DAQmx/Software package not working in Windows 7

[ghillisniper]

The error occurs very randomly.  We have a joke that it always occurs when we're showing the machine to visitors or if we absolutely have to have a successful test.  It does seem to happen most at those times.  We've tested quite a few non-essential test specimens and the error does occur from time to time but very intermitently.  The last time I used the machine it occured on my second test but later that day my coworker used the machine and it never threw the error.

We have no way inside our software to look at the device; however, if we have all of our test menu options in our software then it detects the device.  If our software does not detect the device there will be a lot of mission menu options because they wrote the software to do that to avoid catastrophic errors if someone tried to run a test without having the computer hooked up to the test hardware.  I'll try to get some screenshots of the menus if it will help but it may take some time.

When I put the new USB-6009 OEM in our machine I was not getting full menus (thus our software couldn't detect it), Windows Device Manager was seeing the device, and MAX was not seeing it.  Now that I've reinstalled the old USB-6009 OEM our software detects it and it is visible in Windows Device manager; however, MAX still does not see it.

In the end, I'm not really concerned if MAX sees the device or not.  My objective is to get our software to see it AND most importantly to not get the errors when I test specimens.  I have three test jobs waiting on this machine and for at least one of them I have no room for errors.  I cannot replicate the test specimens if one of them is broken without getting readings in the software.

Thanks. 

[Matthew-B]

Hi ghillisniper,

In general, the device should show up in MAX in order for it to be recognized by any of our software. What I'm most interested in right now is why the old USB-6009 OEM is detected by your software and why the new one isn't. Do you know if you software expects the USB-6009 OEM to be at a certain alias or does your software include the functionality to change the alias used? It may also be possible your software auto-detects which devices are installed in your system and then picks the right one.

If your software expects a certain alias, we might be able to change the new module to the correct alias and hopefully that works.

Regards,

[ghillisniper]

I believe our software looks in a particular place for the device.  It may auto-detect...I'm not really sure.  There is no capability to change where it looks in our software interface although there may be a way to "dig in" to the software and change where it looks from a development standpoint.  Again, I'm not really sure how that works.  I can talk to the guys who helped develop the software and see if they have any insight.

I appreciate you working with me on this.  I know there are several issues going on with this machine that may or may not be related and hopefully we can get them sorted out.

[ghillisniper]

Our software guys confirmed that there is no way in our software interface to change where it looks for devices.  They said that it basically scans for appropriate devices and if it finds them it connects to them.  That's the easy answer that a guy like me can understand anyway.

I upgraded our drivers to NI DAQmx 9.8.  I have tried a driver upgrade before in an attempt to fix the error we were having but had no luck.  However, in this case MAX was able to see the device as it should.  I haven't looked at the device much in MAX yet, but it was listed.  

Now to fix the error!

I just wanted to update you.  Thanks!

[Matthew-B]

Hi ghillisniper,

That's good that updating to DAQmx 9.8 this time has made your USB-6009 OEM show up in MAX! Please let me know if your software is able to properly detect the device and how often you get the error now.

Regards,

[ghillisniper]

Matthew,

I had my collegue work with our test machine yesterday.  He switch the old USB-6009 back out for one of our new boards before running the test.  The reasoning for this was because we don't have a lot of time or materials to run tests on if we can help it and we hoped that we could eliminate USB-6009 from the potential variables to fix list.

Once he restarted the machine, the device was still visible in MAX and in Windows Device Manager but now our software doesn't detect it again.  Additionally, the drivers appear to be just fine in MAX and the device self tests successfully but the drivers don't appear when looking in Windows Device Manager.  When trying to reinstall the drivers they also appear to be correct because it won't install or repair anything.  There is nothing written into our software to manual locate devices.

So to restate the latest developments:  updating the driver with the original USB-6009 OEM device installed allowed our software and MAX to see the device but we still recieved an error once in awhile (probably in every 10 tests but we have a limited sampling from that state of the machine).  Switching the USB-6009 OEM device to a brand new one and retaining the up to date driver caused us to not be able to use our software due to it not detecting the device but for the most part it appears to be communicating with Windows and MAX just fine.

Thanks.

[ghillisniper]

Matthew,

I found another tidbit of information that may help regarding our software.  This was an old conversation I had with one of our engineers long ago that I forgot about.

"On start-up, the software attempts to create a read channel at "Dev1/port1/line2" and attempts to read from it.  If it can’t then it declares the hardware not installed and hides all hardware related menus."

I'm not sure if this helps at all.  I'm also not for sure if that is something I can define to the device in MAX or some other software or not.

Thanks.

[ghillisniper]

I just went into MAX and deleted the old device from the list and renamed the new one "Dev1" and our software now detects it.  I'm not very familiar with how these devices communicate (I'm a blissfully ignorant "plug and play" guy) so I apologize for not catching on to that a bit quicker.

I'll have my collegue run some tests and I'll let you know how those go.  Thanks.

[ghillisniper]

Matthew,

Here's another update:

We started testing the software by running "speed tests" with no samples in the machine.  These were doing fine so we put a few samples in the machine.  Four of these tested fine and then our software shutdown unexpectedly.  Upon restarting the software we got the other error that we had seen before (I'll attach a screenshot of that one).  We don't get that error very often but it does show up sometimes.  It is a cascading error as well so it just pops up infinite error boxes.  Each time we closed the software and reopened it and if it didn't error out immediately it would as soon as we tried to test a sample or test the speed.  We restarted the PC and the software then started up properly and successfully ran about three speed tests.  We then did three actual tensile pulls which all succeeded.  At that point we were out of samples.  So we fabricated an elastic strap that would get us enough force to generate a tensile graph and tested it quite a few times (probably about 20).  None of these threw any errors at all.  We made some more test samples and put them in and after three successful tests it threw the error once again.

Another note, somtimes it throws this error at the very end of the test and sometimes at the very beginning.  Once it throws that error the computer seems to require restarting before the software will start up properly again.  Also, since putting the new USB-6009 device in and changing its name so the software could detect it we have yet to run into the primary error we were receiving before (memory buffer overflow).  But we've only done about 10 actual tests since then and about 20 simulated tests.  The speed tests rarely throw errors for some reason so I can't really count those.

In case the attachment fails, this is the error we have been receiving today:

"NI Platform Services:  No transfer is in progress because the transfer was aborted by the client.  The operation could not be completed as specified.  Taks Name:_unnamedTask<217>  Status Code: -50405"

Thanks.

[Matthew-B]

Hi ghillisniper,

My guess is that the software is coded to use the Dev1 alias, which is why deleting the old device and making sure the new one is at Dev1 allowed your software to communicate with it. The original error was probably related to something with the aliases.

For the new error you are observing, I think it has something to do with the driver or device getting into a state that will cause these errors. Restarting the computer is one way to clear these errors. If the developers are up for making a small modification to the code, you may be able to fix this by programatically resetting the USB-6009 OEM prior to starting any DAQmx tasks. This Community Example shows how you can do this. Documentation for the DAQmx Reset Device VI can be found here.

Regards,