LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Instrument disconnect

Solved!
Go to solution

I have a VI (LV 2017) controlling 4 Lake Shore 648 powersupplies connected by USB simulated COM ports, one of which (the same one regardless of cable or port) keeps disconnecting. I cannot tell if it is the unit itself or the computer or the software doing it. To reconnect the insturment, I have to physically disconnect and reconnect the unit by either unplugging the cable or turning it off and then on. After this, I cannot get the VI to see the instrument with out completely shutting LV down and re-opening it. I can still however communicate with the instument via the VISA control panel within NIMAX.

 

I have no idea why one program would be able to see it but not the other. I've never had any issues with the other three instruments.

 

Is there some method of diagnosing the issue I can employ? Or better yet....a known fix!?

LV-2017
0 Kudos
Message 1 of 16
(4,516 Views)

What power supplies are you using?  Is there another communication bus you can use?

 

Personally, I despise USB for stupid things like this.  My preference is Ethernet.  With a simple Ethernet switch, you can connect a lot of instruments with a reliable bus for cheap.  Just be sure to use a localized network that uses fixed IP addresses to avoid most of the pitfalls.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 16
(4,493 Views)

They are Lake Shore 648 power supplies.

 

I have no choice but to use USB.

LV-2017
0 Kudos
Message 3 of 16
(4,484 Views)

Does it stay with the port, cord, or instrument when you try to switch some things around?  Stay with the method of only changing one variable at a time to help isolate the issue (IE Leaving all the cables plugged into their USB ports, disconnect the bad supply from its cord and swap it with a good one then place the good one onto the bad cable. Try it again - what fails now?)

Help the Community (and future reviewers) by marking posts as follows:
If it helped - KUDOS
If it answers the issue - SOLUTION
0 Kudos
Message 4 of 16
(4,471 Views)

The specs page says it also supports IEEE 488.2, i.e. GPIB.  I don't suppose you could use that instead?

 

Do you have any support from the manufacturer?  It could be a bad board in the actual machine.  If the fault stays with the particular machine no matter what cord or USB port you use, that's the most likely culprit.

0 Kudos
Message 5 of 16
(4,462 Views)

As I said, regardless of port or cable it stays with the same machine. GPIB is a potential fix but I don't want to spend money on the cables and USB adapter if it's not a certain fix.

 

Does LV store some kind of address for each COM port that cannot change without a restart of the program? I'm just a little confused as to why NIMAX can communicate with it after the disconnect but not LV.

LV-2017
0 Kudos
Message 6 of 16
(4,443 Views)

The tendency is that if it works in NI-Max, then it is an error in the vi configuration.  It may be a point where that instrument is handled differently, or a shared resource is not handled properly.  Without seeing any code, everything is just speculation.

Help the Community (and future reviewers) by marking posts as follows:
If it helped - KUDOS
If it answers the issue - SOLUTION
0 Kudos
Message 7 of 16
(4,417 Views)

This is what I thought, I'm hoping it is indeed a issue with the configuration.

 

You are quite right, please find attached. I made the code with a single magnet and then copied it 4 times to get it where it is. VJ is the broken output, please forgive and issues, I am only a beginner.

LV-2017
0 Kudos
Message 8 of 16
(4,397 Views)

Other than guessing at what is happening within your lake shore 648 init+read+close.vi, here are my main observations.

  • You should add a VISA Close upon leaving your main loops
  • All of those spreadsheet writes & reads are trying to occur simultaneously.  An issue may occur when it attempts to read from a non-existent file/folder prior to the initial write.  Using flow-control, perform a Write->Read to prevent this issue.
  • Are the directories and COM assignments correct?

Additionally, you might want to do these as clean-up

  • Change the Refresh to a U32 representation to remove the Wait coercion dot
  • Only a single instance of your timestamp to DBL is needed prior to your main loops
  • The Shift Register in the main loops serves no purpose
  • Remove or replace the build directory loop with a single flat sequence if desired
Help the Community (and future reviewers) by marking posts as follows:
If it helped - KUDOS
If it answers the issue - SOLUTION
0 Kudos
Message 9 of 16
(4,377 Views)

Still no luck? 

 

It seems this work is continuing on from this post -https://forums.ni.com/t5/Instrument-Control-GPIB-Serial/Virtual-com-port-usb-reconnect/m-p/3806347#M...

 

If the same instrument is failing while 3 others work, then you need to call Lakeshore to discuss with them what the issues might be.  If its not specific to one instrument, then there's something wrong with your hardware setup.

 

Can you explain the physical setup?  Is this 4 USB-RS232 cables leading to 4 magnets?   What USB ports are you using?  Have you tried a dedicated USB PCIe card ($20-50) for all of these?  Cheaper than GPIB, which was mentioned.  Perhaps you can borrow a USB-GPIB and some cables to perform a test and check if that solves the problem?  (No change to the code would be required).

 

Craig

0 Kudos
Message 10 of 16
(4,348 Views)