DAQmx read vi freezes randomly with no error

[scaskey]

Good morning Eric, 

I upgraded the DAQmx software yesterday. Through the night, the code froze in the same spot as before. It appears there wasn't any bug fixed with the new version. 

I have not tried running any of the shipping examples of similar acquisition type for an extended period of time. 

I did notice that a sub-vi that applies calibration fits to all the thermocouple points is taking a large amount of time, 0.6-0.7 second to run. This is because the calibration points are in an excel file. I will try to hard-code these points to free up some operational memory in the rest of the system. 

The strange thing to me is, why would the DAQmx read show it is in operation, when it clearly has exceeded the built-in timeout? 

Also, when the main VI is waiting on several DAQmx read VIs, it doesn't appear to be really frozen. The reason I beleive this, is when the main VI hangs up, I can unplug the cDAQ, and trip an error that is registered by the main VI. Otherwise, I cannot have the main VI respond to any other events. 

Can you explain why this would occur? 

Thank you for any insight you can provide. 

Also if we cannot figure out the issue, are there any other support options availble? 

Thank you,

Stephen

[Hazen_berg]

Good morning Stephen,

I am sorry to hear that updating the driver did not solve the issue. 

I believe hard coding those calibration points should free up some memory and time, as it will not have to access a file to read this data/

The behavior you are seeing is not expected behavior.  Unfortunately, I haven't found much information on what could be causing this.  I would attempt to run those examples to see if its the program that is causing issues.  

Also, what operating system are you using?

[scaskey]

Hello Eric, 

Thank you for your feedback. 

Normally, I would run these programs over a long time to see if any issues are encountered. The problem with this approach is, we are collecting data every second, for all hours, everyday, and running a different program would interrupt this data collection for at least a day potentially. 

I would have to find a suitable time period to allow the main DAQ VI to be offline to run the other code independently. 

The OS on the computer is windows 7 enterprise, service pack 1. 

Regards,

Stephen

[Hazen_berg]

Hey Stephen,

Thanks for continuing to work with us on this issue!

I believe this is the best thing to do, as it will be telling if the issue resides in the code, or in the hardware.  From what I understand, it looks like it could be a function in the code just hanging, causing the timeout to not occur, or it could be the hardware failing to complete sending data back to the VIs.  I am curious as to our example code functions in this situation, as its been tested and guaranteed to work when properly implemented.  

If you are able to do this, please try to use one VI to run several tasks without the processing and other functionality of your program.  Just use the shipping examples that come with the DAQmx driver to create a simple VI, and run this over a long period of time.  If this works without error, it is most likely in your VI.  If you still receive the error, it is most likely a PC or hardware issue.

[scaskey]

Hello Eric, 

Sorry for the delay since my last reply. 

Due to the research project the data collection is for, I would like to avoid any attempts to bring the system off-line unless we are down to the last resort. 

Since the problem takes many hours until it occurs, I would have to run a simple VI that I cannot save data with for a long period of time. This would be due to the fact that once a task is opened on another VI I cannot use it anymore on my main data collection VI. 

Let's say hypothetically the problem isn't there when I run a simple VI for a long period of time. Then what in my VI could be causing this problem? 

Since the main VI is stuck at three "DAQmx read" VI simultaneously, where in the structure of the VI that I created could cause this problem to occur? 

Why does the timeout not work on the "DAQmx read"? 

Currently I am pursuing assistance from the ni.com/support page on this issue. I can close this open topic here as unresolved to help save you time if you feel that I've exhausted your recommendations. 

Sorry for any inconvience. 

Kind regards,

Stephen

[Hazen_berg]

Hey Stephen,

That is quite alright!  I am sorry to hear that; this would be quite the inconvenience. 

The only other option I can imagine is that the software is trying to acquire data from the machine too fast and the cDAQ cannot keep up.  I would suggest adding a Wait (ms) inside the acquisition loops.  Create a constant or control on this Wait and give it a wait time so that the acquisition is software-timed.  This will change the rate at which you acquire samples, which depending on your application's requirements may be acceptable or not.  I would just suggest trying this to see if it is an issue with the cDAQ itself.

Aside from this, it sounds like it is either an issue on your specific computer or with the cDAQ.  In a previous instance of this issue, the solution resided in purchasing a new cDAQ.  How old is the one you are using?

I understand the code seems quite large, but if you'd be able to simplify the code and recreate the issue, it would do wonders for troubleshooting it.  If you are unable to find a solution, I would suggest running an example as described in our previous messages, or trying a new cDAQ (if available/willing).  

I do apologize that I'm sure this isn't the ideal answer, but without being able to recreate it or complete the troubleshooting steps (and understandably so from the sounds of your application), then we are very limited in our ability to resolve this issue.  If you have any updates or changes, feel free to post back and I'd be happy to look into this more.