LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Application using DAQmx 7.5 and NI USB-6008 crashes whenever I move its window.Can anyone help me?

Hi everyone !
 
I´m developing a  DAQ application which uses NI DAQmx 7.5 and NI USB-6008 and it´s showing a strange behavior - well ... it seems to be strange to me! - which is, whenever I move its window an error occur. The error code is the following :
 

Error -50550 occurred at DAQmx Read (Analog 2D DBL NChan NSamp).vi

 

Possible reason(s):

 

A synchronization object was not acquired within the time limit. The operation could not be completed as specified.

 

Task Name: AI_TASK

 

This application is made of the following : two while strucutures, one to manage an event structure and another to implement data acquisition and some calculations, before sending data to front panel controls, and a sequence structure that is responsible for initializing the DAQ task.

 

One of my job partners told me the crash is happening because I didn´t separate data acquisition from calculations and user interface management but before doing as he suggested I decided to ask you guys to see if anyone could help me with this.

 

As always, any help at all will be deeply appreciated !

 

 

 
 
 
0 Kudos
Message 1 of 2
(2,496 Views)
Giovani,

That is very strange behavior indeed. It doesn't sound like you are doing any syncronization in your application so this error is quite odd. With this error occuring when you move the window leads me to believe that it is some kinda of software timing issue. When ever you are doing software timing from Windows, or any other non_RealTime (RT) OS you are going to run into non-deterministic timing problems. What I mean by this, is that the OS decides when things will happen, and when to give your application some CPU time, and you can't know when this will be. So if you have any sensitive timing applications (i.e. things need to happen at a certain time) that are software timed  you always run the risk of getting errors when in a non-RT environment. Things like mouse movement, and keyboard strikes always have higher priorty in a standard OS so they can easily cause software timing issues, which sounds like that maybe happening. So avoid software timing if you can, and use hardware timing.

The suggestion that your partner made is a good one. Especially if your software timing is critically, you want to keep any calulations or anything that can take up clock cycles seperate from the actual data acquistion. So as I was elluding to ealier, if your application is being software timed and is time critical, having extranious code in the same while loop could cause issues similar to what you are seeing. So take your partners advice and seperate the code. Another suggestion I have for you would be to check out the shipping examples that come with the DAQ drivers. Make sure that a simple example works fine, and start working from there adding things until you run into any errors. A good example to check out is "Acq&Graph Voltage-Int Clk.vi", use the NI example finder and browse for it in Hardware I/O >> DAQmx >>.Analog Measurement >> Voltage. Make sure that example runs as it is suppose to, and work from there. If you run into any more issues it would be useful to post what kinda data aquisition that you are doing, (e.g. analog intput, number of channels, hardware\software timed, etc.). Hope this gives you some insight, and gets you moving in the right direction.

-GDE
0 Kudos
Message 2 of 2
(2,480 Views)