Deleting channels from task, reconfiguring task

[Drew.Rankin]

All,

I am working on an app where I have a variable number of channels configured at any one time. I have read the forum posts about defining a single task at the beginning of the app; however, I can only add channels to the task and not delete anything. This requires me to clear the task to reconfigure the chassis. This is where I am having problems.

Sometimes, when I call "Clear Task", the task is not cleared, even if I stop the task AND follow that up with an abort task. 

Below is basically how I am executing my DAQ sequence:

The create channel, timing, and trigger settings are called within the main application, then I call the acquisition loop by reference so that I can process other events while the acquisition is running. Once I send a stop to the running acquisition, the taskID is retained by the application to be cleared on the next configuration change or acquisition start. This is denoted by the "Previous TaskID" input.

I get a device reserved error sometimes when I change configurations or, if I am running a strain gage acquisition, when I run the calibration vi's. Most of the time, the vi behaves well; however, at times like in front of the customer, I may get repeated device reserved errors.

Any ideas?

I have thought about the initializer of the for loop being a nullTaskID might be dangerous, but I am not sure.

Thanks,

Drew

[Drew.Rankin]

After some more searching, I have found this article to be of some use; however, I was under the assumption that aborting the task would accomplish the same result as "unreserve."

[Sean_N]

Drew-

It is clear that you are seeing this error because the Start Task VI is within a loop.

-What is your overall goal? To change the channels that are being run during run time?

-Have you looked at the example "Acq&Graph Voltage-Int Clk-HW Trig Restarts.vi"?  This shows a way to retrigger by sending your task back to the commit state.

Thanks,

Sean

[JÞB]

Take a look at thee Auto-start property of the task (If your DAQmx version is at least 9.1)

[Drew.Rankin]

Sean,

I think I used that example originally to write the code. (I have inserted the code from that example below)

What I am doing is grabbing a set number of samples from the buffer once the reference trigger happens and displaying the available samples until the acquisition cycle finishes. I am displaying fewer samples than the finite acquisition buffer size to give the appearance of constant activity while the acquisition buffer has not completely filled/finished. Once the acquisition buffer is full, the task goes into the standby state where I re-start the task and wait for the next trigger event. Having the short time-out on the read allows me to abort the acquisition without having to wait for a trigger event or a long time out. This makes the application more responsive to user input.

I have added a loop inside the example below that has a short time out so that I can put the code in the loop in a separate VI that I can call by reference from the main application. When the acquisition loop is running, I am sending the data up through a queue to the main application for display. After the acquisition is done, or is stopped, the loop should finish and allow me to clear the task. However, when I clear the task, the resources are not always garbage collected properly and I get the resource reserved error.

I am hesitant to use the auto start feature in task creation because I do not know how it will behave in a hardware triggered acquisition.

Having the start and stop inside the loop does not seem to cause the issue, because when the read has finished, the task must be restarted. If you issue a start task without a stop task, you get errors even with finite acquisitions. Hence, the example code above contains both a start and stop command with the acquisition reader in the middle.

I might look at testing changing the abort task to an unreserve task to see if the error is less frequent.

Thoughts??

Drew

[Sean_N]

Drew-

It's still not clear to me what modifications you are trying to make to the example, or why you are trying to modify it.  I just want to make sure I understand your end goal and why the example doesn't do what you are trying to accomplish.  Would a state machine help accomplish what you are trying to do?  Any information would help me utilize my resources to come up with a solution.

Thanks!

Sean

[Drew.Rankin]

I am sorry, I will be more clear now. I am working on an application that is more than just the simple sample of code included in this post. I will not be posting my actual code on an open forum so as to protect my customer. 

Without divulging too much about what I am working on, consider the following:

I.  The application is a PC-QSM with several simultaneous threads and relies on call by reference heavily to control data acquisition and maintain UI responsiveness

II. The LVOOP aspect of the application has a class that contains hardware configuration information about various aspects of the attached hardware. I am using the class as a glorified system cluster

III. The typical acquisition is hardware triggered; needs to display data as it is being acquired (via queues); needs to be retriggerable; and react to incoming triggers until the user decides to stop acquiring data. If the user stops the data acquisition, the task shall be killed quickly and sent to garbage collection to allow for re-configuration.

IV. The number of configured channels in the task can vary from 1 to the number of available channels in the hardware. Currently, this is 24 channels; however, the hardware can be expanded to acquire 56 or more channels of data simultaneously.

V. There are four operating modes to the acquisition:

a. Hardware triggered acquisition that is re-triggerable until stopped

b. Hardware triggered single cycle acquisition

c. User triggered continuous acquisition (no hardware trigger assigned)

d. User triggered single acquisition (no hardware trigger assigned)

VI. The above is only a portion of the capabilities of the software; however, the remainder of the software is not relevant to the current conversation.

To get a better idea of what I am doing, think of Tektronix DSO functionality written completely in LabVIEW. No, the built-in NI-Scope code will not work for this application. Please, look beyond the example code and try to imagine how you would build this into a complete application where you want to stop the acquisition immediately without having to wait for the acquisition to timeout, return data as it is being acquired, and accept repeated trigger events.

Now, that said, everything in the software works, INCLUDING the data acquisition; however, occasionally, I am getting a device reserved error (-50103) due to the running task not being cleared properly after being commanded to stop at the end of the acquisition cycle. 

This is very frustrating because when I send the task to garbage collection, sometimes nothing happens. I get no feedback from the Clear Task vi as to whether or not the task sent for garbage collection even existed, or if the garbage collection was successful.

It would be very helpful to have a method that would return the current list of configured tasks for a given device that have been configured during run-time. Currently, the only information I get from the Device task list is any tasks configured in MAX. This information is pretty much useless to me as I really don't care what has been configured in MAX, I would rather know what is running right now in the RTE.

Sorry for the long post, but this bug is really getting me in some hot water. I feel like it is something small that I am not doing correctly and I just haven't figured out how to ask the question correctly to get the right answer.

Thanks for all the help,

Drew

[Srider]

I am having similar problems trying to reconfigure the channels of a DAQmx task during run time as well.

Attaching the VI for reference. Version is LabView 2009 SP1.

The problem occurs when the vi is ran without a channel selected. Even if the user selects a different channel the program exits with DAQmx error -200088.

If the VI is ran with channels selected before runtime, it behaves the way it is expected to.

Ideally, I would like the VI to start with the Channel selection set to empty, and have the user select the channels after the VI is executed.

I suppose if DAQmx task can not be ran without error even if the channel selection is empty, the only approach is to initilize the task only after the user has selected channels in the channel selection control instead of at the beginning of the program, is that assumption correct?

Is this the expected behavior for DAQmx tasks?

[Drew.Rankin]

Srider,

This error is correct, you can not create a virtual channel with a null physical channel.

You could do one of the following:

- put an error dialog to capture the error within the loop

- Skip creating the task if the physical channel is null

- Do not create a task on initialize at all and just create on channel selector change

- Put a channel into the control and "Make Current Values Default" in the edit menu to ensure that something is always in the channel selector. 

Hope that helps.

Drew

[Srider]

I see, thank you for the reply.

Knowing that makes everything more clear now.

Thank you.

Also, I've read the issue you have posted earlier. Just a guess, but have you tried using the "DAQmx Is Task Done.vi"?