Stopping a DIO Digital Output task to end in a defined/safe state

[MrSpanman]

I am using a USB-6341 X-Series Multifunction DAQ to output HW timed continuous digital command patterns.

I am using LabVIEW 2015 but I think this is a more general query on the the X-series DAQ or DAQmx in general.

Using one of the LabVIEW examples (Digital - Continuous Output.vi) I can configure to output a HW timed pattern to send digital data out of the required port.

Running the DAQ Digital Output in "continuous samples" mode it can loop and repeat my short pattern continuously fine.

However using the "DAQmx Stop" operation seems to stop the pattern anywhere in the data from the FIFO buffered output rather than at the end of the last loop iteration of my short pattern. So the final command line states can end in any logic combination.

 My application needs the pattern to end in a defined safe state (e.g. all output lines logic0).

Does anyone have any experience of how this might be achieved?   

[Kevin_Price]

Here are 3 options to consider:

1. Can you configure for Finite Sampling?  Then you could define your total # samples and make sure to end on the desired state.   By default, the task will regenerate the short pattern you write until it reaches the defined # samples.

2. If you don't know in advance how many samples you'll generate, you could stop your Continuous task at whatever unknown state, write a buffer full of your desired pattern to the task, then start and stop the task (maybe with a tiny delay in between if you have an unusually slow sample rate).

3. The classic approach would be to configure your task to disallow regeneration (using a DAQmx Write property node).  Then you'd need a software loop that writes data to the task at the same overall bandwidth as it's being generated.  (Note: this does NOT mean you iterate at the sample rate while writing one sample per iteration.  One might typically iterate at 10 Hz and write 1/10 sec worth of data per iteration.)

    Then when you're alerted that it's time to stop your task, you make sure that the last data you write to the task ends with the desired final state.  Then you need to wait until the task throws its buffer underflow error, ignore it, and stop the task.

    It's more complicated to manage than the 2nd approach and *probably* induces more latency as well due to the buffers between your app and the signal.  It's mainly worth considering if you care about not only the final state itself, but also the entire final trajectory that leads to it.

-Kevin P

[MrSpanman]

Thanks for the reply Kevin.

I do need finite sampling times elsewhere, I have tried this and it works great. Obviously I just make sure that my short looping pattern ends in a safe state and all is good. However I do also need a continuous pattern that will be run during manual test operation and needs to be started and stopped asynchronously by something like pressing a SW button.

For my application a typical command state lasts 10's of uS. I did try option 2 and this gives me a fixed @50mS unsafe state at the end of my pattern, this is an issue for me as this will cause my DUT to overcurrent and shutdown, as an unsafe state is only allowed to exist for 100's of uS max.

I figured that maybe it was the regeneration/use of board memory that made a configurable interrupt not possible. I am guessing that it wont be possible to run at xMHz to feed the buffer with regeneration off, although I may have a bash and see what it can do (although my states last 10's of uS, I need a resolution that is in the fractional uS, so am currently using a 10MHz clock). 

I was kind of hoping there might me a Stop trigger or something similar, as I found Start trigger functions in the manual but I am guessing maybe this isn't a thing as I haven't come across it.

What do you think about creating an asynchronous output on a separate DAQ DO port (I assume I can do that while the HW timed stuff runs) and use this and some HW logic to enable/disable the HW timed patterns via a SW pushbutton, followed by a "Stop DAQmx task"?     

[Kevin_Price · Accepted solution]

Option 2 could likely be sped up quite a bit by using the DAQmx Task State Model to your advantage -- but I don't think it'll get you to the sub-msec reaction times you're after.

I'd be optimistic about 10 MHz sustained output with regeneration turned off if you were using a desktop PCIe X-series board, but significantly less so over USB.

Here's what I'd probably do if I had a spare DO line available on port 0:

- include the spare DO line in your task

- physically wire it to a PFI terminal

- set it ON whenever you have a safe DO state, OFF at all other times.

- configure a counter to create a triggered single pulse, reacting to a rising edge on the wired PFI terminal.

- configure your DO task to use this counter's output as a Pause Trigger, pausing when high.

- I'd set initial delay and low time to 10 microsec and set high time to an absurdly long time like 60 sec.  (This is an attempt to make DAQmx use its 100 kHz timebase rather than the default 100 MHz timebase).

How it works:

Run the continuous DO task the normal way, allowing regeneration.  (Perhaps you can also configure to use only onboard memory to avoid the need for high speed USB data transfer?).  At some point you become aware that you need to stop the DO generation safely so you *then* start the counter pulse task.  The task will be triggered by the next rising edge, which will come just as the DO pattern has reached a safe state.  After 10 microsec dely, the output will go high, effectively pausing the DO task and freezing the output in its present safe state.  

   Wait long enough to be sure the triggering has happened, then stop the DO task first and stop the counter task second.

-Kevin P

P.S.  On second thought, you'd probably be fine setting your counter's initial delay / low time much lower (but not lower than 20 nanosec), and then reduce the high time a bit to avoid 32-bit rollover.  With the default 100 MHz timebase, this would occur at ~2^32 / 100e6 = 42.95 sec.  I imagine a 30 sec high time would still be plenty of time for your software to confirm the pause and stop the tasks...

[MrSpanman]

Yes I think I understand the idea. I will take a look at doing this as you suggest. Thanks. 

[MrSpanman]

Hi Kevin, When I came to actually implement the counter configuration it took me a while and to get it straight in my head and then to find out how to implement the counter, set-up the trigger etc. but now your solution works great. Thank you for your help.