DAQmx Start/Stop/TaskControl behavior

[JÞB]

I owe a quick note on how I feel about the Autostart option of DAQmx Read.vi and why I even mentioned it.

I may use the feature or not.  If you look at my description of a DAQmx Continuous Sampling Message Handler you will see EXPLICIT Start and Stop States.  Yet, I do not declare Autostart == FALSE in my code.  I know the feature only starts a Task if an implied transition is necessary and will not throw an error if no DAQmx State transition is needed with Autostart = TRUE.  ALTERNATLY calling DAQmx Read.vi with Autostart = FALSE will return an error if the Task is not already in the Run State.  So I leave it default TRUE and remember it's there if I ever need to force all callers to explicitly transition to run first.  Possible examples include: when exposing my QMH Command loop to dynamically registered User Events I can either tolerate the implied State Transition and accept direct Events that trigger a Read command or Keep that Read Command PRIVATE to my QMH. Either way Autostart default TRUE is my choice.

BUT at other times I may want to configure a Triggered Task, Start it, then let the Caller set up everything else before sending a Triggering Event, followed by a direct Event to Command the Read Message. I would use Autostart FALSE then.  If everyone else writes thier code bug free it will not matter.  But, if an error occurs in the caller that is badly handled I may hang my Task Read waiting for a trigger that cannot happen if I use Autostart. 

Since I am giving a workshop: Here is a quick quiz question to see if you all tracked the info and passed.

Q: Given a DAQmx Task that successfully Transitioned to the Commited State at the output of DAQmx Control Task.vi <State=Commit>.  If  DAQmx Control Task.vi is called again, on the same Task, with <State=Verify> What happens? What State or States can the Task Out be returned in? Why?

Hint: look at the lines in the DAQmx State Transition Diagram.  The class may collaborate. But do not check your answers with code yet!  Use the Help File and Sean N's excellent post.  

[Kevin_Price]

Off-topic response to Bob S:

How did you generate a digital waveform with a USB-6212?   I was under the impression that those devices didn't support hw-clocked DIO.  I'd have thought you'd need to use AO, since you'd likely tie up your counters for stepper control.

-Kevin P

[Bob_Schor]

---

@Kevin_Price wrote:

Off-topic response to Bob S:

How did you generate a digital waveform with a USB-6212?   I was under the impression that those devices didn't support hw-clocked DIO.  I'd have thought you'd need to use AO, since you'd likely tie up your counters for stepper control.

-Kevin P

---

Great catch!  Yes, I did tie up my counter with the Stepper, so I generated two Square Waves (2.5 V with 2.5 V offset, so 0 - 5 V,  played out at 4000 Hz, a "Start" tone of 1200 samples at 400 Hz (0.3 s) and a "Reward" tone of 600 samples at 400 Hz (0.15 s).  What I'd like to do is configure, say, the Reward tone, load the samples into the AO, then "at the right time" start the Tone "as often as I need to" until the end of the test sequence.  During initial training, there is only the Reward tone, but as training progresses and the "tasks" get more involved, we will want to add the "Start" tone to say "get ready to pay attention", and to give a Reward tone if the task is done correctly (and at most one Reward per Task).  So the sequence morphs from R R   R  R   R to T R  T   T R .

Going to now hit the references you and Jay so thoughtfully provided, and see what I can accomplish.  Maybe I'll "post some code" ...

Bob Schor

[Kevin_Price]

When the time comes, start a new thread, I feel a little bad hijacking this one.

Meanwhile, here are some fairly speculative and unwarrantied thoughts:

The efficiency reward comes when the task remains in the Committed state between a Stop and a subsequent Start.  But writing a different sized finite waveform to the task buffer seems likely to "back you up further" in the task state model.  Maybe to Reserved, maybe only to Verified, don't really know offhand.

But there's a *chance* that writing the same size waveform would let the task stay in the Committed state.  (Where "chance" isn't to suggest that it's indeterminate in reality, just that I don't happen to know.)   So you might want to try a reward tone that follows the 600 tone samples with 600 samples of silence, to make the same overall size.

But in all honesty, the difference in overhead for the various approaches may all get buried in the noise in an app that deals with some kind of behavioral response that's probably orders of magnitude slower than the overhead.  Still, doesn't hurt to learn a new trick, maybe it'll pay off better in the future.

-Kevin P

[JÞB]

Writing samples to a DAQmx output Task buffer change the Task State at all. No state change is required. HOWEVER, writing to slowly to a running Task may yield a buffer underflow if the Task Buffer is set below the Finite samples in the Task.
And, of course, if you overflow the buffer DAQmx will throw that error.

Follow Kevin's advice on how to calculate your buffer needs....I do!

[JÞB]

---

@Bob_Schor wrote:

---

@Kevin_Price wrote:

Off-topic response to Bob S:

How did you generate a digital waveform with a USB-6212?   I was under the impression that those devices didn't support hw-clocked DIO.  I'd have thought you'd need to use AO, since you'd likely tie up your counters for stepper control.

-Kevin P

---

Great catch!  Yes, I did tie up my counter with the Stepper, so I generated two Square Waves (2.5 V with 2.5 V offset, so 0 - 5 V,  played out at 4000 Hz, a "Start" tone of 1200 samples at 400 Hz (0.3 s) and a "Reward" tone of 600 samples at 400 Hz (0.15 s).  What I'd like to do is configure, say, the Reward tone, load the samples into the AO, then "at the right time" start the Tone "as often as I need to" until the end of the test sequence.  During initial training, there is only the Reward tone, but as training progresses and the "tasks" get more involved, we will want to add the "Start" tone to say "get ready to pay attention", and to give a Reward tone if the task is done correctly (and at most one Reward per Task).  So the sequence morphs from R R   R  R   R to T R  T   T R .

Going to now hit the references you and Jay so thoughtfully provided, and see what I can accomplish.  Maybe I'll "post some code" ...

Bob Schor

---

Bob, one of us should move/Split the thread.  It's your hijack so it might look cleaner if you did that.  PM me if you can't find the how to on top of the round table.

This old dog might just have some tricks for that use but, it's so far off Control Task.vi behavior that it deserves its own thread.  I'll promise to touch on THIS TOO.

[Kevin_Price]

---

@JÞB wrote:
Writing samples to a DAQmx output Task buffer [doesn't] change the Task State at all. No state change is required. 

---

But what happens if the task is in the Committed state, and you try to write a larger # of samples than the task previously allocated?  Wouldn't the memory allocation be something that takes place during the transition to Reserved or Committed states, so wouldn't you need to back out of the corresponding state when you need to re-allocate a different amount?

Don't have hw available to test, and not inclined to trust behavior of simulated device for this kind of esoteric question.

-Kevin P

[JÞB]

---

@Kevin_Price wrote:

---

@JÞB wrote:
Writing samples to a DAQmx output Task buffer [doesn't] change the Task State at all. No state change is required. 

---

But what happens if the task is in the Committed state, and you try to write a larger # of samples than the task previously allocated?  Wouldn't the memory allocation be something that takes place during the transition to Reserved or Committed states, so wouldn't you need to back out of the corresponding state when you need to re-allocate a different amount?

Don't have hw available to test, and not inclined to trust behavior of simulated device for this kind of esoteric question.

-Kevin P

---

Buffer overflow error. 😞 if the current buffer can't hold that many samples.  Writing samples to buffer requires no state transition and will never cause one.

The developer needs to back the Task State down and reverify the new buffer configuration settings if a larger buffer is needed. 

Or nothing, if the buffer has been set up already with enough space to hold the new, larger sample size.

The buffer is allocated in the unverified state.  If the allocation is within the device capabilities a transition to Verified produces no error The Resouces needed (fifo memory etc...) must not be needed by any other Reserved or higher Task to obtain the lock (or reserve throws an error) Commit is not likely to error but can happen if the device is physically no longer in the same place it was.  Ditto The Transition to Run.  Those "...,or device no longer present..." errors can occur with USB devices when Windows Power Management shuts of the device or Joe Dinghead takes your device while you did a Coffee++ loop iteration.

Yes, I worked with Joe.

All others, Kevin is cheating on the quiz! 😀