Buffered Analog Outlout

[bmann2000]

Hi,  I load an array of Analog Output values to a PCI-6341 that are clocked out by pulses from an external source.  However, say I load a 100 element array, sometimes I may have 101 pulses rather than the desired 100 pulses.  The extra unwanted pulse results in 10volts from the Analog Output which is a disaster for the process under control.

Is there a method to ensure extra pulses result in 0volts ?

[IanSh]

Perhaps I'm thinking too simple, but can you just append some 0s to your array?

Maybe it depends on whether this will cause a new problem of having a 105 element array, but only 100 pulses and your task not finishing? You could always stop the task at this point though to solve that.

[bmann2000]

I'm appending zeros at the moment as a work around.  The problem I have is that during software development there's often an erroneous extra pulse and sometimes there's not a zero in the buffer ready to soak it up, this results in damage to the material I'm processing, the Analog Output drives an energy level.

Eventually I'll fully debug the source of the extra pulses and the issue will be solved.

I usually request voltages between 1 and 6 volts, I never request 10volts, so where does the 10volts value originate from?

[Kevin_Price]

I would think that if you configure the finite task for 100 samples, the task would end at the 100th external pulse and ignore any subsequent pulses.  Most devices will keep holding the most recent AO value though, even after stopping the task.  If you want a neutral 0V output to be present after finishing the task, you'll probably need to code that explicitly.

Can't really guess why AO puts out an unexpected 10V.

-Kevin P

[bmann2000]

Thanks for the reply Kevin, I'm still trying to debug the system.  Do you know if there's a DAQmx command to clear the buffer?  I think that sometimes all the values are not clocked out, then when I load the next array it's appended to the values already in the buffer.  If I could query the buffer size or purge buffer it may help for debug.

[Kevin_Price]

1. If there's time available, you can call DAQmx Clear to clear the task, which will include clearing the buffer.  You'd need to reconfigure the task before starting again.

   This would definitely work, but will be relatively slow.  I'd plan for something roughly in the order of 100 msec.

2. If you're still doing Finite Sampling, calling DAQmx Stop will *probably* be enough (can't test right now).   It'd also be a good idea to make sure that the # samples you send to DAQmx Write is the same as the # samples you specify in DAQmx Timing.

  I *think* I recall that if you leave the # samples unwired on DAQmx Timing when setting up Finite Sampling, the first call to DAQmx Write will define the buffer length to be the same as the # samples you write.  I do not know how this behaves across a task stop / start if your next run wants to write a different # samples to the buffer.

-Kevin P

[ben64]

We can't see from the picture what is the value wired to the samples per channel input of the DAQmx Timing.vi. Can you confirm it is set to 100?

Ben64

[bmann2000]

I'm machining lines, number of pulses varies with every line.  Clear does work to stop the analog output but is too slow to prevent damage.  My problem is not with the DAQmx as such, chances are it behaves as expected.  The problem I have is that the card does not always receive the exact number of pulses required to clock every value out of the buffer, or perhaps it receives more pulses than expected.  It would would be useful if I had some type of feedback of number of elements remaining in the buffer, or an indication the buffer was empty.

[Ben]

A Write node will let you check the buffer, total sample generated...

Ben

[JÞB]

Its Likely that there is an external pull-up to 10V and the Idle behavior is HighZ.   With that X series device you ARE able to play with these properties: