LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problems with loop time and DAQmx when designing a P-regulator

Hello!

 

I've attached a VI I'm currently working on. The aim is to create a functionable P-regulator which will compensate my original sweep signal so that the output will look like the sweep. The sweep is the setpoint and I'm tryng to compare each datapoint in the sweep with each datapoint from the output to get my error. The problem is that I don't manage to make it work, and it seems like the loop time is way to slow. Every sweep should be 50k samples with a sample rate of 5000Hz. 

 

I belive the program picks each datapoint from the array with the sweep as it should right now, but not really sure how to manage that with the output signal from the DAQmx blocks. Also uncertain if it is possible to read one sample at a time at this rate with the DAQ. 

 

I'd appreciate comments and pointers on the problem at hand, and on the code in general.

Im pretty new to Labview so im sure there are lots of things that could be done better and more efficiently. 

 

Best regards,

 

Oscar

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

Small tip: unless you specifically want to change the number of measurements during the DAQ, then replace the WHILE loop with a FOR loop.

Compute your N * 50000 once, and let the loop run by itself, without comparing every single time.

 

Point 2, don't try to update the numeric indicator, much less the chart, at 50000 Hz.

It's

Not

Going

To

Work.

Remove the chart and the indicator and see how well it works.

If you need to debug it, save those values (auto indexing arrays) and plot them AFTER the fact.

 

Point 3. You are using TIMED analog output, but you are a slave to the analog input timing.  Use the ON DEMAND mode for analog output and you won't have timers arguing with each other.

 

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

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

Thanks for your comments!

 

I've implemented point 1 and 2, but not really sure how to fix point 3. When using the DAQ assistance there is an option for 1 sample ON DEMAND, but how do I configure that when using the DAQmx blocks? As I've understood I just skip the DAQ.mx timing.vi on my analog output, right?

But then there's an error for the DAQmx read function on the analog input saying it isn't able to keep up the acquisition. Not really sure how to fix that but I'm working on it. Any clues? And am I wrong about how to obtain the ON DEMAND with the DAQmx blocks? 

 

Really gratefull for any help!

 

Best regards, 

Oscar

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

Hello OscarGott, 

 

Can you walk me through the program? When do you want to start writing? What is the commit at the end of the program supposed to do? Why wouldn't you use finite acquisition?

As an answer to your question, change continuous samples to Hardware Timed Single Point. I believe this was previously called On Demand Sampling.

 

Nick

 

AE@NIUK



----------------------------------------------------------------------------------------
Everything has an End, and you get to it only if you keep on
-E. Nesbit
0 Kudos
Message 4 of 8
(2,937 Views)

Attached the VI with comments and a picture of the response signal who I want to adjust such as it follows the chirp. Will need a PID-regulator in the end but thought it would be easier to start out with just the proportional part at first, due to my not so good knowledge in Labview.

 

Very interested in any comments you might have on my program!

 

Thanks in advance!


Oscar

Download All
0 Kudos
Message 5 of 8
(2,934 Views)

Hello Oscar, 

 

I'll have a look at your code, first of all some unrelated comments:

- Keep your wires straight and going from left to right, loops should have inputs on the left and outputs on the right (otherwise the code is very hard to read

-Do not cross or bend your wires, if possible

 

The mathematical part does not matter for this problem, it is only DAQmx. A few questions: 

-It looks like you are using a set number of acquisitions, finite acquisition seems very well suited for the job, why continuous?

-Do you want to write inside the loop, or outside?

-You will not be able to read/write point by point at 5 kHz using a PC, this is just a hardware limitation, use another way of acquisition/output (multiple samples or waveform). 

 

Best Regards



----------------------------------------------------------------------------------------
Everything has an End, and you get to it only if you keep on
-E. Nesbit
0 Kudos
Message 6 of 8
(2,924 Views)

Thanks for your comments! Oh, sorry, will work on keeping my code more clean and easy to read.

 

- I want to be able to adjust number of "acquisition runs", where each run will consist of 50k samples.  Realize I've probably misunderstood how the finite samples work, and as you say it would suit for the job. Will try it out tomorrow.

 

- I have to write inside the loop. I need the "compensated chirp" as output to my system in order to dampen the systems resonance peak and to exaggerate the other frequencies. Really uncertain how to connect the DAQmx blocks and in which order. But I have spent the evening reading about it and will probably get some clarity tomorrow.

 

- I'm using a myDAQ, isn't the maximal rate 200kHz or am I tcompletely way of?

Wouldn't another way of aqcuisition/output cause problem with the comparison in my P-regulator which has to be in real time. Is there any way to make it work with another way of acquisition/output?

 

Best regards,

 

Oscar

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

Sorry to say, but I really don't think you can get there from here with your present equipment.

 

From what I've gathered in this thread, you need reliable loop timing at 5 kHz and low latency i/o.  USB doesn't have nearly low enough latency and it also won't support "hardware-timed single point mode".  Windows timing functions don't even have enough resolution nominally (limited to 1 msec), and the accuracy / repeatability that can actually be achieved in Windows is considerably worse than that.

 

All these things are working against you.  Your data acq device and OS are too limited to satisfactorily perform real-time control at 5 kHz.  It'll be a waste of time to keep tweaking the code to try to make it happen.

 

P.S.  As to your specific question about the myDAQ handling 200 kHz -- that would be a spec for buffered data acq.  When doing buffered data acq, data does not move across USB 1 sample at a time, it moves in good-sized chunks in or out of a buffer.  And the presence of a buffer necessarily implies latency.

 

 

-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 8 of 8
(2,899 Views)