LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Overwrite continous output buffer

Hi, I have written a program in LabVIEW 2014 to generate an arbitrary waveform with a cDAQ 9178 and a analog output module NI 9263 (for now simulated). It is performing already what I want, but i want to add one more function. This is the option to stop the signal at any moment and returns with a ramp to zero Volt from the value it was when the stop button was pressed. But therefore I need to overwrite the samples in the buffer, because the complete signal is already written to the module in 4 iterations (for the signal in the vi)(and the signal is 35 seconds, so this takes far longer than the loop). How do I do this? I already searched for some examples but I am not sure if this works.

 

Examples: 

https://forums.ni.com/t5/Multifunction-DAQ/How-to-overwrite-the-output-buffer/m-p/1803060?profile.la...

https://forums.ni.com/t5/Multifunction-DAQ/Clear-Analog-Output-Memory/m-p/2475840?profile.language=e...

 

Is this possible? 

 

I hope that the issue is clear. Thanks in advance

 

Willem

0 Kudos
Message 1 of 8
(2,937 Views)

A controlled gentle ramp back to 0 won't be trivial.  Let's talk through more details of your app to figure out a reasonable approach. 

 

- What drives this requirement?  What makes it important?  For example, why is it bad to simply make a single sudden step to 0?

- What is this AO signal causing to happen out in the physical world?

- What further specs or constraints do you have?  (Max time to return to 0?  Max slope during return?)   

 

The smoothest kind of return may require you to run your task with minimal buffering, which further requires lots of timing-critical interactions and puts you at a greater risk of buffer underflow errors, which would *also* leave you stuck with a non-zero output voltage.

 

So, as in many (most?  virtually all?) engineering tasks, there will be tradeoffs between the speed and quality of the return to 0 and the risk and difficulty of implementing it.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 2 of 8
(2,903 Views)

Hi Kevin P,

 

Thank you for your reply! Why this is important is because this signal eventually controls a hydraulic cylinder. This is controlled via a PID-controller. This is why it is not desirable to do a sudden step to 0. I hope the purpose because clear with this scheme:

WillemNL_0-1587559224746.png

 

For me it is more the question: how do I remove the samples I already have written to the module so I can get back to zero with a ramp. I have already built in the ramp with this part in the vi:

WillemNL_1-1587559738463.png

 

 

Willem

 

 

0 Kudos
Message 3 of 8
(2,894 Views)

So your AO task is creating the "Desired Force" setpoint in the figure, right?   And the PID controller is an external device separate from your code?

 

If so, then I would *guess* that you could live with a brief time holding at your last generated AO voltage before the ramp to 0 started, right?  That would make things quite a bit more straightforward.

 

Then all you really need is a way to know what output voltage you left off at.  Two options there:

1. Loop it back to an AI module and measure it after stopping your AO task.

2. Keep careful track of the history of data written to the task.  Then use knowledge of the # samples actually generated by the AO task to lookup the voltage you must have left off at.

 

The first method is simpler and more certain.  That's the approach I'd aim for, even it meant needing to buy an AI module.  (I'm supposing that the concern about a step change in force setpoint is due to the possibility of physical danger to humans or equipment.  The cost of an AI module could be pretty cheap insurance.)

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 4 of 8
(2,879 Views)

Hi, 

 

Exactly, the PID controller is an external device. I have access to an AI module so that is not the problem. The concern has just ordered an AO module but it is not been shipped yet, and that is why I want to make sure that my vi is doing what it suppose to do. When it has arrived I will try the first option.

 

So, you say that I just have to try my vi's, right? 

 

Willem

0 Kudos
Message 5 of 8
(2,873 Views)

Fear not, the stuff you're gonna be doing is pretty straightforward as DAQ goes.  If all this stuff is pretty new for you, I'd recommend the following:

 

When you get your AO device, test your code *without* the hydraulic cylinder & its controller.  Just *observe* the output signal.  Try out these ideas for ramping to 0 for a while to build confidence.  Or come back here with questions (and code!) if you run into trouble.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 6 of 8
(2,862 Views)

Okay I will let you know!

0 Kudos
Message 7 of 8
(2,803 Views)

It works! (with a few adjustments)

0 Kudos
Message 8 of 8
(2,761 Views)