VISA over TCP/IP goes dead after few hours

[Fedor]

We are using VISA over TCP/IP to communicate with instruments. We run into some odd behavior that hard to explain:

The VISA session starts fine, the LabVIEW application communicates with the instruments few times a second via Visa write and Visa read. Then, after few hours, there's a VISA error that pops up, either VISA timeout or connection lost. Any attempt to communicate with the instrument, e.g. closing/opening/clearing visa etc,  fails after that. Surprisingly, if the failed connection was started using canonical VISA name, e.g. "TCP::..." it is often still possible to communicate with the instruments using its VISA alias. I believe the opposite is also true, if it fails via alias, canonical name still work. The VISA functionality could be restored by closing LabVIEW completely, and trying to communicate to instrument via NI-MAX VISA session, e.g. by issuing *IDN?\n query. After opening LabVIEW again, application works fine for another few hours. 

We never had any issues if use the same LabVIEW application with VISA over USB or GPIB.

Is there something wrong with LabVIEW VISA TCP/IP library?

Details:

LabVIEW 2016 64 bit

NI VISA 17.5

Instrument: Cryo-Con 22C

[Bob_Schor]

We connect to (up to) 24 balances that send out serial (VISA) data over TCP/IP, and typically record for 2-3 hours at a time.  We've not seen any problems.  The Balances are connected to two "concentrators" that take 12 serial ports in and send it (multiplexed over 12 TCP/IP "ports") through two IPs (one per concentrator).  This is connected to the campus network, and we read the data using LabVIEW VISA commands on a PC several floors (and a different sub-net) away.

I'd guess your problem is either hardware or software.  You haven't told us much about your hardware or network, and haven't shown us any VIs with code ...

Bob Schor

Bob Schor

[Fedor]

Hi Bob,

We have several instruments interrogated in parallel several times a second using LabVIEW VISA calls, just VISA Write and VISA Read VIs, nothing particularly fancy. The instrument VISA resources are configured as TCP/IP RAW sockets in NI MAX. The communication messages are ASCII-based, configured to terminate on cartridge return char.

I don't think the problem lies with the LabVIEW code because of the symptoms of the problem: once the communication with a particular instrument goes bad, any attempt to communicate with it from within LabVIEW using its VISA name fails. For example, if I just stop main VI after communication fails and run a very simple VI instead that only contains VISA write with "*IDN?\n", followed by VISA read, it would return an error. Sometimes, in this failed sate, testing instrument as above, but using its VISA alias instead of the the canonical resource name would still work ok.  If I would than exit LabVIEW development environment and issue the same query in NI MAX, the instrument responds right away. I can then restart LabVIEW and communication would work fine. 

Fedor

[billko]

---

@Fedor wrote:

Hi Bob,

We have several instruments interrogated in parallel several times a second using LabVIEW VISA calls, just VISA Write and VISA Read VIs, nothing particularly fancy. The instrument VISA resources are configured as TCP/IP RAW sockets in NI MAX. The communication messages are ASCII-based, configured to terminate on cartridge return char.

I don't think the problem lies with the LabVIEW code because of the symptoms of the problem: once the communication with a particular instrument goes bad, any attempt to communicate with it from within LabVIEW using its VISA name fails. For example, if I just stop main VI after communication fails and run a very simple VI instead that only contains VISA write with "*IDN?\n", followed by VISA read, it would return an error. Sometimes, in this failed sate, testing instrument as above, but using its VISA alias instead of the the canonical resource name would still work ok.  If I would than exit LabVIEW development environment and issue the same query in NI MAX, the instrument responds right away. I can then restart LabVIEW and communication would work fine. 

Fedor

---

Sounds like you are losing communications with your instrument and your VISA resource session becomes invalid.  Closing out LabVIEW closes your VISA resource session, too, making it available once again.  Check networking issues and the like.  You may want to trap that error, close the VISA session and re-open it.

[Bob_Schor]

Can you show us your code involving the VISA Setup and the VISA Read?  I presume your device sends a Termination Character, you've set VISA up to read up to the Termination Character, and your VISA Reads specify something like 1024 bytes (which is the "too large number" that I use in my code) ...

Bob Schor

[Fedor]

Bill,

Is there a way to make VISA resource that became invalid like that available again by programmatic means, without exiting LabVIEW?

Bob,

The setup code is VISA Open followed be Termination Character Enable and Termination Character = 10.

The communication code is VISA Write, followed by VISA Read.

It takes few hours to reproduce failed conditions, so my diagnostic data on that is somewhat limited.

[Bob_Schor]

---

@Fedor wrote:

Bill,

Is there a way to make VISA resource that became invalid like that available again by programmatic means, without exiting LabVIEW?

Bob,

The setup code is VISA Open followed be Termination Character Enable and Termination Character = 10.

The communication code is VISA Write, followed by VISA Read.

---

If I had a dollar for every time I described (incorrectly!) my faulty code to a colleague and said "Why doesn't it work", and then showed them the VI and they said "But this wire is connected to the wrong place!", I could buy a really nice dinner, with good wine ...

Bob Schor

[Fedor]

VI is attached.

[billko]

---

@Fedor wrote:

Bill,

Is there a way to make VISA resource that became invalid like that available again by programmatic means, without exiting LabVIEW?

Bob,

The setup code is VISA Open followed be Termination Character Enable and Termination Character = 10.

The communication code is VISA Write, followed by VISA Read.

It takes few hours to reproduce failed conditions, so my diagnostic data on that is somewhat limited.

---

Sorry I didn't make myself clear.  The procedure I outlined above is how you would handle it programmatically.

[mcduff]

Is the code attached, the code you are actually using?

I have seen some flaky behavior with too many VISA opens being run in a loop. Open it once outside the loop, and then close when finished.

The other problem may be the computer, I had the same issue as you where it would work for a while and then stop for no apparent reason, nor at any particular time. Sometimes IT runs stuff that interrupts comms. Other computers with the same code just worked.

mcduff