USB Extenders and cDAQ

[Gan Uesli Starling]

For years I have successfully used the Icron USB Ranger 2204 Cat 5 Extender with both cDAQ and SCXI. But now I have one very annoying issue.

I only recently purchased some NI 9237 units for my pressure transucers. Those, and only those, modules don't seem to like being polled over the USB-to-Cat5 extenders which I have in both of my test cells. I have timing issues. Not with all of them all of the time. But with all of them some of the time and with some of them all of the time. I get that pop-up message that says not all of my channels have been read. Increasing the timeout even to ridiculous lengths helps not at all. The rest of the porgram works just fine so long as I do not assign a bridge channel.

So, what gives? I can't go bringing my PC closer to the test setup because of safety reasons. We're a combustion lab. I don't want to have to be stringing out long wires all of the time because we're a test lab and those get set up, taken down, changed all around every week. It's a big issue.

Can anybody recommend a USB extender other than the Icon which they have used with good success on the 9237 units? All that I am trying to read are finite samples, just two of those, and the speed doesn't matter much. I've already tried different speeds to no avail.

[asbo]

This might be a bug with the module - have you bounced this scenario off NI?

[hooovahh]

If you are using cDAQ is there a reason you haven't tried the ethernet chassis? I swear there was an 8 slot option, and I also thought they were the same price as USB. I've had good luck with replacing a USB solution with an ethernet one which would be more suited for long routes.

[Gan Uesli Starling]

To "asbo": The problem manifests with plural, identical NI 9237 modules.

To "hooovahh": I would like to have considered that before having acquired almost ten of these cDAQs slowly over the last five years. At the time the idea was to have them compatible with any PC. We only have a two, 3-instance, Full Development licenses and propagate some VI's as built applications. Also, our IT department has fairly draconian views with anything we do on Ethernet.

[Jordan Kuehn]

If you are using cDAQ is there a reason you haven't tried the ethernet chassis? I swear there was an 8 slot option, and I also thought they were the same price as USB. I've had good luck with replacing a USB solution with an ethernet one which would be more suited for long routes.

Here you go http://sine.ni.com/n...g/en/nid/208990

The ethernet ones take a little bit more set-up, but work great for longer distances.

Edited October 29, 2012 by Jordan Kuehn

[JamesMc86]

What other modules have you used previously successfully? I find it odd that the different modules would have much of an effect, the underlying transfer mechanisms should be the same, but these would be potentially at the faster end of the spectrum.

How many chassis do you have on one link as well? I guess the other consideration is that the latency would be increased, I presume you have a decent enough timeout but maybe the DAQmx driver dislikes the increased latency (but again why this module!).

I would probably suggest getting in touch with your local NI branch, they should be able to get in touch with R&D that will have a better idea of lower level differences.

[Gan Uesli Starling]

To JamesMc86: These are all the cDAQ units I presently use. Green have given me no difficulty whatsoever. Only the red ones have been a problem. I mix and match them variously for different tests. Obviously I don't have the bucks to just replace 9 USB cDAQs.

Qty Model Description

9 NI-9178 Compact DAC, USB Chassis, 8-slot

7 NI-9203 Analog In, Current, 8 Ch SE

10 NI-9205 Analog In, Voltage, 32 SE/16 DI

11 NI-9213 Analog In, Thermocouple, 16 Ch DI

1 NI-9263 Analog Out, ±10 V, 4 Ch

11 NI-9265 Analog Out, 0 to 20 mA, 4Ch

1 NI-9274 Digital Out, 24 VDC Max , 8 Ch

6 NI-9435 Digital In, ±5 to 250 VDC/10 to 250 VAC, 4 Ch

7 NI-9485 Digital Out, 60 VDC SSR, 8 Ch

Only the four that I have of this model give me problems:

4 NI-9237 Analog In, Wheatstone Bridge, 4 Ch DI

I think latency is indeed an issue. I have only one cDAQ chassis on this Dell Optiplex 790 MT. But I can get a few readings on the 2-port USB before it hangs, never more than one or two. If I'm plugged into the either of the 4-port USBs it hangs on the first scan. May I add that I'm only trying to read one single channel of that Wheatstone bridge module.

[Gan Uesli Starling]

To "Jordan Kuehn" and "Hooovahh": Our IT Dept pushes us to use these small form factor Dells which have only one Ethernet connection and our Ethernet has a lot of restrictions. Very specifically, I'm forbidden to put in a switch (which might add latency there, as well).

[Gan Uesli Starling]

This is the specific error I keep repeatedly getting, but only when trying to read a channel of the NI 9237. Sometimes it stopps immediately, other times it chugs along nicely for a few readings first.

Error -200284 occurred at Inputs_Read_All.vi

Possible reason(s):

Some or all of the samples requested have not yet been acquired.

To wait for the samples to become available use a longer read timeout or read later in your program. To make the samples available sooner, increase the sample rate. If your task uses a start trigger, make sure that your start trigger is configured correctly. It is also possible that you configured the task for external timing, and no clock was supplied. If this is the case, supply an external clock.

Property: RelativeTo

Corresponding Value: Current Read Position

Property: Offset

Corresponding Value: 0

Task Name: _unnamedTask<A89>

I can get it to run quite a bit longer by daisy chaining two 5-meter USB 2.0 extender cables end-to-end (routed under the door) but then, after enough time, the cDAQ itself momentarily fails to be detected and I get a "device not there" error. So that's no fix either. Alas and alack.

[Jordan Kuehn]

This is the specific error I keep repeatedly getting, but only when trying to read a channel of the NI 9237. Sometimes it stopps immediately, other times it chugs along nicely for a few readings first.

Error -200284 occurred at Inputs_Read_All.vi

Possible reason(s):

Some or all of the samples requested have not yet been acquired.

To wait for the samples to become available use a longer read timeout or read later in your program. To make the samples available sooner, increase the sample rate. If your task uses a start trigger, make sure that your start trigger is configured correctly. It is also possible that you configured the task for external timing, and no clock was supplied. If this is the case, supply an external clock.

Property: RelativeTo

Corresponding Value: Current Read Position

Property: Offset

Corresponding Value: 0

Task Name: _unnamedTask<A89>

I can get it to run quite a bit longer by daisy chaining two 5-meter USB 2.0 extender cables end-to-end (routed under the door) but then, after enough time, the cDAQ itself momentarily fails to be detected and I get a "device not there" error. So that's no fix either. Alas and alack.

At risk of sounding insulting, are you certain the task is configured correctly? You mentioned that these are new modules to you so perhaps there is something that isn't configured correctly that is giving you your timing issues. It could even be a combination of both. What are the details for your task configuration?

Also, here's NI's breakdown on that error: http://digital.ni.com/public.nsf/allkb/FEF778AD990D5BD886256DD700770103

Of course, it's entirely possible everything is set up correctly, but it never hurts to double check the obvious stuff first.

[asbo]

To "asbo": The problem manifests with plural, identical NI 9237 modules.

I didn't mean a bad module so much as a design problem with every module or its driver.

NI I/O Trace may reveal some interesting low-level detail; if you go to NI, it will almost certainly be a useful diagnostic tool.

[Mellroth]

This is the specific error I keep repeatedly getting, but only when trying to read a channel of the NI 9237. Sometimes it stopps immediately, other times it chugs along nicely for a few readings first.

Error -200284 occurred at Inputs_Read_All.vi

Possible reason(s):

Some or all of the samples requested have not yet been acquired.

To wait for the samples to become available use a longer read timeout or read later in your program. To make the samples available sooner, increase the sample rate. If your task uses a start trigger, make sure that your start trigger is configured correctly. It is also possible that you configured the task for external timing, and no clock was supplied. If this is the case, supply an external clock.

Property: RelativeTo

Corresponding Value: Current Read Position

Property: Offset

Corresponding Value: 0

Task Name: _unnamedTask<A89>

I can get it to run quite a bit longer by daisy chaining two 5-meter USB 2.0 extender cables end-to-end (routed under the door) but then, after enough time, the cDAQ itself momentarily fails to be detected and I get a "device not there" error. So that's no fix either. Alas and alack.

We had a similar issue with the ethernet based cDAQ chassies NI-9188.

In that case the solution was to define a higher sample rate than we actually needed, just to fill the transmit buffer on the cDAQ side, then decimate the samples on the receiving end.

When we asked NI about this, the response was that it probably had something to do with the new DAQ Streaming engine.

/J

[Gan Uesli Starling]

To Jordan & Mellroth: No worries, I'm not so thin skinned. Among an infitity of things in which I am not an expert, LabVEIW is just another. That said...

If I take the Icron Ranger 2204 USB2-Cat5-USB2 extender out of the connection link, replacing it instead with a pair of daisy-chained, USB2 repeater cables, then my LabVIEW program works as expected, sometimes for up to two hours. If I do get any error on the those, daisy-chained cables, it's temporary failure to recognize the cDAQ at all, whereupon I get a "device found" pop-up from windows. The program also works fine as is if I bring a laptop into the combustion lab test cell and plug in the USB cable from my cDAQ directly.So my suspicion would be that it has to do with the Icron extenders themselves.

Timeout: I have set my timeout up to a full minute to the same effect.

Sample rates: I have tried increments everywhere from 1613 to 50,000 all to the same effect.

Read later in the program: This would be hard to do. But it's a loop and often does take a reading on the first loop, sometimes several, before it hangs.

Longer delays in the loop: Tried this just because. Does not seem to help.

Timing: I use the internal clock.

Updates: I pretty much always have the latest. We're on NI's annual renewal plan for two Full Development licenses.

I have twenty some other channels being read all in the same loop and none of those give any problem. These are thermocouples, current AO's and AI's, a digitial output. My single bridge channel is configured for Finite Readings, 2 Samples only of just one channel, on the internal clock at any of the speeds told above. I really only want one single reading per loop. I could get that using a voltage channel but I was really looking forward to the simplicity of not having to hook up an external power supply every time just to get pressure readings from my Sensotec units. So I bought four of these cDAQ bridge units on my annual capital budget. They're starting to become an embarrassment to me.

I'd like to include a screenshot but I can't seem to upload it directly and am having trouble finding someplace to put it where I can just use an URL.

[Jordan Kuehn]

I'd like to include a screenshot but I can't seem to upload it directly and am having trouble finding someplace to put it where I can just use an URL.

I use imgur.com for quick uploads of images.

[Gan Uesli Starling]

I use imgur.com for quick uploads of images.

Alas and alack, I get this... Your request to URL "http://imgur.com/" has been blocked by the McAfee Web Gateway URL Filter Database. The URL is listed under categories (Media Sharing), which are not allowed by your administrator at this time.

Likely it will be the same with any of those. When I'm desperate, I got to B&N and use their WiFi, but it's a fair drive from work.

[asbo]

I'd like to include a screenshot but I can't seem to upload it directly and am having trouble finding someplace to put it where I can just use an URL.

Moreover, if you click through to the full editor using the "More Reply Options" button, you'll have the ability to attach files, including images.

[Gan Uesli Starling]

Update: I've spent two hours mixing and matching my USB2-Cat5-USB2 extenders and have more complete results. While none of the Ranger 2204 pairs I have tried perform reliably with the National Instruments cDAQ-1978 having a NI-9237 installed, all of them cause the LabVIEW program to hang at some point, I do have another model, an Ranger 2104 pair having SN’s ICL2101903-009845 and ICR2014903-005975 which appears to be working fine, at least so far.

Models & SN’s of Ranger 2104 pairs which work okay:

Model P/N 10-00117 SN ICL2101903-009845

Model P/N 10-00119 SN ICR2104903-005975

Model P/N 10-00117 SN ICL2101905-020378

Model P/N 10-00119 SN ICR2104905-006207

Model P/N 10-00117 SN ICL2101912028137

Model P/N 10-00119 SN ICR2104912009732

Models & SN’s of Ranger 2204 pairs which cause LabVIEW hangups:

Model P/N 10-00153 SN IC2204L003612

Model P/N 10-00154 SN IC2204R003612

Model P/N 10-00153 SN IC2204L002365

Model P/N 10-00154 SN IC2204R002365

Model P/N 10-00153 SN IC2204L006293

Model P/N 10-00154 SN IC2204R006293

Model P/N ? SN IC2204L-04-007412

Model P/N ? SN IC2204R-04-007412

So, oddly enough the oldest USB to Cat5 extenders, the ones I bought first, the 2104’s seem to perform okay but all of the newer 2204’s, which I thought were nicer because they’d sit on top of the PC where I could see the readout LEDs are sources of trouble.

I am in communication via Email with Icron to see what might be the issue.

[Gan Uesli Starling]

I have attempted to address the issue with the Icron Ranger 2204 unit pairs by updating them to latest firmware supplied by Icron Support (91-00083-R05.exe).

This update of firmware had no beneficial effect on this particular problem with communicating to the NI 9237.

I have informed Icron of this and await their further suggestions. Meanwhile know that the Icron Ranger 2104 unit pairs continue to serve my LabVIEW purposes well. It is only the 2204 units which have this issue.