DAQmx Task ID missing in action

[johnsold]

I am converting an old program (Its ancestry goes back to LV 1.2) from LV5.1 on Mac OS7 to LV8.2 on a Windows XP machine with a PCI-6221. This is my first attempt to use DAQmx, so I am probably doing something simple, but wrong.

I started with the example Cont Acq & Graph Voltage-IntClk.vi. That works fine. I split it into three parts, the configuration, the read, and the clear, with the read part in a loop. This seems to work every other time the program is run. On the times it does not work, I get a timeout error and the Task ID out indicator is empty. I am trying to put together a simple example which illustrates the problem, but have not yet succeeded. I'll try to post something later today.

I have a Config AI VI which contains DAQmx Create Channel (AI-Voltage_Basic).vi DAQmx Timing (Sample Clock).vi and DAQmx Start Task.vi - exactly the same as the example. The inputs are AI physical channels, Samples per Channel, Sample Rate, and error in. The outputs are ai task out, AI Sample Rate, and error out. If I run this directly the Task out is "_unnamed task <1>". When run as a sub VI the Task out is sometimes empty. I suspect that the Stop Task and Clear Task VIs were not executing, but I cannot confirm this. Putting an indicator or probe on the Task out wire shows empty on the times where it does not work. Do Stop Task.vi and Clear Task.vi work if the error in is True? The help is not clear on this although prelininary testing indicates that they do.

The final program has the AI running continuously, feeding a circular buffer. The AI Sample Clock is used as the clock for hardware timed DO with finite samples. This task gets reconfigured frequently as the number of samples in each burst vary. (This is a slow system with lots of time between bursts, so the reconfiguration time is not an issue.) An AO task is run from a different clock but is triggered from an edge on one of the DO lines. This is also a finite burst of variable length.

Any ideas?

Thanks,

Lynn

[Kevin_Price]

One thing that tripped me up when first using DAQmx is the automatic garbage collection it does.  It doesn't sound exactly like your problem, but it may be a possibility.

I often wrapped up my data acq tasks in action engines.  Using the traditional DAQ drivers under Windows, I could test the action engine as a top-level stand alone vi.  I'd run it with the "Config & Start" action, then run it again a few times with the "Read" action, then run it yet again with the "Stop & Clear" action.  The DAQ task ID was held in a shift register, available for reference on subsequent runs.

This technique failed under DAQmx because all open DAQmx task refnums are cleared when LV completes execution.  So I'd run the action engine with the "Config & Start" action, and all was well.  When I tried to run it next with the "Read" action, I was pulling a no-longer-valid DAQmx task refnum out of the shift register, producing an error.  The workaround is simply to make a non-terminating test vi that calls the action engine as a sub-vi.

Here's a link so I can stop typing sooner. 

"Clear Task" will will indeed clear a task even with an error wired in.  I'm not sure about "Stop Task."

Finally, FYI, your end goal definitely sounds feasible under DAQmx.

-Kevin P.

[johnsold]

Thanks, Kevin. I was not aware of the garbage collection. I do not think that applies here because the Task IDs are wired.

Here is a reduced set of VIs which exhibits at least part of the problem. Rabbit Test 9mx.vi is the top level VI. This program creates and configures several tasks and then clears them without actually reading or writing anything to the DAQ device. If the Clear AO DO tasks.2.vi is opened before the Rabbit test is run, I observe that the Task ID inputs to that VI are empty. Because no Task ID is passed, the tasks are not cleared. If the tasks are not cleared, in the complete program, an error occurs when the program is executed a second time.

As I stated in the OP, most of teh pieces were copied directly from NI examples. What am I doing wrong?

Lynn

[Kevin_Price]

A. I assume it's intentional that the 3 tasks are configured to different stages.  The two that are wired to the "Clear" function are never explicitly started -- perhaps that has some relevance to the empty Task ID inputs?

B. I tried running it but had to do it using a DAQmx simulated device.  Like you, I saw that the Task ID inputs appeared empty.  Next I ran in highlight execution mode and put a probe on the Task ID's.  They showed up as something like "<unnamed task>...".  Then I took off execution highlighting and ran full speed.  This time the Task ID input controls in "Clear AO DO" showed text matching the probes.

This sort of "apparently empty task string" problem vaguely rings a bell with me.  I've got a factoid stuck in the back of my head telling me not to trust what's displayed (or not displayed) in the controls / indicators.  I don't recall why.  But in case that's actually justified, I'd suggest trying something more reliable to test whether a Task ID is actually passed in properly.  Maybe wire up a DAQmx Task property node or something to see if an error is generated?

C. DAQmx tip: down the road as you build up your app, note that it's sufficient to Stop a task in order to redefine the Timing parameters such as # samples.   You can do this using the original Task ID, and then simply call Start again on the defined-but-stopped task.  This will have considerably less overhead than fully clearing the task and then fully recreating it from the physical channels.

-Kevin P.

[Charles_CLA]

I'm not sure if this is related but you are start the AI before you config the AO and DO, if synchronization is an issue you will have issue because the sample clock source is set to the AI. If you want to make sure that everything is synched, then move the AI start vi after the Config AO and DO vi's.

Charles

[johnsold]

Kevin,

A. The tasks are created in separate VIs because the original program was structerd like that and dropping in replacement VIs with similar connector panes simplified things (I hoped). I left out the start and write VIs because I saw the empty task IDs with or without.

B. I will try it with execution highlighting. Would someone at NI look into making the default probe for a Task ID big enough to display the default "_unnamed task <3A>"?
I have observed that the results sometimes seem to vary from one run to the next. I have not been able to identify any correlation with anything which might cause this effect.

C. I do Stop Tasks and reconfigure inside the loop and only Clear at the end. Again that is not clear from this reduced test VI.

Would a named task behave any differently?

Thanks.

Lynn

[Kevin_Price]

---

B.  ...I have observed that the results sometimes seem to vary from one run to the next. I have not been able to identify any correlation with anything which might cause this effect.

... Would a named task behave any differently?

---

B. Yeah, my vague memory is similar -- results from attempts to display Task ID text would vary with no apparent rhyme or reason.  However, I eventually became convinced that the actual functional behavior of the code using the Task IDs was reliable whether or not the text displayed as expected, and pretty much just moved on with things without pursuing it further.

Dunno if a named task would behave differently, but shouldn't hurt any.  (I generally haven't named my tasks and am not aware of any particular benefit.  Unless maybe it would enable some parallel process to lookup tasks by name rather than needing wired task ID's, analogous to named queues.  Never tried it and only just thought of it while typing.)

-Kevin P.

[johnsold]

Here is an analog in only VI which exhibits the missing task ID at the Clear task VI. This VI seems to work OK, but my more complex program is not happy with attempting to reconfigure tasks which cannot be stopped or cleared between iterations of the loop. I think the missing task IDs are either the symptom or the cause.

I am running this with a PCI-6221, but I think it would work with most DAQmx compatible AI devices.

Can anyone explain why task out2 is different from task out and task out3 after pressing stop?

Lynn

[Electromecha]

Lynn,

Did you ever find a remedy for this issue? 

I have the exact symptoms you describe in this post on LV8.5 in the development environment.

In my case, I'm attempting to clear an analog load task in order to ressert a hardware null.  I pass arrays of tasks (AI, AO, Counter, DIO) around my statemachine in a cluster.  When I arrive at my clear state, and call the DAQmx Clear Task.vi, the task value passed to the funtion is empty and the task is not cleared, because when I go to reconfigure, I get error -50103 stating that the resouces for the specific hardware location are reserved.

The task name will also randomly show up in a probe on the task array but the majority of time it's MIA.

Yet in the acquire state, after initial hardware configuration, the DAQmx Read.vi sees the task and executes accordingly.  I haven't been able to locate this as known LV issue but I've seen it in both 8.2.1 and 8.5.

Thanks in advance.

Steve

[johnsold]

Steve,

I have not worked on that project since shortly after my previous post and I do not have access to the computer on which it is running.

Looking at my archive copy, I see that I named the tasks from string constants in the configuration VIs.  I did not wire the task out terminals from those VIs. I placed Task I/O constants containing the names at the inputs to the subVIs which used those tasks.

My conclusion form looking at the code was that I never satisfactorily resolved the issue but was able to get it working by dropping the Task I/O constants all over the diagram.  Of course this makes a maintenance nightmare, but I already told the client that the program would be rewritten, not modified, the next time something needed to be changed.

Lynn