Deleting channels from task, reconfiguring task

[Drew.Rankin]

I am using that VI to determine when the inner loop should be done. If you look at the code in the IDE, you will see this in the "No Error" case.

[JÞB]

Drew Wrote:

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.

---

That's certainly going to rewrite a lot of the TASK properties in a very dynamic manner.  Thinking out loud --- I've never reconfigured a task so many times and ways but in THEORY it is possible and should not be a problem if you didn't hit a untested use case (found a bug)

It still sounds suspiciously like DAQmx is not releasing the resource occainsionally.... Is the DAQmx 9.1 or newer? if not, upgrade immediately. there was a bug in some of the read vi's related to resource release after acq complete- it "MIGHT" be related since its dealing with the same area. 

If you have the latest driver version- maybe there is a corner case that didn't get handled.  Is there any additional info- like after switching from continious to finite samples?  we may need to to some serious investigation to reproduce the error repeatably.

[Drew.Rankin]

Jeff,

I am using LV9.1 with DAQmx 9.3, I haven't ported this application to LV10 yet (outside of a test build a couple weeks ago) as the customer is still on LV9.1. The application is running from the RTE via an executable file.

I have noticed the error when going from continuous to single acquisition, but can not reliably force the error to occur.

Your suspicions are correct, DAQmx is not releasing the task resources correctly on occasion and I am hunting for a work around. I found something in the knowledge base that I am trying today. The posting is from LV7 and is located here (http://digital.ni.com/public.nsf/allkb/485201B647950BF886257537006CEB89?OpenDocument).

Based on the above document, I just found another post (http://forums.ni.com/t5/Multifunction-DAQ/How-to-query-DAQmx-task-state-in-LabVIEW/td-p/1515460) that talks about using explicit task state control; however, they do not address garbage collection in that post.

There was a mention of starting a "Get Task State.vi" thread in the Idead Exchange, but they are looking for a champion. I am considering championing that as well as a method to query the DAQmx driver to list the currently configured tasks by device.

Drew

[JÞB]

I have noticed the error when going from continuous to single acquisition, but can not reliably force the error to occur.

After first verifying in single I bet:::::-- Follow me here:

The State Transition model implicitly verifies finite tasks that have been in run and then had a property change and does not EXLPICITLY verify the task until it the next state transition.

As explained in the help file

"As another example, suppose the task is in the Reserved state, and you call the Read function/VI to perform a finite measurement. This results in the task implicitly transitioning from the Reserved state to the Committed state and then to the Running state before performing the read operation. When the read operation completes, the task does not remain in the running state. If this were the case, the result is unexpected behavior, because you need to stop the task and unreserve its resources despite the fact you never explicitly reserved the resources or started the task. Instead, after the finite read operation completes, the task is implicitly transitioned from the Running state to the Committed state to the Reserved state. This results in the task returning to the state before you performed the read operation"--- WHOA! now we KNOW that the state transitions ARE handeled differently depending Cont/Finite!!!  AND the resources are released differently.

Reviewing the State Model from here

And the reverse transition state goal of returning to previous with implied reverse transitions

We see that depending on Finite/ Continious we can either wind up in Verified or Reserved states when a task stops.

From Verified a setting a property explicitly transitions back to unverified and the task is reverified then.

From Reserved setting a property implicitly erifies the task and the task stays reserved.

FOR FUN:

Try "abort task" before changing properties to explicitly unreserve resources!  Let me know

[Drew.Rankin]

Jeff,

I had tried the abort task and it seemed to fix the problem. Then I took the system to the customer and the bug returned with a vengeance, can you say embarrassed!?!?!

Also, when I state that I can run in continuous mode, I mean that the task is looped as a finite acquisition with hardware triggering. Therefore, every mode of operation is a finite acquisition, it's just that some modes do not have a hardware start trigger defined and would run in a pseudo-continuous acquisition mode.

When I get to the customer with my new build this afternoon, I will post the results of the changes I made and post summary code here (if the work-around works). I might even post it as a document to incorporate other white papers that I have read concerning this situation for others to learn from my pain. 

Drew

[JÞB]

GOOD LUCK!

I'll keep my fingers crossed for you

[Drew.Rankin]

Ok, so the fix didn't work completely. I still get the occasional -50103 or other task reserved/resources reserved error in my application. AAAARRRGGGGGHHHH!!! As Charlie Brown would say!

What I did notice was that if I explicitly name a task at create task, I can never have a task with the same name until after I close the application completely. I have tried setting auto clean up to both true and false with the same result. This happens every time without fail. Therefore, I do not name the task and things seem to work OK.

However, even with each created task being uniquely named, I still get the reserved error sometimes.

Below is my sequence for data acq (psuedo-code):

Main Thread:

If previous task exists

Set to Unreserved

Clear Task

 Endif

Create task

Create Channels (using channel list from DAQ.lvclass)

Set Timing Config

Set Trigger Config

Call DAQ loop by ref: (Start acquiring data in a spawned thread) -- TaskID is passed to DAQ loop via DAQ.lvclass

  Set Task to "COMMIT" <---- This improved asquisition performance greatly!! I am sold on using this in re-triggereable acquisition loops

While Acquire Data == True AND AppStop == FALSE AND DAQStop == FALSE

Start Task

Read Data

If Read Data.Timeout == True

Ignore error

Else

Send data to queue for processing in the main app data processing and display threads

If Task is finished

End While

EndIf

EndIf

Stop Task

WEnd

Set Task to Unreserved

Clear Task

Process Errors from DAQ sequence

Return to Idle State

This sequence will be called each time a new configuration is loaded.

Below are the code snippets:

Create and run task by ref from main app:

InitAITask:

TimingSetup:

RunDAQ:

ClearAITask: (Run on InitTask):

That's about it. This code is basically what is found in the AI continuous acquisition examples with a few added features to help me manage different channel configurations.

Thoughts?

Drew

[JÞB]

Nice looking stuff.

Two questions:

1) in timing set-up you are changing the task, why did you not chose to write the task back to the task FGV?  

2) in the run vi, what happens in the error case? and can that cause the task data on the input tunnels of the loops to be disconnected from the real task state?  What happens if you replace w/ SRs?

[JÞB]

Maybe we can get a app eng to "Pop-the-hood" about exactly what runs down the Task Wire.  is it the task data or is it ref to the location in memory that contains the task data?

[RavensFan]

---

@Jeff Bohrer wrote:

Maybe we can get a app eng to "Pop-the-hood" about exactly what runs down the Task Wire.  is it the task data or is it ref to the location in memory that contains the task data?

---

I always figured it was a reference to the task, since it is purple like a lot of other resources (VISA, Fieldpoint I/O, Shared Variable)