Thanks for the post. I am sorry you feel my post was misleading.
My post was a summary of previous customer issues, my work, your work and the results of R&D testing this time around.
With reference to your situation - I was not trying to say it had been resolved yet... I was reporting back on the R&D test. USB devices have been made to fail/error in the past by placing mobile interface near the device. This was the environment conclusion I spoke of.
It is a known attribute to any system that noise is a factor which must be taken into consideration with all applications. I think in a board term we must remember that the environment doesn't always mean electrical noise, but vibrations, temperature, moist - to name a few which do affect the performance of systems.
Again, with the DAQmx reset has been seen to resolve customers issue in the past - so I felt this information - rightly so, should be provided for all systems.. not just RES'.
Also RES you are incorrect in the closing of your support call (Service Request). I am still working and testing with R&D - as I had mentioned I had updated them with the new information from the other poster. I am still awaiting an email with the results of your latest test. I posted on the forum to update the community and post my findings/and previous solutions of similar issues.I also feel i haven't pre-emented the outcome of your test. All the inform regarding soltuions were other customers and R&D work to date.
I am in no form finished with this issue - Once again, I am sorry for any misleading my work may have given.
I'd like to set this out as clear as possible. There is a known issue with our USB devices that can cause a -50405 error. When you plug or unplug an additional USB device some USB chipsets can cause a surge of current on our device. This causes the USB chip on our device to send a error flag. Since that error can mean data loss, we stop the acquisition and propagate the 50405 error up to the user. Currently, the low level USB communication we implement to talk to the device does not recover from that error, so when you do a device reset or try other interactions we don't recover and continue to return the 50405 error. This is a bug and we are actively working on resolving this. We will not be able to prevent the error from the USB chip, but we will be able to recover from the error. In some instances of the error we are able to recover by simply resetting the device twice, but not in all cases. CAR 44890 has been filed with the intent to implement code to allow users to recover from the 50405 error without having to power cycle or unplug and plug in the device.
Now for some specific issues on this post. Res has a situation where he sees the error after running for a long period of time and as far as he knows, no USB devices are being added or removed. This is not a known or reproducible issue on our end. We recently did a long term test for 8+ weeks running continuous acquisition without error and we tested a situation very similar to Res's for a long period of time as well without reproducing the error. I hypothesized that it could be environmental, because enough noise on the USB chip from the environment could cause the same behavior as the current surge from the device removal. This would have to be significant noise and focused on the device (whether on purpose or not) but is the only known failure mechanism. If it turns out that Res can reproduce this in a independent of environment (regardless of how long it takes - there is no reason USB can't run continuously indefinitely) and it seems to be HW or setup related, then we will investigate and try to resolve the error.
For AJ's post, I think that unplugging and replugging the device is essentially causing the same situation - the chipset is throwing us an error due to power fluctuations (if you loose connection only momentarily there may only be a dip in power.) I'd be curious to know how you are securing the USB cable - are you using the strain relief that ships with it? I agree that it would take quite a bit of vibration to pop one of those cable loose, when we put these devices to shock and vibe testing cable disconnects never seem to be an issue. Do you only get the 50405 error when it is in the setup?
MIO Product Support Engineer
Thanks to all the quick responses. Answering the questions directed at me:
Regarding the fix (CAR 44890), do you have any idea on the timeframe for this? And would this require the replacement of the hardware or only a software upgrade?
1. The shipping kit with the USB-6229 currently comes with a stick on cable tie mount and a cable tie for USB strain relief. Check out the getting started section in the user manual. It works well for most situations, though we've added more robust solutions in the BNC modules.
3. Devcon is a Microsoft tool - all it does is allow you to disable/enable the host controller pragmatically. This is pretty much the same as plugging and unplugging the device. You can see if it will help you out by going to Device manager and disabling your USB 2.0 host controller. This has different names based on what chipset you use, but my Intel shows up as "Intel(R) ICH9 Family USB2 Enhanced Host Controller - 293A." Be careful when you disable/enable - your mouse and keyboard will generally switch to the old universal host controller (if they aren't already on there) but if you disable both you'll have to remote in or reboot for the mouse to work. Also any other USB 2.0 devices will either not work or run as a 1.0 device.
I hesitate to put out a timeframe on any CAR, we're still looking at possible solutions. It is currently planned for the next major release of DAQmx which, historically come out every 6 months 9we just released 8.9 a couple weeks ago.) By no means does this mean we will absolutely have this implemented in 6 months, but that would be my best guess. This would not require a HW change, just a driver upgrade.
Hope this helps,
I am having the same problem as AJ, only the error message pops up after about a minute rather than an hour.
I am still working through some of the suggested fixes posted here, but as the system is installed at a remote field site, it takes a little while.
Here is an update on the status of this problem.
We moved the PC + USB + thermocouple into an office environment away from the production environment.
After 1 week collecting temperatures continually the system was still running OK.
For this reason, we are currently working on the assumption that external environmental interference causes this problem. To this end, we have bought a gold-plated USB cable with two ferrite beads and returned the system to the production environment. The test has been re-started (note: tests take upward of 1 week to complete).
Again,. the result of this test will be posted here.
We also have some of these same USB-6229 devices running in a more electrically quiet environment. From what I've seen so far it seems that these units are more stable in terms of staying connected. However, we have found that if we need to reboot our computer for whatever reason, then the USB DAQ devices will not be automatically recognized when the system comes back up. Until the power on the devices is turned off and back on, NI-MAX does not recognize the device as connected and Windows Device Manager indicates and Unknown Device under Universal Serial Bus controllers. I have tried manually removing/uninstalling these unknown devices by hand through the Device Manager and also using the devcon utility, but I'm unable to get them recognized again. When I finally go out to the computer myself and power off/on, then it comes up right away.
Is it possible that this is the same issue (perhaps during computer warm reboot your USB chip gets into its locked state)? Or do you think that this would be something else?
Also (just to be clear) I need several of these devices both out on the production floor and back in our computer room -- though I indicate above that I'm running these devices in a "quieter" environment, I don't have the option of moving all of my devices into that room. Some of them need to stay out near the production I/O points. So I'm just saying that we are keenly interested in getting this NI-DAQ bug fixed so that the devices will automatically come back online by themselves. If this is really going to be a while before it is fixed then we may need to look for other alternatives.
I have been meaning to post a more detailed account of my problem but haven't had the time until now.
I am running a monitoring site off the grid in a research forest. The setup consists of 80 sensors installed in a stream, which are connected to a USB-6229, which monitors the voltage in each sensor. The DAQ board is connected to a Nexcom NISE 3120 computer. This is a low power fanless, AMD Geode box, running Windows XP SP3. The detailed specs can be found here. I am running Labview 8.6 and NIDAQmx version 8.7.2f1. Because there is no power at the site, the entire system must be run off of a battery bank, which is automatically charged by a generator. The batteries, charging system, computer and DAQ are all located in a 8'x5' shed adjacent to the creek. The generator is located about two meters away in its own enclosure. I have the USB-6229 powered directly from the DC circuit coming off the batteries on a 2 amp fuse. This is to save power compared to connecting to through an inverter.
There are no other USB devices connected to the computer. I was not able to use the supplied USB cord as it was too short. I could physically rearrange the components if using the shorter cord would fix the problem, but it would not be a simple task. I checked the USB controller and it is truly USB 2.0. I have turned off the power saving option but I am still getting the 50405 error. If I unplug the USB cable, start up Labview, plug in the cable it will acquire data for about a minute before crashing. Then it will not work again until I unplug the cable, and then the problem repeats itself.
So far it seems that it has been environmental factors that are supposedly the cause of these errors. What sort of environmental factors might these be? It is not possible for me to relocate the system, as there is no where else I can put it. Is it some sort of electrical interference? I may be able to seperate the charging equipment and the DAQ board some distance but I am limited by the physical size of the shed. Is it at all possible that I will be able to get this system, in its current environment, recording data, or should I begin looking for a new system?
Device detection on reboot is an issue I've seen reported but we've never been able to reproduce in house. I really don't have a theory on what causes it but would love to investigate. May I contact you offline? You can also email me at MIO.DAQ.PSEs@ni.com.
I would hope that you're not getting enough environmental noise to cause a problem in the middle fo the forrest (sounds like a cool application by the way), and I would think your generator would have to be right on top the module for it to have any chance of causing a problem. Also, the 6229 has a metal case as opposed to the plastic on the 621x devices so it should be more immune to environmental. Aside from environmental, I've known power supplies to cause problems and poor quality USB cables to cause random issues that would seem completelty unrelated. Just to double check, do your batteries supply 11V and up to 20 W? Can you monitor the voltage on the power supply and see if it corresponds to a failure? Just as a sanity check, if you use a different USB cable does it still reproduce in a matter of minutes?