Showing results for 
Search instead for 
Did you mean: 

Change/Add digital data to task mid stream?

Say I have 12 digital channels in one task, and any number of them may be outputting a digital waveform.  Is there a way to add/change/remove digital data to/from any of the active or inactive channels without interrupting the data already being outputted?
0 Kudos
Message 1 of 10



Do you want to remove data that the inactive channels have already acquired?


Ipshita C.

National Instruments
Applications Engineer
0 Kudos
Message 2 of 10

well, more like i'd like to add data to channels within that digital out task, while the task is running a waveform.  so say within one task, channels 1-4 are just low, and 5-8 are outputting a waveform.  is there a way to output a waveform on 1-4 while 5-8 are running, without stopping the whole task?  note, im not acquiring any data, just outputting digital data.


my application is this:  a number of channels may have a long waveform that modulates an LED, and others would be sending digital data in SPI or I2C form, getting its data from a PID controller.  this data would then need to be updated constantly, while the LED waveform remains uninterrupted.  i can't seem to find a way to maintain continuous data output from the LED channels while updating the SPI/I2C channels without interrupting the whole task.

0 Kudos
Message 3 of 10



This implies that you would like to achieve digital input and output in the same task, if I understand correctly. That is not something that is available within the current programming parameters but you can definitely separate out your digital acquisition and generation in different tasks and run them in one VI. Hope this helps!


Ipshita C.

National Instruments
Applications Engineer
0 Kudos
Message 4 of 10



Have you tried using non-regenerative operation of your task?  You have to continually feed it data as it runs, but it does allow you to change a single channel output without changing the others.  Here's a quick example I threw together for doing exactly that.  This should give you the general idea.  By the way, you can find very similar code to this, generating analog outputs instead of digital, in the shipping examples that come with LabVIEW.



Message 5 of 10

ipshita, ive built the apis for the spi and i2c such that i wouldn't need to acquire.  i realized i couldn't do that, but managed (i think Smiley Happy ) so far to avoid digital input.


dianes, thanks for the reply, i'll give that a shot.  would this imply that i'd be limited to software timing instead of a hardware clock?

0 Kudos
Message 6 of 10

Not at all.  Note that the example I posted uses the sample clock as the hardware timing source.  If I were using software timing, I wouldn't have configured a hardware clock.  Also, you can't run a waveform data type unless you're using hardware timing -- the waveform data type and software timing are mutually incompatible.


Give it a try and post back if you run into trouble.  I've used this technique many times for changing analog output waveforms "on the fly", and it works like a champ, so I think it will do exactly what you want it to do.



0 Kudos
Message 7 of 10

I know this is a super old post but I thought it's better than to open yet another thread on a similar topic...anyway here goes:


say if I'm only writing booleans to digital output of the DAQ device i.e. true/false, would I still need to use the 'Do not regenerate' property node? Or is it possible to overwrite it without stopping and starting the task again?


Thank you!

0 Kudos
Message 8 of 10

In LabVIEW, a task will be "software-timed" (a.k.a. "on-demand") *UNLESS* you configure a hardware sample clock, typically via a call to DAQmx


IF your task is software-timed, you can configure and start it once, then write True or False to it repeatedly, any time you want, without stopping and restarting the task.


A non-regenerating "hardware-timed" task would require regular care and feeding.  You're still able to vary the output, but there is typically latency (due to buffering) and your app is required to keep feeding data to the buffer fast enough to keep the buffer from emptying.



-Kevin P


Message 9 of 10



Yeah, I just realised through trial and error that works. It turns out the Write property node for regeneration doesn't work because my USB-DAQmx device apparently does not support it

0 Kudos
Message 10 of 10