closed-loop control using LabVIEW Real-time

[mhmdi]

Hi,

I am trying to use the LabVIEW Real-time module to control the vibrations of a flexible link. The highest frequency I am dealing with is around 1000 Hz. Considering that, I have a few questions:

1) I am using the 1 KHz clock with a period of 1 ms for the timed-loop, namely, I am capturing data at 1 KHz. I read in NI forums that there are limitations on the determinisim of the timed-loop if the MHz clock is used with loop rates of less than 1 msec, for Windows host PCs, even if the target isoperating under RTOS. Given data acquisition rate should be at least twice as fast as the highest frequency, I was wondering if I would run into problems using the 1 msec period with 1 KHz clock?

If yes, what if I increase the samples per channel of the DAQmx Read VI from 1 to 10 or something? Does that really increase my sampling rate?

2) Also, I realized that after runnig my real-time project for a certain time duration (e.g. 20 sec), I am not getting enough samples that I expect (assuming a sampling rate of 1000 Hz for the DAQmx Timing VI and 20 sec of runnig the code, I expect to see 20,000 samples). It seems to be that some data is lost either due to non-optimized parameters of the time-loop or due to the network stream parameters (e.g. buffer sizes that transfer the aquisition files to host PC).

Any idea would be greatly appreciated.    

[RavensFan]

1.  Give us a link to what you read in the forums about the limitations in the determinism of the 1 MHz clock so we can read it too.  Why do you think the Windows OS would give you problems with the real-time OS on the target?  What is  the target?  What code are you running in Windows and what code are you running on the real-time target?  Where is your control loop running?  Something doesn't sound like it would work right if you are trying to use a 1 kHz loop to control a 1 kHz vibration.  I think you'd need to run at least twice as fast (based on Nyquist) to have a chance, and probably at least 10 times as fast.

2.  If you feel you are losing data points in your acquisition, post your VI's so we can see how you have them set up.

[mhmdi]

Hi RavensFan,

1) Here is the link to the 1KHz timed-loop limitation in Windows:

http://forums.ni.com/t5/LabVIEW/windows-1KHz-time-loop-limitation-reason/td-p/2201514

 I am not sure why windows would give me such problems.

The target is a third party desktop-PC (core 2) with the RTOS installed on it.

The codes I am running on windows and RTOS are attached here. I am runnig closed-loop code on the target (using shift-registers on the timed-loop).

To confirm, you mean I can only control the vibration of up to 500 Hz using the 1 KHz clock with 1 msec period in the timed-loop, regardless of other parameters in the code, right?

2) The VI's are posted here.

3) Also, I am also not sure if I can use more than 1 sample per channel in the DAQmx timing VI and DAQmx read VI. My feeling is that if I use more than 1 sample per channel for closed-loop control, the data array stored in buffer would lead to some delay which would finally make the closed-loop control system unstable. Should we consider such limitations (i.e. keep the value of samples per channel to 1 for both DAQmx VI's) in real-time closed-loop control?

Regards,

Masih    

[RavensFan]

1.  That is different.  In your original message, it wasn't clear you were talking about the timed while loop.  While timed loops provide some nice features, they are not really intended for the Windows OS.  You can run a regular while loop much faster on Windows, you just don't have any determinism on the timing of the while loop.

---

@mhmdi wrote:

To confirm, you mean I can only control the vibration of up to 500 Hz using the 1 KHz clock with 1 msec period in the timed-loop, regardless of other parameters in the code, right?

---

---

I am no expert in control theory, but that is what I'm talking about.  I don't see how you can control a process that is happening faster than you can track it.

---

mhmdi wrote 

3) Also, I am also not sure if I can use more than 1 sample per channel in the DAQmx timing VI and DAQmx read VI. My feeling is that if I use more than 1 sample per channel for closed-loop control, the data array stored in buffer would lead to some delay which would finally make the closed-loop control system unstable. Should we consider such limitations (i.e. keep the value of samples per channel to 1 for both DAQmx VI's) in real-time closed-loop control?

Regards,

Masih    

---

Yes you can read more than 1 sample per channel (depending on your DAQ device).  If you don't, there is no way you can measure samples from a DAQ device with repeatable timing between samples (with continuous acquisition, you are using the DAQ device's timing system", and still be able to keep up with the data coming into the buffer.

Technically, even if you are reading only 1 sample, you are still somewhat delayed from when the reading occurred to the time it arrives in the PC where you can act on it.  Of course the more samples you read at a time, the more stale the first sample in a packet of data becomes.

As I've said, I'm not an expert in control theory, but even delays in data arrival can be modeled as part of your overall control loop scheme.

[nathand]

---

mhmdi wrote:

1) Here is the link to the 1KHz timed-loop limitation in Windows:

http://forums.ni.com/t5/LabVIEW/windows-1KHz-time-loop-limitation-reason/td-p/2201514

 I am not sure why windows would give me such problems.

The target is a third party desktop-PC (core 2) with the RTOS installed on it.

The codes I am running on windows and RTOS are attached here. I am runnig closed-loop code on the target (using shift-registers on the timed-loop).

---

The loop rate on the host (the Windows machine) and on the target (Real-Time Operating System) are unrelated. I don't know what the maximum frequency is for a loop on a real-time desktop target, but I suspect it's faster than 1kHz. I'm not sure how you concluded from the linked discussion that the host limits the target loop rate; I don't see anything in that thread that would suggest that limit.