Why does the output buffer not seem to be clearing with Clear Task?

[dbmeor]

I am generating a sinusoidal waveform that I then differentiate and output on an analog channel as a voltage using Daqmx commands.   I control the continuous generation using a while loop and a boolean control to enter/exit the loop.  If I run a waveform with a given amplitude, exit the loop using the boolean control, modify  the amplitude by a significant amount, and re-renter the loop to ouput the new waveform, I get a large spike in the differentiated signal.    It seems  to me that the last point from the previous loop iteration remained in the buffer and was used in differentiating, possibly giving results approaching infinity.  If I stop and restart the VI I can not duplicate the error.  I am using the Clear Task VI upon turining off the Boolean control and exiting the loop. 
Any thoughts?

Thanks

Dan

[stilly32]

Hey Dan,

From your description it seems like you're differentiating in SW - is that correct? Or are you using some analog circuitry? In either case, you could possibly be trying to differentiate a step, which could produce those results. From your previous posts it looks likre you're using a USB 6211, if you try to generate a value outside the range of that device (+/- 10v) it should just throw an error - have you monitored the results of the differentiate function to ensure that they match up with what is actually generated?

If you're using some external circuitry, the last value generated by the device when clear task or stop task is called will continue to be generated until a new value is written or the device is reset - this could very well be what you are seeing. That last value could be any of the points along the sine wave, and a larger increase in amplitude would increase the likely hood of a larger step. There are  couple ways you could deal with this. Instead of starting/stopping the task, you could just write a new buffer with the new amplitude. You can add a DAQmx Write to the while loop in the Cont Gen Voltage Wfm - Int Clk.vi to write new values when you desire. You would want to make it phase continuous but that isn't too hard - by default all new writes start at the beginning of the buffer. You could also just ensure that the generation ends at 0 - just perform a DAQmx write with an array of 0's after exiting the loop, wait a short time for that array to fill up the buffer, and then close the task. Again, the write will start at the beginning of the buffer so it will be a smooth stop of your buffer ends on a 0.

If this doesn't help, please post a more broad description of what you are trying to do with some more details - when I see differentiate a sine wave" I just think how much easier it would be to generate a cosine, but I'm guessing there is more to it than that  It would also be good to know what OS and ADE (I'm gathering LabVIEW (version?) from your descriptions but I could be wrong) as well as what HW.

Cheers,

Andrew S  

Message Edited by stilly32 on 10-19-2007 12:19 AM

[dbmeor]

I'm going to try to digest your reply.  I'm not quite sure what you meant by "differnetiating in SW".  I am generating a sinusoidal position waveform based on a given amp. and freq.  This wfm is to be differentiated and output as a voltage on my usb-6211.  I see a step in the position waveform, which then translates into the spike in my velocity (derivative) curve.  But why is this step even there?  I don't kno why it would be connecting the last point of the previous data set with the first of the next.  When the "Run Wave" boolean is turned off, the task is stopped.  See my attached pics of the code and ouput results.
Here is how I achieved the error:

1.  Fr = 1, A = 1.0
2.  Turn on Run Wave
3.  Turn off Run Wave
4.  Fr. = 1, A = 8.0
5. Turn on Run Wave


Here is data from the last position waveform generated and from the differentiated waveform:

9.75                 -6614.125875              -8

9.75005           0.047773                     -8

9.7501             0.048519         -7.999998

9.75015           0.049265         -7.999996

9.7502             0.050011         -7.999994

9.75025           0.050757         -7.99999

9.7503             0.051503         -7.999986

9.75035           0.052249         -7.999981

Thanks

Dan

Message Edited by Dan ME on 10-19-2007 01:31 AM

[stilly32]

By "differentiating in SW" I mean taking the derivative in software like what you are doing with the Time Domain Math Express vi. The issue is not with DAQmx or the buffer's its with the values you are sending it. You'll notice this jump in your Position, almost a full cycle after you change amplitudes :

which is leading to your large negative spike in the Velocity (Cm/s):

I'm not sure how you are generating that - when I run through your procedure I only get the step when I change amplitudes. I've attached the VI I use to repeate it. When it comes down to it, anytime you have a sharp edge or a step and you take the derivative you're going to have a spike. to remove the spikes, you're going to need to smooth out those discontinuities (possibly a filter) or find another way to generate the derivative (a phase shifted sine wave would be a good approximation).

Hope this helps,

Andrew S.

Message Edited by stilly32 on 10-19-2007 10:49 AM

Message Edited by stilly32 on 10-19-2007 10:49 AM

[dbmeor]

Andrew,

First off...thanks for the help.  I'm always impressed at the quick responses and interest in solving problems on the forum.

So I also only get the step when changing amplitudes.  I understand that it is trying to differentiate a step and that is teh spike I see.  My confusion is that when I change amplitudes, and run again, a new waveform is created and the first point in the position waveform is that new amplitude.  This new waveform has no data point from the previous amplitude wave and this is the data being differentiated.  How does the differentiation function handle this first data point.  If dx is defined by df - di then what is di (initial x value)?  Is it referencing the last point of the previous waveform?
If I stop and restart the VI between amplitude changes this problem does not occur, only when I turn on/off the boolean.

I have solved this problem by ignoring this first point in the differentiated waveform when I go to send the data to the output channel but I'm still trying to figure out why this happens.

[Neal M]

Hi Dan,

I have looked at your problem as well, and I would say you are correct with the assumption the issue is with the way the derivative is calculated, especially for the first point.  Since it does not have a "previous point", there are some issues in calculating the slope.  I wrote a basic vi to see what affects this (screenshot of the code attached), and discovered that if I write one period of a sine wave, then I did not get a spike in the derivative for the first point, just a step rise from zero:



However, if I shifted the phase of the sine wave at all, then I got a large spike:



I am not sure how the vi handles this first point,  but due to the formula it uses, no matter what it assumes for the n-1 point, then this first point will not be valid data.

Message Edited by Neal M on 10-19-2007 03:36 PM

[stilly32]

If you open the front panel (right click >>Open Front Panel") of the derivative express vi you'll see how it gets it's previous points - it relies on the last point of the previous waveform if Continuous Mode is chosen. It automatically resets when you start/stop the vi (thanks to the First Run.vi) which accounts for the difference.

You can either use that vi with the settings changed and throw out the first point, or just modify the opened front panel to suit your needs.

Hope this helps,

Andrew S 

Message Edited by stilly32 on 10-19-2007 04:08 PM

[dbmeor]

Andrew,

O.K., I had a look at the derivative express vi and figured that was what it was doing.  I don't quite follow your solution.  What do you mean by "You can either use that vi with the settings changed and throw out the first point, or just modify the opened front panel to suit your needs" 

If I run in Continuous or Per Segment mode I still have to throw out the first point and I don't folow what to modify on the opened front panel?



Dan

[dbmeor]

And where do I find the First Run.vi?

Is it something I can call when I want to mimic a restart?

Dan

[stilly32]

Hi Dan,

What I meant to say is that you can use the "Continuous" or "Per segment" operations and change the output data from the express vi (by throwing out or reducing the values above/below a certain point) or you could open the front panel and modify the code such that it will never actually generate values above a certain range.

I always for get where the "First Call?.vi" is too, you can find it by searching the functions - it's under the Synchronization pallette. Just capping the values of the output would work, you could also do the math and just generate the signal from that ie d(sin(u))/dx = cos(u)du/dx. If you go about it that way you can just change the generated signal, and ignore the sharp edges. I'm not sure that I know enough about your application to say if that is a valid solution though.

Cheers,

Andrew S