LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Re-establishing VISA Ethernet comms

My scenario:

 

1. I am using an Agilent 34980A datalogger with a notebook running LabVIEW 2010 10.0f2 connected via an ethernet crossover cable.

2. I log temperatures for up to 300 thermocouples every 5 mins. Tests typically run for 4 to 8 hours and often overnight.

3. If there are any power glitches, the datalogger will reboot into an initialised state. Battery backup on the notebook will keep it running.

 

What I am finding is if power is lost, and the ethernet connection is disturbed, I cannot re-establish comms without re-booting the PC running my compiled LabVIEW code.

 

The last couple of days I have been running my uncompiled code to try and work out where the problem is. This is what I have found:

1. After the ethernet connection is first established, I can view the logger in MAX.

2. I run my code, the logger is found and the software and logging functions work fine.

3. If I re-boot the logger while my LabVIEW code is still running, the connection cannot re-establish and I get a VISA error -1073807346.

4. If I go into MAX again I can connect to the logger and view the HTML pages the logger is pushing to MAX but still my code can't re-establish.

5. If I restart my LabVIEW code, connection is then re-established.

 

Does it have anything to do with VISA opens and closes? Any clues would be much appreciated!


Regards, Adam

 

 

 

0 Kudos
Message 1 of 6
(2,887 Views)

Yes.  You will likely need to close your VISA connection and try to reopen it to establish the connection.

 

What does your while loop look like?  If you have a shift register on your error wire, it can cause problems unless you handle the errors carefully because an error would be returned to the beginning of the loop and would cause the code in future loop iterations not to execute becuase of the error.  That is because most LabVIEW functions that take an error wire will not execute any real code if there is an error on the wire already.  They will just pass the error through untouched.

0 Kudos
Message 2 of 6
(2,881 Views)

Yes I did discover the error scenario you describe where another VI wasn't fully operating due to an error being fed into it. I now have an "error" case structure which includes running VISA Close before re-starting the comms process.

 

Can anyone point me in the direction of some good VISA ethernet based VIs as a coding example?

0 Kudos
Message 3 of 6
(2,860 Views)

Hi Adam,

 

I haven't been able to find a good example to point you to on this topic, but in some past cases your strategy of closing and reopening the connection on a timeout error has worked out.  Were you successful in getting your instrument to reconnect with that approach?  If not, let me know where you are stuck.

 

Thanks,

Morgan S

Applications Engineer

National Instruments

0 Kudos
Message 4 of 6
(2,827 Views)

Please find attached the coding I have been using to investigate my errors.  (LABview V10 vi)

 

This seems like the best way to recover from comms errors that I have come up with, but I am very happy for the gurus on here to pull my code to bits as they see fit!

 

There are still some times when it cannot recover and I have to restart LabVIEW and/or the 34980A datalogger to recover.

 

I also notice that the Find VISA resource list will list my three 34980A loggers even if they are are not connected, so I have to ping each one to work out which one is actually connected. I guess I could use the default IP address instead to connect.

 

I had also forgotten that the dataloggers have USB on them as well, so I am now comparing USB as a permanent connection option. So far it seems to recover much better than Ethernet, but I would love to hear from others regarding USB vs Ethernet comms for reliability.

 

I also have a wireless DAQ module on loan from NI that I am evaluating......

0 Kudos
Message 5 of 6
(2,817 Views)

Looks reasonable to me.  So sometimes that's working to reconnect and sometimes it never does?  Are you getting timeout errors every time, or do other errors start coming up?  USB may be a good way to go - Ethernet can create some extra variables, especially over a shared network.

 

Morgan S

Applications Engineer

National Instruments

0 Kudos
Message 6 of 6
(2,789 Views)