Confusion regarding hardware-software interfacing using DAQmx

[johndoe86]

Hi,

Before I begin, I would like to inform that I am fairly new to Labview and please be considerate if I sound naive with my questions.

Aim: To implement feedback control algorithms in a test rig
System: A combustor exhibiting combustion instability
DAQ hardware: NI PCIe-6353 card (in PC) connected to SCB-68A
Instrumentation:
(1) Feedback is obtained from the system using an Electret Condenser Microphone (ECM) that measures pressure fluctuations in the form of voltage. The ECM is connected to one of the Analog Input (AI) terminals of the SCB-68A.
(2) Control signals are sent as voltage to a loudspeaker (the actuator) via an amplifier. The actuator is connected to one of the Analog Output (AO) terminals.
Software: Labview 2017 installed in Windows 10.

The attached figure (BlockDiagram.png) will provide a better understanding of the system. In very short terms, I measure voltage via the AI terminal in SCB-68A and supply control signals via the AO terminal.

The frequencies of pressure fluctuations in the combustor vary from ~650 Hz to ~2000 Hz. Hence, I need to use a sampling rate of 20 kS/s at both the AI and AO terminals. Such a high sampling rate is necessary, especially during system identification where I need to supply an excitation signal that includes the dominant frequencies of the system.

My confusion is in the choice of Sample Mode in DAQmx Timing (Sample Clock).vi. The way I understand controller implementation is that, you measure one sample from the system and based on this acquired sample, the controller supplies one sample of control voltage to the actuator; this should continuously. Considering this, Sample modes of Continuous and N samples cannot be used and hence, the Hardware-timed single point mode was chosen (refer to Trial4.vi).

At this point, I would like to ask my first question: I am right in choosing Hardware-timed single point mode over the others OR am I missing out on some other capability of the Continuous and N samples modes that can be utilized for my purpose OR is my understanding of controller implementation insufficient?

Secondly, I require a sampling rate of 20 kS/s, but am unable to go beyond 1 kS/s for both AI and AO terminals. I was getting error code -209801 during the process; Labview documentation explains this as, "DAQmx Write did not complete before the arrival of the next sample clock which indicates that your program is not keeping up with the hardware clock. To remove this warning, slow down the hardware clock, or else change your application so that it can keep up with the hardware clock." I did post this second question in the here; but, probably due to lack of information (provided by me) or clarity (of questions), I am still confused. I was told that the issue is due to looping at 20 KHz and PCs were not intended to run that fast. The solutions suggested were:

1. Use RT on an RT target.
2. Use a producer-consumer method
3. Implement this on a FPGA.

I however think that I might be missing out on something like:

1. Is this a hardware limitation?
2. Am I approaching the controller implementation wrongly in Labview? For e.g., if looping at such high sampling rates is the problem, is there some other way of doing it without using looping? If enforcing hardware timing is the problem, how large will be the errors?

Note: I have done a lot of "googling" and found that "looping" acquisition and supplying of data using the "hardware-timed single point" sample mode setting is the right direction to go. I am mostly looking for a second opinion on the matter.

Thanks in advance.

[Kevin_Price]

Thanks for the careful and detailed post, that's a big help for getting started.

1. Do you intend a *control loop rate* of 20 kHz so that you can smooth out and compensate for ~650-2000 Hz pressure fluctuations?

   If so, you will absolutely, unequivocally NOT be able to do this under Windows.  I can't speak with authority about RT, but I suspect the DAQmx driver may be a key bottleneck that makes it "iffy".

A really clear answer to this question is of paramount importance to the rest of the discussion.  Are we really solving the right problem here?

2. Producer - Consumer may be useful but it attacks your secondary problems more than your primary ones.  I see your primary problems as:

- timing *consistency*

- timing *raw speed*

- timing *latency* for your feedback-signal-to-control-effort chain of signals and code

Your ceiling for some of those things will likely be a bit worse without Producer-Consumer or some similar way to make your code parallel and distributed, but they aren't really *solved* by it.

3. My take is that HW-timed single point methods are both useful for timing consistency and fragile for reliable operation (because they not only *help* timing consistency, they *demand* it and fail immediately if the timing target isn't met).  It's important to understand this at the outset.  If the consistency is super important, you live with the fragility.  But life's easier when you can accept a little timing inconsistency.

-Kevin P

[johndoe86]

Dear Kevin,

I cannot thank you enough for your effort in going through such a long post, and phrasing it much more concisely. Also, I apologize for a delayed response.

I started off this post saying that I am new to Labview. Let me just rephrase that my experience is mostly in simulating control scenarios in softwares like Matlab. Based on this experience, Labview documentation and NI forums took me to where I am (my first post). Your question: Are we solving the right problem here? got me thinking on where to start. This being said, lets start at the beginning. I have a system (experimental setup) that has limit cycle oscillations at frequencies ranging from 650-2000Hz. If I want to implement a controller on this system, how would I go about it in Labview with the hardware I have? is the basic question. I am facing issues especially in the "DAQmx Timing (Sample Clock).vi". Should I stick to *1 sample HW timed* mode or should I look at *N samples mode* or *Continuous mode*. Is it wrong to use these other modes (Continuous and N-samples mode). I have attached a figure for using Continuous samples mode for my purpose. Is there anything wrong in using this. There aren't any stringent requirements on the *timing consistency* or *timing raw speed* or *timing latency*.

Please tell me, from your experience, how would you utilize Labview and NI PCIe-6353 hardware to implement controller for my problem?

[johndoe86]

Dear Kevin,

I cannot thank you enough for your effort in going through such a long post, and phrasing it much more concisely. Also, I apologize for a delayed response.

I started off this post saying that I am new to Labview. Let me just rephrase that my experience is mostly in simulating control scenarios in softwares like Matlab. Based on this experience, Labview documentation and NI forums took me to where I am (my first post). Your question: Are we solving the right problem here? got me thinking on where to start. This being said, lets start at the beginning. I have a system (experimental setup) that has limit cycle oscillations at frequencies ranging from 650-2000Hz. If I want to implement a controller on this system, how would I go about it in Labview with the hardware I have? is the basic question. I am facing issues especially in the "DAQmx Timing (Sample Clock).vi". Should I stick to *1 sample HW timed* mode or should I look at *N samples mode* or *Continuous mode*. Is it wrong to use these other modes (Continuous and N-samples mode). I have attached a figure for using Continuous samples mode for my purpose. Is there anything wrong in using this. There aren't any stringent requirements on the *timing consistency* or *timing raw speed* or *timing latency*.

Please tell me, from your experience, how would you utilize Labview and NI PCIe-6353 hardware to implement controller for my problem?

[Kevin_Price]

I'm afraid I don't have a good understanding of what you mean by "limit cycle oscillations."  You mentioned system response frequencies in the 650-2000 Hz range.  So I see the purpose for sampling input/feedback signals at 20 kHz.  It's a little less clear whether that also needs to be the control loop rate.

I don't have any good idea what a simulation model might look like for a controllable combustion system.  But I know some systems with high frequency dynamics are managed with control loops running much slower than those natural response frequencies.  Such control systems might aim to decrease excitation or increase damping as a way to limit response amplitudes.

IF you had such a system, you might look to set up DAQ hardware to sample at 20 kHz, and then do your control logic at, I dunno, let's say 500 Hz (making a 2 msec loop interval.  Each pass through the control loop, you'd read your 40 latest samples (2 msec worth) and use them to calculate your next control output.

On the other hand, if you really *must* aim for a very fast control loop, I just remembered another thread I was in a little while back.  It showed pretty decent timing behavior for 5kHz loop rate under Windows.  Here's the message with an example program, but you should read more of the thread for context.  It's a minimal output-only example, I never tried extending it to include DAQ input and control logic.

-Kevin P

[GerdW]

Hi John,

some generic advice on your last image:

• Never initialize, start and stop the DAQmx task inside the control loop! NEVER! These steps belong before/after the loop…
• LabVIEW comes with a ready-to-use PID: no need to do all that on your own. Especially no need for those ExpressVIs…
• Never include charts/graphs inside tight control loops. NEVER!
• Never do "complicated" stuff inside tight control loops: why do you need to apply FFT and ToneMeasurments in here???
• Setting up an AO task for "Continuous Samples", but writing only "1Chan 1Sampl" is pretty senseless IMHO.
• Reading 3000 samples at AI task and writing just 1 sample at AO task: why did you set them to the same sample rate?
• Don't fiddle with the "samples per channel" value at DAQmxTiming, when you choose "Continuous Samples" mode. Read the LabVIEW help for this function!

Ever heard of producer-consumer schemes?

[johndoe86]

Dear Kevin,

If the system dynamics changes rapidly enough, the controller should also be fast enough to accommodate the changes. This is true for my system, and hence I require a faster control loop rate equal to that of the system (650-2000 KHz). Even for doing a System Identification, dominant frequencies of the system must be excited, and hence the actuator must have a bandwidth similar to the frequency range of the system. Considering this, I dont think a slower control loop rate is the right direction for me to go.

[johndoe86]

Dear GerdW,

The image was a screenshot from some document. I am with you on all the points from 1-4. Points 5-6, I am trying to figure out how people have managed to get control using that *.vi at 30 KHz. As for point 7, I am aware of the table provided for continuous mode in Labview documentation.

Producer-Consumer: Yes, I have heard; but that is pretty much the extent of my knowledge on the matter. I am yet to explore that more.

However, you can help me with my current problem: I have a system with dynamics having a bandwidth of 650-2000 Hz. I would like to implement a controller with a similar bandwidth. But, I am unable to incorporate a sampling rate of 20 KS/s separately for acquiring and generating together. I have a NI PCIe-6353 card connected to SCB-68 connection block. Everyone here thinks that running this setup in Windows is impossible. I am in desperate need of help, and if you have a means to by-pass this, I am all ears.

[GerdW]

Hi John,

Everyone here thinks that running this setup in Windows is impossible.

I also have that opinion.

You will not get control loops running with >2kHz on a regular WindowsOS.

It is even hard to reach this on a default RT system.

You should think about FPGA targets to reach stable (!) loop rates of >5kHz…

I have a NI PCIe-6353 card connected to SCB-68 connection block.

I am in desperate need of help, and if you have a means to by-pass this, I am all ears.

First you should collect your requirements, then you should buy the hardware needed to fulfill those requirements.

Insisting on using that 6353 card on your Windows pc doesn't help a lot…

[Kevin_Price]

Later today I'll take that 5 kHz example, add AI, and then try to push the loop rate limits.   I don't expect I''ll get anywhere near 20 kHz with reasonable consistency, but I'll give it a shot.

A generic comment: you're tackling an extraordinarily difficult task as a beginner.  Fast deterministic control of high-bandwidth real-world physical systems is rarified air.  Relatively few people around here have even attempted it (myself included), even fewer have succeeded.  And the long-standing consensus from those who've gone before us has always been that:

- Windows cannot guarantee deterministic loop rates, and is generally not worth trying for multi-kHz loops.  Even the fairly decent results at 5 kHz I got using a minimal and highly idealized example seemed revelatory and almost shocking.

- High bandwidth systems in particular NEED determinism.  Timing jitter will excite those high natural response frequencies.

- For anything like 20 kHz, you better be really close to the metal (FPGA, dedicated microcontroller, pure circuitry) and avoid the presence of an OS or DAQ drivers.

It's worth asking the questions because sometimes the consensus is wrong.  But understand that the answers you're being given are not arbitrary.  A lot of us *have* done quite a variety of poking and prodding at DAQ and Windows timing without getting close to finding a magic bullet for fast real-time control.

-Kevin P