Engine Dynamometer Brake Control, DAQ & LabVIEW PID

Question

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

Answer 1

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