USB DAQ interferes with USB Serial port

[sth]

Has anyone else run into the problem of USB locking up due to VISA timeouts on another device?

I have two separate VIs.  One does some USB-Serial communication and continuous DAQ (VI-1) and the other doing just serial communication (VI-2).  When VI-2 is connected to a remote device all works fine.

VI-1 does serial communication and USB-DAQ in separate loops.

The problem is that the device on the other end of VI-2 is sometimes turned off and does not respond.  When this happens VI-2 attempts 5 reads to timeout then throws up a modal window to the user to tell them that the remote device has disconnected them.  This modal window self dismisses after 10 seconds.

When VI-2 gets a serial port timeout, the DAQ loop in VI-1 also gets a timeout and reports an error which causes all sorts of havoc since it appears that the DAQ board has failed.  The timeout is the default 10 seconds and I am reading about 0.1 seconds of data so the timeout is much longer than needed.

USB requests on separate devices such as DAQ and Serial should be completely independent and non-blocking.  Has anyone else run across this problem?

LabVIEW 2012

Mac OS X 10.8.2

VISA 5.20

NIDAQmxBase 3.6.0

[Chris-NI]

Hi sth,

The error you are describing does sound odd.  What is the specific timeout error you are receiving?  Is it the same error code for both drivers (VISA and DAQmx Base)?  Have you tried your code on a Windows computer to see if the same problem occurs?

If you can post your code here, that would be helpful as well.

Regards,

[sth]

Yes it is odd.  I am assuming that the timeout error is just that, a read with no response.  But I will check it tomorrow.  The system had to run last week so I carefully avoided the problem and couldn't mess with it.

I could post the code for both VIs.  I have no problems doing that, but it is two large hierarchies with all sorts of related calibration files etc. I will try to save a copy of the hierarchy for both programs and zip them up, but no guarantees that it will load or run on another system.

No, I haven't tried this on Windows.  Finding a computer that runs windows with LV 12 and NIDAQmxBase installed is a bit of a job and installation time.  Our lab is almost entirely Mac for the ease of use factor.

[Chris-NI]

Hi sth,

Thanks for the additional information, and I'll wait to hear on that error code.

I'll be happy to look at the complex VIs, but as you said, it may not do us any good without identical setups, files, etc..  Is it possible to make a more basic replication of the issue with some basic VISA and DAQmx Base calls?

If we were to try to reproduce the issue here, we'd be starting on Windows; the Mac machines are a bit harder to get ahold of.

Regards,

[sth]

Chris,

The error code from the DAQ loop is a timeout as I said.  It is code -200284 time passed without samples being available.  This loop does a continuous iteration and acquires 100 points or so at 1 kHz.  It has a default 10 second timeout which is 100 times longer than the expected operation.

This combination of VIs ran well and reliably using a PCI 6030 card and LabVIEW 7.0 on a Mac running OS 9.2.2.  The two VIs did not interfere with each other.

I have attached the VIs as a compressed hierarchy.  The two relevant ones have aliases in the top level folder.  The machine has a keyspan dual serial port attachment and a NI USB-6210 multifunction DAQ board.  The two VIs are "Hybrid PS control.vi" and "PS Control.VI"

Usually the "Hybrid PS control.vi" is run first.  This has the DAQ board interface.  This VI runs fine and communicates using a serial port 

Then launching a second VI completely hangs the first VI while it attempts 25 times to communicate over a serial port.  This hangs the bottom while loop in the first VI which only does DAQ.  The DAQ times out.

The system is configured to have 8 threads for all execution engines which should be plenty in this case.  That used to be the max.  I see that the new threadconfig.vi allows up to 20 threads per execution engine.

I have a bunch of things going on this week, but I will try to slim down both VIs to a minimum to replicate the problem.

Thanks for looking at this.

Scott

[johnsold]

Scott,

1. These VIs are set to run when opened.

2. Running Hybrid PS Control.vi generates an error in the Hybrid Start Read Server.vi because the Hybrid PS Read gateway.vi is not in the batch of VIs you posted.

I do not have any DAQ hardware, but I was going to take a look anyway.

Lynn

[sth]

Sorry about the run when opened.  They are set up that way for the operators.  You can always just add them to a blank project and open them from their to get them to open without running.

I have turned that off and included the two dynamically called VIs that did not get included (and all their sub-vis).  I agree that it won't run, but you can get an idea of the code problem from looking at the BD.  It is the bottom loop in the "Hybrid PS Control.vi" that times out while the USB serial port is timing out.  It doesn't happen every time but often enough to signal system failure and initiate a shutdown of the world's most powerful magnet.

[johnsold]

Scott,

Thanks for the other VIs.

In Hybrid PS Control I disconnected the error out wires from Setup DAQ.vi and Read DAQ w- Reset.vi.  With those changes it will run.  I also added indicators on all three loop iteration terminals.  PS Control.vi generates an error at PS Setup.vi and PS get status.vi is even unhappier. After killing the error wires in those subVIs, PS Control will run.

I have an EasySync two port USB to RS-232 adapter connected with the second port (ASRL4) wired to loop back. Get First Serial Port.vi returns that port.  I noticed that format of the name returned in Check for Valid Serial Port.vi seems slightly different from the regular expression.  I am not very good with regexes, so IO may just be misinterpretting something. But it might be worth checking.  The help for that property node recommends against using it for programmatic decisions.

The status displays on both VIs go crazy, but both continue running, with all three loops in Hybrid incrementing.  They have been running with errors supressed while I was writng this. Iteration counts are now above 3000 in both VIs and 1000 in the bottom loop of Hybrid.

I am sure you have seen this also but sometimes an error is caused by something else which occurred before the error message shows up.  You might look at what is happening just upstream of the VIs which are throwing the errors.

Lynn

[sth]

Well the fault is that the daq times out when the other VI is run.  If you hide the NIDAQmxBase error returns then you won't get the DAQ to quit.

Since it is 4PM here and things have calmed down I hope to start stripping down the main VI to make a runable error.

[sth]

Lynn, Chris,

Here is a hugely stripped down version of the 2 VIs (now about 1/5 the size).  Have the serial port with a loopback connector on the port.  Run #1 first then when it is running and updating the voltages it will probably show the DC Breaker voltage in red since it will be too low.  That is fine, it will just display and the voltages will flicker as they update.

from the DAQ card start #2.  It will timeout since it will not get a response on the first port.  Wait a moment and dismisse the modal dialog.

While #2 starts up, it will freeze the daq update.

At this point the DAQ loop will get a timeout and then fail.  This timeout is false but still reported by the system.

If it doesn't the first time, run VI #2 a second time.  I haven't had to try it a third.

Lastly, VI #1 blanks the front panel and leaves it white with a spinning pizza wheel of death for about 10 seconds when pushing the done button.  Not clear why that is happening.

Notes: It is not clear that the #1 VI needs the serial port at all to show the error.  That will be the next simplification but I did a lot and the error is still there.

The #1 VI doesn't need a loop back connector since it isn't reading anything.

Hardware is Mac Mini 2012 quad CPU, Keyspan twin serial adaptor, USB-6289 mutlifunction DAQ

I will update my find first serial port and find second serial port for the FTDIs when I settle on one of them that is reliable as per my info-labview discussion

I will try simplifying this more tomorrow (I have about 4 open VISA/USB issues and I am trying to resolve and test them all simultaneously)