LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx bug?

Solved!
Go to solution

With DAQmx 8.8 and LabVIEW 8.6.1

 

"DAQmx Read ( Analog 2D DBL NChan NSample.vi)"

Requesting a finite number of samples leaves the task running until the task is stopped with  DAQmx Stop Task.vi.  This appears contrary to the help file "Auto Start Property var L_helpType = "STD_ENG";

Auto Start Property

Short Name: AutoStart

Property of DAQmx Read

Specifies if DAQmx Read automatically starts the task if you did not start the task explicitly by using DAQmx Start Task. The default value is TRUE. When DAQmx Read starts a finite acquisition task, it also stops the task after reading the last sample.

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 1 of 11
(4,720 Views)

Hi Jeff,

 

Are you calling DAQmx Timing (Sample Clock).vi? When you pass Continuous Samples for the sample mode parameter, then the task won't stop automatically (which you can verify by trying to set a property like AI.Max). When you pass Finite Samples, the task should stop automatically after the read is complete.

 

If you don't call DAQmx Timing.vi, then the SampTimingType property is set to the default value, On Demand, which also causes the task to stop automatically after the read.

 

If this doesn't explain the behavior you're seeing, could you post some code that demonstrates it?

 

Brad

---
Brad Keryan
NI R&D
0 Kudos
Message 2 of 11
(4,703 Views)

Brad,

 

I was relying in the auotstart property of "DAQmx read (2d DBL NChan NSample).vi" to start and stop a finite sample Task on a NI USB 6212 Analog input task.  5 ch with programaticly determined finite samples (less than 10).  the Task did not stop after returning the correct number of samples.  This was unexpected and caused a seperate task on the same device to return a error (-50060?) "Resource reserved..."  when it was next called.  The work around was to explicitly stop the NCh Nsample analog read task with a call to "DAQmx Stop Task.vi"  

 

With a finite sample task and Autostart at default, the call to "DAQmx Stop Task.vi" should have been redundant.  According to the help file, a finite sample task should release its resources when it completes and the AutoStart property is "True" (Default).

 

Is this a previously reported bug in DAQmx 8.8 and LabVIEW 8.6.1?  What C.A.R. can I refer to?


"Should be" isn't "Is" -Jay
0 Kudos
Message 3 of 11
(4,696 Views)
Solution
Accepted by topic author JÞB

Hi Jeff,

 

Are you using reference triggering? I don't have a USB-621x handy but reference triggering on a PCIe-6259 seems to keep the task reserved when using auto start. I just filed CAR #185781 about it.

 

Brad

---
Brad Keryan
NI R&D
Message 4 of 11
(4,692 Views)

Thanks Brad!

 

No referance triggering.  Just a simple NSample on demand AI task that operated unexpectedly.  The work around is obvious but having the this behaviour documented may save someone else a headache.

 

I'm curious to know if any other of the DAQmx Read.vi instances have the same behaviour or if it is limited to just (2D Dbl NChan NSample)


"Should be" isn't "Is" -Jay
0 Kudos
Message 5 of 11
(4,668 Views)

Hi Jeff and Brad,

 

I don't know if you guys would check this post after a year or so, but i'm going to try since i'm finding kind of similar problem.. I'm reading finite samples from Analog Input(3channels) in sync with Digital Input (2 channels). the sampling rate and number of samples for both AI and DI are same (100k sampling rate, reading 70k samples).

 

In my application, I have couple of switches and another analog input from a pot (all tasks created using DAQ express). In the end I acquire signal from three AI(accelerometer) and two DI (two digital sensors). (i'm stopping the task and clearing it it just to make sure it ends- not visible in the picture)  

 

Here's the problem..I have to run this program again and again, since it is a test program run for different parameters. The program runs without any error.. Suddenly the 3 AI's do not accurately acquire the signal at all.. the output just stays at some high value like 500... I have another VI which acquires these 3 channels using DAQ assistant express, so I have to run this VI, then I can actually see the signal suddenly switching from high 500 value to actual value.. now I run again the DAQmx tasks, it works fine..

 

The acquisition part is very crucial for my application..I'm not able to understand this behaviour.. any help is very much appreciated..

 

Thanks,

Palkin
0 Kudos
Message 6 of 11
(4,435 Views)

Palkin-

Yes I was surprised to have a reply after a year but,   I do get a summary e-mail every day from the forums so I caught this.

 

Your issue is not related to the auto-stop bug.  From what I see in your picture (oh-and please post .png files not .jpg's) and your discription I would be 95% confident that you arecausing the problem by re-creating your tasks each time you use it.

 

DAQmx can only open 4095 tasks and then it goes out to lunch.  

 

A better method is to create the tasks you need ONCE and destroy them only when the vi leaves memory.  setting the Auto clean-up T in create task.vi can help get rid of "Old" tasks but it relies on the OS garbage collection to de-allocate the memory (not too reliable).  Alternately, Create persisted tasks in MAX and use them in your vi.


"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 11
(4,407 Views)

Hey Jeff thanks so much for replying..

 

What you say makes sense.. I have used tasks and each time i've created and cleared... Initially when i started off this program, i didn't think it would grow so big.. I'm afraid that i might be in point of no-return ( well may be very difficult return considering my time deadline for delivery)..

 

for all the rest of the tasks, I've used DAQ express and i'm not sure why I don't see the same problem in these DAQ express tasks.. At the particular part of the program, I had to use AI and DI sync'ed so I went in for DAQmx...

 

One more thing I observed is when it is "N samples" mode, this problem is more. If I change it to continuous mode, it seems better..in continuous mode I sometimes see the signal go from 500 some value to correct value. (I've attached the vi if you change the mode of DAQmx from N samples to continuous you probably can see what i'm saying..)

I've added a DAQ express task before reading DAQmx, this kind of seems to work..although I don't understand why...

 

 

0 Kudos
Message 8 of 11
(4,396 Views)

Hi palkin and Jeff,

 

Searching the LabVIEW Help for "Task Creation and Destruction" (without the quotes) will turn up a page that explains when LabVIEW automatically cleans up DAQmx tasks.

 

DAQ Assistant express VIs rely on auto-cleanup, but they don't leak thousands of tasks because they use a LV2-style global to reuse the same task for each call. To see exactly what an express VI is doing behind the scenes, right-click on it and select "Open Front Panel" from the context menu. This converts it to a normal VI, and then you can look at the block diagram.


By the way, CAR #185781 is fixed in DAQmx 9.1.

 

Brad

---
Brad Keryan
NI R&D
0 Kudos
Message 9 of 11
(4,360 Views)

Brad K wrote: .


By the way, CAR #185781 is fixed in DAQmx 9.1.

 

Brad


Thanks!

 

Feedback on when CAR's are fixed is a bit hard to come by.  Mega Thanks!

Message Edited by Jeff Bohrer on 03-18-2010 07:51 PM

"Should be" isn't "Is" -Jay
0 Kudos
Message 10 of 11
(4,352 Views)