USB DAQ 6001 & 6216 Init Issues

[MogaRaghu]

In a project on Win10 machine using LV2012 i am using 2 nos of USB6001 and one USB6216. 

All fine. Except at random occasions the USB 6216 (and  other card at times ) do not initialize and all gauges are dead. Have to open MAX , reset the cards and then they fire up.

This is annoying to do and they fail exactly when the customer is around ( ! ) ... has anyone faced this kind of issues ?

And to mitigate this can  I use the DAQmx Reset.vi just after i create the relevant task ? Will it help ? Or is there any other reason for this kind of behavior ?  I have used the regular PCI DAQmx cards in so many projects and not once i had such an issue. 

Any pointers to solution will help. 

Thanks. 

[Blokk]

---

@MogaRaghu wrote:

In a project on Win10 machine using LV2012 i am using 2 nos of USB6001 and one USB6216. 

All fine. Except at random occasions the USB 6216 (and  other card at times ) do not initialize and all gauges are dead. Have to open MAX , reset the cards and then they fire up.

This is annoying to do and they fail exactly when the customer is around ( ! ) ... has anyone faced this kind of issues ?

Yes, the "customer" tricked me and unplugged/plugged the USB cable 😄

And to mitigate this can  I use the DAQmx Reset.vi just after i create the relevant task ? Will it help ? Or is there any other reason for this kind of behavior ?  I have used the regular PCI DAQmx cards in so many projects and not once i had such an issue. 

I suspect that you do not close the DAQmx resource properly. Can you show your VI? Do you properly initialize before your loop, and close the resources after (DAQmx Clear Task VI)?

Any pointers to solution will help. 

Thanks. 

---

 Edit: some more questions:

• Do you run your application from the LV IDE, or as an EXE?
• Are you sure the DAQmx HW dev numbers are correct?
• Do you use proper error handling? You should program your application in a way that it reports you any errors. What kind of error you get when the device "does not want to get initalized". Resource not found? Timeout?...

[MogaRaghu]

@Blokk

1. Problem is same when running in design mode as well as EXE mode.

2. Device numbers are correct.

The actual code is really large and I will not be able to post it as is.  But I am attaching the DAQmx init part for the Analog channel .... the task reference then passes to a Timed Loop within which the actual acquisition happens and resulting data is passed via Queue to various other SUB VIs.  Here is the Init part :

 And user clicks the QUIT APP button the DAQmx tasks are closed in two ways. The AI and DI taska are just cleared . The AO and DO tasks are written with default values and then cleared., Error is daisy chained to trap any issues. Here I show the AO and DO termination :

[Kevin_Price]

Due to these kinds of experiences with USB DAQ boards (both our own and others we've read about here), we work to avoid using them for any apps being deployed to non-expert users.

So unfortunately, I don't have any reliable advice -- if I knew any, we'd have done it ourselves.

I'd just point out that your shutdown code isn't really doing what you describe as your goal.  You're feeding the DAQmx Write's with *empty* arrays rather than default values that are safe to leave after app shutdown.  Even after fixing that, chaining the error cluster is *not* a good idea here because an error on an early task will prevent the subsequent ones from writing the safe values.  Here you should explicitly *not* wire the error in's, and then merge the error out's.  That gives you the best shot of successfully putting safe values on each task's output pins.

-Kevin P

[MogaRaghu]

@Kevin_Price

Do you imply that the USB-DAQ devices are not for the weak-of-heart clients ? Maybe that only confirms my worst fears going by the random lock ups these seem to have. Anyway the project is now commissioned and any change of hardware will have serious implications. So will need to try all ways to make it more reliable.

The point on daisy chaining error outputs is an eye opener. Never realized that one upfront error will prevent "write" of a down the line device. Will change it. And yes "empty array" don't achieve anything. The real code has properly initialized arrays. So no issues on that count.

Thanks.

[Blokk]

Once I programmed an NI USB-6009 "soap box" which reads 2 AI channels with the max available speed, plus ramping up a power supply of a magnet using voltage output (stepwise ramping up with the required resolution). This was an update/upgrade project of a very old K-Ar dating instrument with a spectrometer. As I remember the year of the project was 2013. Since then they are using the system with this USB device without any problem!

We had actually some issues with this USB-6009, but we figured out the issue was caused because we used a non-reliable USB port in our laptop. After we started to use the USB-3.0 port which was "closer connected" to the motherboard, and not via an internal USB-hub (common thing in laptops that some of the USB ports are bundled together to a hub), the problem just got solved.

During another project, some colleagues got random problems with their USB DAQ unit. When I went to troubleshoot the problem, I realized they connected the DAQ unit to the laptop via an external USB-hub. I told them they should connect the DAQ device directly to the laptop, or at least they should get a brand USB-hub which has external powering. This solved that problem too...

I have no idea if you have such problem, but you can give it a try. That time I got an advice from an NI engineer, that the best thing to use is a separate brand made PCI-USB card (if you use a desktop PC), and not USB-hubs!

[Kevin_Price]

My preferences are not the last word on USB daq boards.  Their continued popularity suggests that there are a lot of customers who are generally or very satisfied with them.  I've gotten the impression (but can't back it up) that it's the lower cost bus-powered boards that tend to be significantly more problematic.  

Yeah, error chaining is generally a good practice but your situation is one of the exceptions.  It's good to ask that question as you wire errors: "do I want a prior error in the program to change the behavior of this specific function?"   I've found a number of circumstances where I'll merge errors after calling functions without wiring an error in.  When you do this, consider priority -- I always make sure the original error goes in at the top of the merge node so I'll see it in my error reporting.

-Kevin P

[Blokk]

Yes, looks like the error handling "eats" the original error. You should get an error when your application cannot initialize the DAQ dev. Even when we had our problems originated from the cheap USB-hubs, we got errors. So we had the chance to trace the original reason, even if it took some time.

You could also create a small application trying to reproduce the behaviour. It is easier to catch the problem if you use a lightweight test VI. One example: try to make a While loop which does nothing but Initializes then Clears the resource(s), then run it for a couple of days. You did not tell us, what is the frequency of these issues? Lets say number of occasions per day (considering you run the system all the day)?

You can also put in some DAQmx Read or Write in the loop, just to see if these functions cause something...

[JÞB]

And do check the windows power manager settings.  I can almost bet that the OS is shutting down power to the USB hubs.  Of course, this is BAD since the device then needs to be unplugged and plugged back in.  I also hope you have a hub powered from an external source (Wall wart) and enough power per device (500mA recommended)

And that no-one starts hijacking the port by sticking their thumb-drive etc... into your hub

[Ben]

---

@JÞB wrote:

And do check the windows power manager settings.  I can almost bet that the OS is shutting down power to the USB hubs.  Of course, this is BAD since the device then needs to be unplugged and plugged back in.  I also hope you have a hub powered from an external source (Wall wart) and enough power per device (500mA recommended)

And that no-one starts hijacking the port by sticking their thumb-drive etc... into your hub

---

Ditto that!

I have shunned using USB_Hubs so I can not speak to their use but all of the USB DAQ devices issues I have seen have all been corrected by finding and killing all of the power -saver/sleep options.

Ben