Jump to content

USB Extenders and cDAQ


Recommended Posts

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.

Link to post

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.

Link to post

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.

Link to post

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 by Jordan Kuehn
Link to post

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.

Link to post

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.

Link to post

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.

Link to post

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.

Link to post

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.

Link to post

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

Link to post

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.

Link to post

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.

Link to post

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.

Link to post

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.

Link to post
  • 2 weeks later...

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.

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By Gary Armstrong
      LV2016 64-bit
      I have inherited a LabVIEW Interface that talks thru a USB2 Interface to a micro-Controller at 921,600 baud.
      This opens a new world of possibilities as USB2 can handle data at much higher rates than a typical RS232 interface.
      I have been tasked with rewriting the LabVIEW code as it is difficult to maintain.  I have an application that will talk to the uC at 230 kbaud but can't attain the 921,600 baud. I have tried copying the pertinent VIs from the supplied code into my app but still can not attain 921,600 baud. Plus I don't have a serial line analyzer capable of handling USB2, so I can only trial and error with the uC. Is there a setting I have to do in LabVIEW to allow serial communications at the higher rates? At the moment, I am trying to get the Find Controllr VI to work. I have included the support VIs for the Find Controllr.vi. The Find Controllr VI attempts to find the correct port and baud rate and then obviously communicate with the uC.
      Find Controllr.vi
      Packet TR.vi
      Get Available Ports.vi
      Serial Data.vi
      Check For Packet.vi
      Open Port.vi
      Create Packet.vi
      Extract Packet ID.vi
      PTI CRC.vi
    • By Gan Uesli Starling
      I have a LabVIEW program, which when operating with simulated input data is blazing fast during mock-up. As soon as I hooked into a real cDAQ on Windows, however, the update speed fell off to 4 seconds. That's awful slow. I don't really have a whole lot of channels. I have read tasks for Volts of maybe 5 channels, write tasks for both On./Off for maybe 10 channels (simultaneous) and write tasks for 4-20mA of only 5 channels. How may I improve on that? Is it maybe a priority issue in Windows or to do with USB? What? How to improve? Thanks in advance.
    • By Manudelavega
      Hi, I have contacted NI sales services but it's a great frustration as usual, so I will try to get some support here
       
      Basically for a project I need 2 CAN ports and I decided to go with XNET and Compact DAQ. I have 2 solutions I try to choose from:
       
      Solution 1 --> One 4-slot chassis with 2 NI-9862 modules (one port per module)
      Solution 2 --> One 1-slot chassis with 1 NI-9860 module (this module has 2 ports)
       
      I am confident that solution 1 will work well since I already had a project in the past with one 4-slot chassis (cDAQ-9174) and one NI-9862 module. But going with solution 2 will allow me to cut cost significantly. I just want to make sure it will be absolutely seamless and transparent for the software. Does anybody have experience with the NI-9860? Can it be considered as the equivalent of 2x NI-9862 as far as the software is concerned (LabVIEW driver) or does it remove some performance/flexibility/other?
       
      Thanks!
    • By volatile
      Lets pretend I wanted to simulate a solar panel using a cDAQ, a programmable power supply and a light sensor. Id have to measure the voltage from the light sensor and the PSUs current, use those values to find the respective operating point on my light/voltage/current-curve and update the PSUs settings. Lets also say I wanted to do this for multiple systems in parallel, all connected to 1 analog input and 1 analog output module in 1 cDAQ.
      What would be the best way to achieve the quickest response time? Simply reading and writing single samples seams to be pretty slow (though I can encapsulate everything neatly this way).
      Is there a better way?
    • By FJ_Sanchez
      Hello,
       
      I've been struggling with this problem for months now... I want to use a cDAQ9171+NI-9234 with an Advantech PC (AIMB-580). I have 3 computers like this and all with the same problem. I plug the USB cDAQ-9171, Windows detect the device and loads the proper driver (cDAQ-9171), it is displayed in MAX but self-test or reset always fails with error. At the same time, NI Devive Loader service hangs up. If I try to restart or stop this service it cannot complete the operation, the only way to finish this operation is to unplug the usb cable from the PC, then the service restarts correctly. Additionally the windows' event logger shows the next error message:
       
       
      or
       
       
      In one PC I re-installed Windows, installed DAQmx 14 and the problem was still there, this is with a Windows fresh-install... After this, I removed DAQmx 14 and installed DAQmx 9.8 (supplied in CD) and the it worked!!! I upgraded to DAQmx 9.9 and it was still working, so I stoped there as it was all I needed (9.8 has some bugs with NI-9234 that 9.9 solves).
       
      One thing to note, when it works, Windows first install cDAQ-9171 driver, but then inmediatly it changes to USB flash firmware updater, after this it returns again to load cDAQ-9171 and detects the NI-9134. When it don't work it only installs the cDAQ-9171 and doesn't load anything more...
       
      I tried in a second PC to repeat the process, but I have been not able to repeat the success, only the fail... I get the same error every time I plug the USB and I have not idea of what else try... I have disabled UAC, cleared the MAX data, reinstall windows 2 times, tried with DAQmx 9.8, 9.9 and 14. Forced USB flash firmware updater as Windows driver, changed BIOS settings (disable hyper-threading, VT extensions, USB legacy, etc.). I am almost sure that it is some kind of weird incompatibility or similar, the thing is that NI device loader always hangs-up. In the next days I'm going to try to copy the same exact configuration of BIOS from the working PC, just to be sure.
       
      Any recommendation?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.