Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Help understand correlated digital output problem

Hi,

 

Please consider the attached VI. Since the digital output tasks use /Dev1/ao/SampleClock as their timing source, I would expect that if the ao task (also using /Dev1/ao/SampleClock by default) fails to start, due to a resource conflict because another VI is using Dev1/ao2:3 (although not, in this case, using /Dev1/ao/SampleClock), then the digital output tasks, although started, would not receive any clock ticks from /Dev1/ao/SampleClock since, I would assume, that timing source is controlled by the ao task. Therefore, I would expect that the while loop will stop because of the error on the ao task and then all of the tasks would be halted and cleared without any updates being generated.

 

Unfortunately for me, that's not what happens. Somehow, the digital output tasks do generate updates and if a line goes high near enough to the start of the waveform, then it can stay high much longer than was intended.

 

e.g. If I set the rate to be 10k S/s, and input waveforms that set Dev1/ao0 to some value for 1s starting at t=0, set Dev2/port0/line26 high for 3ms at t=2ms, and set Dev2/port0/line31 high for 3ms at t=50ms; then if I try to run FinitePulse.vi while another VI is using Dev1/ao2:3 for continuous hardware timed output (using /Dev2/ao/SampleClock as the timing source), then Dev2/port0/line26 winds up going high for anywhere from 20ms or so, to a couple of hundred ms or so.

 

This is dangerous for our application because the digital lines control relays that switch external voltages that can damage our leads if left on for too long. I'm sure I can find some workaround to avoid damaging our equipment, but I would like to understand, if possible, why the digital tasks generate any updates at all if the ao task fails to start.

 

Any insight or advice would be greatly appreciated. Thanks in advance.

 

Ron

 

0 Kudos
Message 1 of 2
(2,447 Views)

I would suggest to create a kind of dataflow from the creation of the AO Task to the creation of the DIO Task. This means that you should use the error flow to determin that the AO configuration starts befor the DO Task is getting configured. So if any errors occure during the AO config the DO wont start.

 

Hope this helps,

Christian

0 Kudos
Message 2 of 2
(2,437 Views)