Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

linux DAQmx intensive execution failure

Hi,

I'm using a PCI-6602 under CentOS 3 Linux kernel 2.4 with DAQmx 8.0 drivers.

I made a code that uses all eight on board counters: this code waits for a signal on ctr1 or ctr7 (buffered two edges separation) to activate a 1Hz signal on ctr0 used to trigger all remaining counters (that made buffered semiperiod measurement).

I start this code that must remains in execution without exit (cyclic code). After a complete acquisition, it delete tasks, creates new tasks restarting all counters and waits for a new signals on ctr1 or ctr7.

I've experienced a problem: after about four days of continuous execution, ctr1 and ctr7 does not longer respond to signals: I must quit and restart application to reactivate normal funcionality on this counters.

It seems that there is an execution-time dependency, not a number-of-measures dependency on failure: so, it seems that isn't important how much restarts, but how much time the program remains in continued execution.

On the same pc, to simulate signals, there is another 6602 used by another software. Curiously, this software never fails, but there is an (important?) difference between two softwares: simulator starts, generates signal, and then exits: it is executed into a shell while script. Instead,first program (the one thar measure signals), never exits.

What could it be? Could be an issue that NiDAQmx drivers must be resetted after each execution?

 

 

Thank you, regards

Mauro 

0 Kudos
Message 1 of 3
(2,949 Views)

Hi Mauro!

I'm not sure I have understood correctly the difference between the application that gives you problem and the one that works correctly:

in the first case you start and stop the task inside the loop (so you create a new task every while cycle), while in the second case you start and stop the task outside the while loop. Is this right?

Do you get any error message when counters stop receiving signals?

Are you sure that the trigger signal is still arriving correctly to ctr1 and ctr7 when you see this problem?

Thank you

 

Serena M.

Applications Engineer

0 Kudos
Message 2 of 3
(2,929 Views)

Hi Serena,

thank you for your response.

The difference between tvo executables is that the first, as you say, creates, starts, stops and deletes tasks into a while loop inside the program.

The second one creates, starts, stops and deletes task not in a while loop, because is a one-shot program: it executes the code and then exits.

The ciclicity is obtained with a console loop: in pratice, program will be executed n times; acquisition program instead executes only one time, but creates, starts, stops and deletes tasks n times.

Could be this difference the problem? (so, drivers musd have reinitilized after a couple of time?)

I'm absolutely sute that trigger signals arrives correctly on ctr1 and ctr7 (I can see them with a oscilloscope) .

 

Thanks in advance, regards

Mauro

0 Kudos
Message 3 of 3
(2,926 Views)