01-15-2013 03:39 PM
The NI I/O trace will be helpful when you get the chance to create it.
Are you seeing the same results on both the Windows 7 development computer and on the Windows XP testing computer?
01-17-2013 07:23 AM
I'm hoping to run an I/O Trace today on the testing PC. It will probably be a large file size, I'll have some trimming to do.
I did see the issue a few times on the development computer early on, but we have only one DAQ and it is in production use at this time, so I don't have it connected to the development computer long enough to see any problems recently. It's been a couple months since the DAQ spent any appreciable time connected to it. The development computer is my own assigned laptop, so I can't usually leave it for a routine test. If you think it's worth investigating, I can arrange to get a loaner for a day while the test group runs the test with my machine.
I hope to have some more data tomorrow.
Thank you again!
01-17-2013 08:36 AM
I launched NI I/O Trace on the testing PC both prior to launching and after launching my software. Unfortunately, it doesn't capture anything at all (Captured: 0) when my software is running.
I tested it out with MAX and confirmed that I/O Trace does in fact get communications details through MAX. It grabbed some 533 lines in under a minute of running.
Is there anything I can do to get it to work in my software? My code is compiled with the Debug flag set. I confirmed the software is working as expected and data is in fact being fed to the testing PC.
I could try to let it run for a while in MAX after a routine test is completed, and I expect I'd have an error or two overnight.
Thank you!
Jim
01-17-2013 05:35 PM
I am not sure why it isn't capturing in Measurement Studio, I will look into that as I am trying to reproduce the behavior.
I am working to recreate the behavior in MAX and then in Measurement Studio. However, when you posted the code it was only the .cs file, will you please zip your entire project and post that verses just the main code.
01-18-2013 08:06 AM
M,
For help in reproduction, attached is the MAX task and device export, which might help in troubleshooting. All of the NI9211s have four Japanese-spec T-type thermocouples attached. The NI9215 has four voltage-output pressure transducers connected with all four negative signals electrically connected. We are seeing the data we expect to see. The NI9201 and NI9403 devices are not connected to anything at the moment (all terminals are open). The pressure transducers are powered by a 120VAC-24VDC power supply, the frame of which is grounded to the chassis ground of the enclosure and the DAQ frame itself.
As for the software, I'd have to talk with IT and legal to release the entire codebase as is, since it contains specifics on test specifications and measurement criteria of our production units. It would probably be better for me to fork the software and use 95% of the existing backend (removing equipment-specific details), write up a new dummy frontend that does the same thing as our existing software, verify we still have the glitch, and then send that to you. That might take a week or two since this is actually more of a side-project and unrelated to my official job title.
Would that be acceptable?
01-18-2013 10:50 AM
Hello Jim,
After working with a few of my colleagues in relation to the cDAQ 9188 another reason your device could be timing out is due to a loss of communication, it could be network communication or the computer falling asleep. Is there any way that the times that the program times out the computer goes to sleep, disconnects from the cDAQ, or something else occurs on the PC?
Another possible way to get NI I/O Trace from your code is by building it into an executable then preform an NI I/O trace of the executable.
As you work towards creating code that we would be able to test, this article explains a way of getting the error and then ignoring it and restarting your device. The article explains how to perform this operation in LabIVEW, but the concept should be able to take place in Measurement Studio as well.
After working with Chris there is a corrective action request (CAR # 387231) filed related to a similar issue with the same error.
01-18-2013 01:02 PM
Hello M,
Again, thanks for your continued investigation.
When we have the problem, the DAQ and the PC are both alive and well. I've had a couple of rare occurrences where it happened a few minutes after starting the task in MAX - without my software running. The PC is set to never sleep; it will eventually lock the desktop, but not sleep, and the reported issues happen while the desktop is still unlocked. The network configuration is such that the DAQ is wired right to the PC with no other devices in between, both with static IP addresses. The PC does have a wireless adapter to connect to the company network, but this is configured separately. Last I checked, the PC CPU load is under 50% with no 100% peak usage spikes. I wouldn't rule out a networking issue or some freak hardware problem with the PC(s) but it does seem to be less likely than a software glitch of some sort.
My software is built into an install package using a deployment project and then is installed as an executable on the testing PC, which is where I tried the I/O Trace software. I didn't see an option to attach it to an executable, but I'll look again. On the development laptop, I run from within Visual Studio. I didn't try an I/O Trace that way.
I have been able to work around the issue somewhat in my software - the DAQ.cs file I'd sent shows what the read function error handler does now. It stops the task and restarts the task. The DAQ device itself needs no additional queueing or input, it continues to work after the stop and restart of the task. I just lose some samples, which is ok in my current application. It's still not my prefered workaround, but it has kept me from restarting a 5-hour continuous test after a few hours. I will certainly review the article and see if I can do more.
Thanks again. How do I follow that particular CAR?
Jim
01-21-2013 05:09 PM
Hello Jim,
The best way to get information about a CAR is to add a post after some time looking for additional information with the CAR number or by contacting National Instruments at ni.com/support.
The other CAR was created based on DAQmx Base on a Linux machine. I am currently working on reproducing the error on a Windows machine with DAQmx. I will post the results of my test when completed.