From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Sine Wave Voltage Output Dependant on Voltage Input (Derivatives)

Hey guys, hope you're all safe and sound.

 

I have a question regarding NI-DAQmx (my device used is NI USB-6341 together with LabVIEW 2016 Version 16.0) and LabVIEW.

I'm using LabVIEW to generate a voltage output, while also reading voltage input from an input channel.
Without going into too much detail, I'm basically applying an electric force (using my voltage output) to a mechanical system, measure the position/amplitude of my mechanical system, and then I want to feed this information back into LabVIEW, because the amplitude of my output should actually depend on the current state of my mechanical system.

 

Here's what I want to to step-wise:

 

  • Simulate and output a Sine wave of a specific frequency and amplitude (this will drive my oscillator)
  • Read input voltage signal (representing the amplitude of my mechanical oscillator)
  • Calculate the derivative of my acquired signal, multiply this by a constant and then add (subtract) this to the amplitude of my sine wave


I'm not really looking for code, I'm just looking for a basic strategy. Even though I'm very new to LabVIEW, I have already played around with a couple of VIs, watched some videos and checked some of the example projects in LabVIEW. I guess the main questions I want to ask are the following:

 

  • Should I work with datatype DOUBLE to be able to calculate my "derivative" dy manually for every sample? Or should I just work with the Waveform datatype and use the "Derivative x(t).vi" to get the derivative of the whole signal? Of course, this question about datatype applies to Input and Output. If I'm reading N samples, I would therefore also have to write N samples because of the interdependent relationship I have between my input and output. Do I basically then just work with, let's say, 1000 data samples per loop? And those will just all get "refreshed" in the subsequent iterations of my while loop s.t. I can have a "live" graph of my amplitudes and also vary my damping on the fly?
  • How and where would I then add my damping to my signal? I'm not really experienced in working with multiple samples (see below) at the same time. In the end, it's just an array full of samples, right? But my damping term that I want to add to my sine signal is always dependent on the derivative (it can of course also be 0. This would mean I'm just creating a standard driven oscillation)
  • How do I make sure that I do not "lag"? Let's say it takes 0.5 ms to read N samples of my oscillator's position. By the time I have finished reading those and calculated the derivative(s) of my signal, my oscillator will already be out of phase. It doesn't wait for me to finish my calculation and output the correct voltage. Any ideas about how to solve this problem, if this actually is one? Of course, I want to continuously output a sine wave, but I still need to add/subtract my damping term the correct way.

 


Every comment/idea is welcome. There are definitely some things I'm unaware of in LabVIEW, so I might think about this totally the wrong way. Let me know.

 

 


What I have tried:

For starters, I have tried to realize this with a constant voltage output instead of a sine wave.

 

  • Have a while loop that reads one sample per iteration
  • calculate the difference between sample (i) and sample (i-1)
  • multiply this by my damping coefficient
  • output the calculated value


So I'm basically working with DOUBLE as datatype and one single sample per while loop iteration. I can then plot the amplitude of my oscillation over the index of iteration. So if I collect 10 samples, my X-axis would just be 1,2,3,4,5,6,7,8,9,10, whereas my Y-axis is the voltage I have measured in the respective iteration of my while loop.

 

I realized that this is definitely not ideal, because my while loop iterations are taking a bit too long have different times in general (ranging from 0.0001s to 0.002s) I can almost certainly not use this VI and just add an additional SINE wave as my output, because I wouldn't really know what value my SINE wave should have at what iteration of my while loop. And it would not really be possible to emulate specific frequencies for my Sine wave.

 

I hope this is not too much text. Providing you with screenshots wouldn't help much here, in my opinion. I would be very grateful for any sort of advice/hint/suggestion. Thanks and have a great and healthy week 🙂

0 Kudos
Message 1 of 3
(1,223 Views)

I just ran across this previously-unanswered question.

 

First, thanks for a nice thorough first post.  That's a big head start in the right direction.

 

Second, I've got bad news for you.  You're tackling a pretty difficult problem in real-time mechanical control for which Windows, USB, and buffered input & output are not particularly well-suited.  You've got all three working against you so you may not be able to "get there from here."

 

Your concern about "lag" is exactly the crux of the problem and it will be most pronounced for your buffered output signal.  It will never be 0 and is unlikely to get low enough (or consistent enough) for you to establish the degree of control you're after.

 

 

 

What kind of mechanical oscillating system are you dealing with? 

What's its natural frequency when oscillating?

What kind of feedback sensor are you using?

In plain words, what are you trying to do?  In other words, how would you describe the way you want your feedback control loop to work if you were talking to someone with very little technical background?

What's the overall purpose of doing this control -- what do you hope to observe and learn?

What excitation frequency do you intend?

What is your intended/desired control loop rate?

 

I'd recommend you do a little basic tinkering with your system using *unbuffered* input and output.  This is your biggest point of leverage for reducing lag.  You still have the timing uncertainty of Windows and the USB bus against you, but there isn't much you can do about those.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 3
(1,155 Views)

Hi,

 

crosspost in German www.labviewforum.de!

 

(We came to the very same conclusion of USB setting the limits in this application…)

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 3 of 3
(1,150 Views)