Engine Dynamometer Brake Control, DAQ & LabVIEW PID

[el bob]

Hi all, I am in the middle of a project to design, build and test a controller for an eddy current engine dynamometer.  I have an idea of how the inputs, outputs and overall process go, but am not sure how to best implement the necessary features in LabVIEW.  I have access to a NI USB-6211 DAQ, and a PC with LabVIEW 8.6, DAQmx drivers and the PID toolkit installed.

On the electrical and mechanical side, an SCR firing board takes a 0-5VDC analog control signal to vary the amount of current passed through 380V three-phase electrical lines hooked into a large field coil.  Varying the input 0-5VDC signal results in a directly related variation of input current into the field coil, which in turn affects the strength of the magnetic field generated by the coil.  A large ferromagnetic rotor spins concentrically within the coil.  If the magnetic field increases, eddy currents are induced in the rotor causing it to slow down and heat up, and vice versa.  The engine-under-test is bolted to the large rotor and is put under load by the effects of the induced magnetic field and eddy currents.

The plan is to have LabVIEW manage the 0-5VDC SCR firing board control signal.  The dynamometer currently has manual rotary knob controls, but the types of tests that are currently possible are limited.  The goal of the overall project is to produce "dyno sheets," plots of engine torque and horsepower over the motor's usable RPM range.  The problem, and motivation for this project, is that the manual controls cannot provide repeatable, precise measurements necessary for "power sweep" tests used to produce dyno sheets.

Power sweep tests are used by all engine and chassis dynamometers to gather an evenly distributed collection of data across the engine's usable RPM range.  The idea is that the engine should be forced to accelerate its RPM at the same rate from just off-idle to rev limit.  Bolted to a dyno and given its druthers, most engines will accelerate more slowly off-idle and more quickly in their upper RPM power bands.  Load must be controlled so that the engine can spin as freely as possible down low in the RPM range, and be forced to maintain constant acceleration as it tries to pull away in the upper RPM range.  Human, manual control of rotary knobs can provide a respectable effort in this situation, but the problem becomes very apparent when comparing back-to-back, "identical" tests on the same engine, with the same operator.  Repeatability of torque and power measurement tests is very important to understanding how distinct changes to the engines mechanical and fluid systems affect its torque output, along with other symptoms.

I hope the background is helpful.

There are RPM and Torque inputs into LabVIEW for the engine under test.  In the design stage, I figured I would be able to implement a PID controller in LabVIEW to vary the SCR firing board's 0-5VDC control signal.  The PID loop would control the 0-5VDC signal so as to allow the RPM of the engine-under-test to accelerate as closely as possible to an operator-chosen rate.  The USB-6211 DAQ has two analog outputs, one of which can be used for the 0-5VDC control signal.  The DAQ also has two digital counter circuits.  One of them is used for counting and determining the continually changing frequency of a TTL pulse train driven by engine-under-test RPM.  Lastly, one of eight analog inputs is used to measure a 0-5VDC analog input signal from a strain gage signal conditioner indirectly measuring engine-under-test torque output.

I worked with LabVIEW as a student in school, but never attempted to design VI's from scratch until now.  I spent the last week or so practicing with the DAQmx Assistant and later the broken-out DAQmx LabVIEW code for bench-testing the counter and analog inputs for RPM and Torque.  I plan to begin experimenting with PID controls this week, but I have stumbled into a few trouble spots with the DAQ input code already.

As of right now, it seems that the PID control loop will only use RPM data, not engine torque data.  I would like to make sure that the sampling settings being used provide just the right amount of coverage, not using more DAQ or PC resources than necessary.  I figure this will assure the sampling process and controller will run as close to real-time as possible without relatively large-scale changes to the system.  Due to mechanical limitations of the dynamometer, the engines under test will never exceed 3600 RPM.  A variable reluctance sensor is positioned closely to a 60-toothed trigger wheel bolted to the dyno's rotating assembly.  The VR waveform is passed through a LM1815 based VR signal conditioning circuit to produce a TTL pulse train.  This digital signal is then piped into of the counter inputs on the USB-6211 DAQ.

(3600 Revolutions per Minute * 60 Teeth per Revolution) / 60 Seconds per Minute = 3600 Teeth per Second (Hz)

The maximum frequency of the RPM signal will be 3600Hz.  I started to try different DAQmx Timing settings. It seems the three main options are Timing Source, Timing Rate and Number of Samples.  I have the book "LabVIEW for Everyone," and read Chapter 11 on LabVIEW with DAQmx, but I had trouble figuring out exactly how these three fields affect a Counter input, as compared to the examples in the book covering analog inputs.  If it's not too much trouble, could anyone shed any light on this?

In case it's interesting, here are some pictures of the engine dynamometer and some of the older data equipment that is being replaced.

Engine Dyno Pictures

Thank you for any help! 🙂

Rob

[mishkin]

Hey Rob,

Thanks for taking the time to write such a detailed message. The overview of your setup definitely looks good and should be sufficient for you to pull off the dyno project. Just make sure  you keep an eye on the number of inputs/outputs available on the card. You didn't really mention yet how you'll be measuring the horsepower produced by the engine. 

The PID toolkit should give you the ability to control the RPM acceleration rate so that you can increase it  steadily.One question here though: in your PID control loop, are you going to be taking torque measurements into account when adjusting your RPM rate? In other words, is  your RPM rate adjusted based only on the previous RPM reading or both RPM and torque? In either case, you should be able to adjust the rate based on both inputs if you wanted to.

As far as learning more about DAQmx, probably your best resource are the examples in Labview's example finder (one useful feature is to select your hardware in the dropdown box in the bottom left corner and limit the results to hardware). For your counter task, for example, you could probably use the example in Hardware Input and Output > Daqmx > Counter measurements > Digital Frequency. One of those examples uses one counter. You'll notice that the example doesn't exlplicitly specify timing at all.

Also, see if you can find any useful information about getting started with DAQmx here. 

Let me know if I didn't answer some of your questions - it was a pretty long post 

[el bob]

Hi Misha,

Thanks for the help.  I think I might have seen a mention of the example finder before, but I completely forgot about it.  Thanks for the tip.  I am looking forward to check it out.

The plan for horsepower measurement is to try and compute it in real-time using the formula, HorsePower=(Torque x RPM)/5252.

I don't believe I will need to take torque into account for the PID control loop.  The brake control output, and ulimately the RPM acceleration rate, will be adjusted based only on the previous RPM reading.  From what I have seen, engine dynamometer operators are usually asked to specificy three inputs before performing a power sweep test.

Input (Units)

* Beginning RPM (RPM)

* Sweet Rate (RPM/second)

* Ending RPM (RPM)

The software needs to then determine target PID setpoints (engine under test RPM points) for given time requirements.  I believe a possible example could look like this.

Beginning RPM --> 800 RPM

Sweet Rate --> 200 RPM/second

Ending RPM --> 2200 RPM

Setpoints are auto-generated and passed to the PID control loop for when the operator begins the power sweep test.

Time 0s -- 800 RPM

Time 1s -- 1000 RPM

Time 2s -- 1200 RPM

...

Time 6s -- 2000 RPM

Time 7s -- 2200 RPM

When the operator is ready to beging the power sweep, the engine under test is first brought up to the desired beginning RPM, without engaging the eddy current brake.  Then, simlutaneously, the engine under test's throttle is opened 100% and the PID control loop is run.  When the engine under test RPM reaches the ending RPM, the brake output and throttle opening are decrease steadily to zero percent.  Some dynamometer control systems provide a pre-load stage where the operator can open the throttle 100%, the software commands braking effort just enough to hold the engine at the desired beginning RPM, and the operator presses a second button to begin the sweep test.  While this offers a few nice advantages, I am not looking to add this feature in the short term.

Thank you for reading that admittedly long post. 🙂  I appreciate your help.

Rob

[mishkin]

Sounds good, Rob. If you have any specific PID questions later, feel free to post them in here or start a new thread.

[el bob]

I put together a basic PID controller VI and tested the combined DAQ and dynamometer system last week.  I studied the PID Toolkit example VIs and made a few best guesses.  I ran into a couple of issues that I'm hoping learn a few things about here on the NI boards.

Here's a screenshot of the VI's block diagram and front panel.  The block diagram is missing the Write to Measurement file sub-VI that was later added.

09_03_20 PID_TargetRPM Front Panel and Block Diagram Screenshot

Here's a download link to the VI itself.

09_03_20-PID_TargetRPM.vi Download Link

The first problem I noticed was mostly of my own doing.  The PID Controller would kick on the dyno brake when the engine-under-test RPM dropped below the programmed RPM setpoint.  I realize that this is normally how a PID controller is supposed to behave.  If I was trying to maintain temperature in an oven, I would want the heater to kick on when the temperature fell under the programmed temperature setpoint.  I was not quite sure of how to best setup the PID loop to work as a braking control circuit, rather than an acceleration control circuit.  I tried by modifying the PID output, I'll call it alpha, with a simple subtraction equation.

FinalOutput = 5 - PIDControlOutput

This did result in the brake kicking on when operating RPM (Process Variable, PV) exceeded the target setpoint RPM (setpoint, SP), but I'm not sure if there's a better way to accomplish this.

The other main problem I ran into was the PID loop kicking on full braking output whenever PV > SP, this resulting in a tremendous amount of braking torque being applied to the engine and prompty stalling it.  I tried to limit this behavior by changing the control output range variables.  This provided a temporary patch and prevented the dyno from stalling the engine immediately, but I do not believe it will work long term since more braking power will be needed when a similarly-sized engine is run at higher RPM, under more load (making much more torque), or when a larger displacement engine is used in similar conditions.

After troubleshooting these issues for a while, I was able to use closed-loop PID control to regulate engine RPM from ~970RPM down to ~905RPM.  The process variable and final control output was piped into a log file and graphed.

09_03_21-TestingLog02_04 Engine RPM versus Control Output Signal Chart

It can be seen that the control output currently looks more like a rapidly-changing on/off switch instead of a continuously variable analog control signal.  I'm not really sure what's causing this, but I would like to find out.

Any ideas or advice?  Thank you for reading.

Rob

Message Edited by el bob on 03-23-2009 01:47 PM

[CoastalMaineBird]

As it happens, I am involved with a large project that controls engines, as well.  I have two control loops, one controls dyno drive based on speed, and the other controls throttle based on torque.  Usually only one is in PID mode at a time, the other is open loop.  I have to run the engine thru a prescribed speed-torque cycle and measure how much exhaust pollution occurs.

We do "Torque Maps" which are sweeps similar to what you describe. You put the throttle 100% ON, and ramp up the dyno speed, all the while capturing data.  You get a map of how much torque you can obtain at any given speed. 

I do it on a PXI box to avoid timing issues.  When I last tried to use the host computer to do this, Windows was just not able to devote the time to getting the data right.  The PXI box guarantees that I can control the loop at 100 Hz (I have tested it up to 1000 Hz).

Anyway, to your specific question: 

I started to try different DAQmx Timing settings. It seems the three main options are Timing Source, Timing Rate and Number of Samples. 

The counters are general-purpose, so they can be configured in many different ways.

The TIMING SOURCE is where the basic timebase comes from.  If you're measuring a high-frequency signal, you want a higher-frequency timing source (so you have resolution to spare).  If you're measuring a low-frequency signal, you want a low-freq timebase (so you don't run out of counter bits).  If your max input is 3600 Hz (277 uSec), then a 1 MHz timebase (1 uSec) will give you  one part in 277 resolution WORST CASE.  A 10-MHz timebase will be 10 times as good.

I don't know where you are getting the TIMING RATE and # SAMPLES inputs, can you explain? 

[walter-donovan]

First off, your photos show enough parts to build a couple dynos. There is obviously the eddy current frame & brake. There is also parts of a Go Power water brake dyno. Don't think you'll need many parts from it.

I think turning the signal negative is perfectly acceptible as a PID is simply a box full of equations, tunable by coefs. Pretty sure this is standard procedure for cooling systems (you mention a heating PID).

As far as the system control being less than desired, this relies on careful coefficient tuning of the PID routine.  I think the PV/SP graph indicates an unstable system that is overdamping. Try increasing Ki and maybe decreasing Kp. Also there is a little noise in your input signal. This could be causing havoc. Your sampling frequency seems overkill. I would probably use some of these samples for filtering. A simple boxcar filter could stabilize the PID tremendously by steadying the errors. 

[nathand]

---

el bob wrote: 

It can be seen that the control output currently looks more like a rapidly-changing on/off switch instead of a continuously variable analog control signal.  I'm not really sure what's causing this, but I would like to find out.

---

Are you certain your PID tuning parameters are good?  If you've gone through a tuning process such as Ziegler-Nichols and you're still getting odd behavior, make sure you've got the units right - your integral and derivative parameter should be in minutes, even though the dt input is in seconds.

[el bob]

---

CoastalMaineBird wrote:

As it happens, I am involved with a large project that controls engines, as well.  I have two control loops, one controls dyno drive based on speed, and the other controls throttle based on torque.  Usually only one is in PID mode at a time, the other is open loop.  I have to run the engine thru a prescribed speed-torque cycle and measure how much exhaust pollution occurs.

We do "Torque Maps" which are sweeps similar to what you describe. You put the throttle 100% ON, and ramp up the dyno speed, all the while capturing data.  You get a map of how much torque you can obtain at any given speed. 

I do it on a PXI box to avoid timing issues.  When I last tried to use the host computer to do this, Windows was just not able to devote the time to getting the data right.  The PXI box guarantees that I can control the loop at 100 Hz (I have tested it up to 1000 Hz).

Anyway, to your specific question: 

I started to try different DAQmx Timing settings. It seems the three main options are Timing Source, Timing Rate and Number of Samples. 

The counters are general-purpose, so they can be configured in many different ways.

The TIMING SOURCE is where the basic timebase comes from.  If you're measuring a high-frequency signal, you want a higher-frequency timing source (so you have resolution to spare).  If you're measuring a low-frequency signal, you want a low-freq timebase (so you don't run out of counter bits).  If your max input is 3600 Hz (277 uSec), then a 1 MHz timebase (1 uSec) will give you  one part in 277 resolution WORST CASE.  A 10-MHz timebase will be 10 times as good.

I don't know where you are getting the TIMING RATE and # SAMPLES inputs, can you explain? 

---

That's a very interesting project you are working on, certainly a lot more involved and impressive.  I think I saw a few screenshots of the LabVIEW interface on your website and wow!...that is really nice.  The emissions analysis equipment can get very pricey, but I can't think of a more timely test to be directly involved in at this point in time.

I briefly researched standalone LabVIEW system options and real-time capabilities.  I am hoping that the barebones nature and low operation count of the VI will allow a Windows host PC to be sufficient for controlling the process.  This is largely an economic motivation to keep the overall project cost down.  If it turns out that PXI hardware is necessary, it will also be possible to look down that path at that point in time.

When I first looked at LabVIEW DAQmx reference materials, I suspectec I would need to go beyond the DAQ Assistant and break down DAQmx tasks into their lower level start, read, write, stop and clear components.  After reading more and working with additional LabVIEW PID examples, it looks like I may be able to stick with DAQ Assistant sub-VI's.  I was confused at the time by the different DAQmx timing components and chose to begin with a question on the counter input.  Today, a DAQ Assistant sub-VI seems to be handling the counter input well enough.

I most likely need to focus on PID parameter tuning at this time.  If it turns out that the timing configuration of the counter RPM input is preventing the system from working as required to perform a power sweep, or follow a Torque Map like you mentioned, then I will need to revisit it.  For now I'm just going to be happy that its portion of the system seems to be working. 🙂 

Message Edited by el bob on 03-24-2009 01:45 PM

[el bob]

---

walter-donovan wrote:

First off, your photos show enough parts to build a couple dynos. There is obviously the eddy current frame & brake. There is also parts of a Go Power water brake dyno. Don't think you'll need many parts from it.

I think turning the signal negative is perfectly acceptible as a PID is simply a box full of equations, tunable by coefs. Pretty sure this is standard procedure for cooling systems (you mention a heating PID).

As far as the system control being less than desired, this relies on careful coefficient tuning of the PID routine.  I think the PV/SP graph indicates an unstable system that is overdamping. Try increasing Ki and maybe decreasing Kp. Also there is a little noise in your input signal. This could be causing havoc. Your sampling frequency seems overkill. I would probably use some of these samples for filtering. A simple boxcar filter could stabilize the PID tremendously by steadying the errors. 

---

Haha, I guess those pictures do show an eclectic mix of hardware.  The popular favorite seems to be the camshaft sticking out the side of the shopping cart.  I did not know where that test stand came from, but like you guessed, it came from a 1970s Go Power water brake dyno that was retired eight or nine years ago.  It was recently used only for its throttle lever and cable.  It's since been replaced by a throttle assembly installed closer to the rest of the dyno and computer controls.

Regarding the PID output being flipped negative, thanks for the information.  Hopefully it will work out nicely.

I did not try a particular tuning method.  I was having a significant amount of trouble keeping the controller from abruptly ramping the output to full brake and stalling the motor.  I read about the Ziegler-Nichols method and will try it in full this week.  I tried to adjust Kc last week to just get an oscillating process response, but got caught up in how the output seemed to which on and off with no sign of smoothly changing between the two states.  At the time, I convinced myself that I must have made a mistake in the LabVIEW code, forgetting to consider the possibility that the problem could just be PID parameter tuning.

Doh, I didn't notice the noise problem.  Thanks for the clue-in.  It looks pretty obvious now that you mention it.  I'm not terribly knowledgeable about filters other than basic low and highpass filters.  I looked up the boxcar filter on Google and found this Wikipedia page.  I'm probably misinterpreting the text, but it looks like a boxcar filter would be used to filter an analog signal into a sort of digital TTL signal.  I know I've got this wrong, so I'll keep searching for more info.  Any advice and insight would be greatly appreciated.

Sampling at 50ms intervals means 20Hz sampling.  The maximum engine RPM is 3600 RPM, and the maximum DAQ counter input is 3600Hz due to the 60 tooth trigger wheel the VR sensor reads from.  I'm a little unclear on the details here as I remember the Nyquist theorem lessons talking about sampling at 10 times the greatest frequency of the signal to be measured.  This makes me think I should be sampling at 36kHz, but I'm probably missing something again.  Hope you guys aren't sick of this by now. 🙂