Engine Dynamometer Brake Control, DAQ & LabVIEW PID

[CoastalMaineBird]

According the Nyquist theorem, if I wanted to capture all the important information, every last force change event within a single rev, I would have to identify the highest component frequency of the force signal and then sample at twice that rate.

It's not just a good idea, IT'S THE LAW!  ;->

 Since I'm not interested in intra-rev data, I can sample once per rev.  I have an option to sample at a fixed 60Hz, or possibly use synchronous sampling to time each sample with one complete rev, 60 pulse edges from the trigger wheel counter input.  It seems like a matter of project preference, but there might be something I'm missing that makes this a more clear cut choice.

--- This depends on how you're measuring torque.  If there's averaging built into the torque meter, then you're OK sampling once per rev.  But if you're measuring torque straight out of a strain gauge or something, then you've got to sample faster or you'll miss things.  The torque goes up when the spark plug fires, and is lowest just before it fires.  If you only sample once per rev, then you might catch it at the peak, you might catch it at the valley, or you might catch it in between.  And if you sample synchronous to the shaft, then all the averaging in the world won't help, because you're sampling at the same point every time around.

[CoastalMaineBird]

Is it accurate to say that the Nyquist theorem isn't immediately important to infrequent (max component freq >> sample freq) signal averaging data acquisition?

The short answer is "It's not nice to fool Mr. Nyquist".

The reason being that when you have frequency components higher than Fn (the Nyquist freq, or Fsample / 2), then they appear in your data as aliases, data that looks OK, but is completely bogus.

My favorite illustration of that is the old B/W western TV shows, where the wagon takes off.  The wagon wheels spokes roll forward, and then appear to slow down as the wagon speeds up. At some point the spokes STOP, and then start appearing to roll backward.  The point at which they stop is the Nyquist frequency (the camera is a sampling device).  If all you could see was the wheel, then you could not tell that the wheel was rolling forward.  That's aliasing in action.

But if you're averaging, then by definition, you're not that interested in the intra-cycle events, and so you probably don't need to care.  Again, that depends on how you're measuring torque. 

[CoastalMaineBird]

I was having trouble seeing how a counter itself was doing averaging.  I think I get it now.  The counter is counting pulse edges generated by the trigger wheel per unit time.  If the unit time is one second and the counter counts 1700 pulses, then we know the RPM is 1700 pulses divided by 60 pulses per rev, equals 28 1/3 revs, times 60 revs per minute, equals 1700 RPM.  Like you said though, there's no way to know if the engine spent the first half of the second at 2000RPM or 1400RPM.

Exactly.  It's not that the counter performs an averaging operation, but that you are inherently measuring the average. You don't want to do that on a changing signal, because averaging inherently inhibits fast changes. 

[CoastalMaineBird]

On a different tack, I would like to point out that for PID work, consistency of timing is CRUCIAL.  An error in timing, either in sampling a signal, or in generating one, is JUST AS MUCH A PROBLEM as an error in measurement.

Suppose your signal changes at 1 Volt per second, and you're sampling at 100 Hz.  If you're 1 mSec late in sampling, then you're off by 1 mV. It doesn't matter if you use a 42-bit A/D: if your timing is off, your measurement is off.

On input, that's usually not a problem, as the sampling is controlled by a steady clock source.   But the same rule applies to output as well.

If your drive signal should change at 1 V/sec, and you're 1 mSec late, then your drive signal is 1 mVolt off.  That's a disturbance to the system, and it's a source of noise. Not because the signals are going wild, just because they're changing at odd times.

There are two approaches to solving this.

One is determinism. You make sure your code path takes the same amount of time regardless of any decisions made along the way.  You see this in the PID toolkit, where they calculate some number, and then throw it away, based on a decision.  The reason is that they want it to take the same time whether the number is used or not.

If your system is fully deterministic, then the time between sampling the input and producing the next output is constant, regardless of decisions made along the way.

Good luck with that.

When I faced this issue, I solved it another way. Forget determinism.  It's just too much work. What I did was tie the clocks together so that I sample the input at the EXACT SAME INSTANT as the output changes. I don't care how long it takes to compute the next output, as long as it's before the next clock tick, I'm OK.  Sampling at 100 Hz, I have 10 mSec to get it done.  I don't care if it takes 0.1 mSec or 9.9 mSec, it works the same.  And I don't have to be counting cycles.  It's easy (in software) to tie the DAC UPDATE CLOCK to the SCAN CLOCK of the input side, and I write to the DACs without updating right away.  This scheme is rock-solid.

[el bob]

---

CoastalMaineBird wrote:

According the Nyquist theorem, if I wanted to capture all the important information, every last force change event within a single rev, I would have to identify the highest component frequency of the force signal and then sample at twice that rate.

It's not just a good idea, IT'S THE LAW!  ;->

 Since I'm not interested in intra-rev data, I can sample once per rev.  I have an option to sample at a fixed 60Hz, or possibly use synchronous sampling to time each sample with one complete rev, 60 pulse edges from the trigger wheel counter input.  It seems like a matter of project preference, but there might be something I'm missing that makes this a more clear cut choice.

--- This depends on how you're measuring torque.  If there's averaging built into the torque meter, then you're OK sampling once per rev.  But if you're measuring torque straight out of a strain gauge or something, then you've got to sample faster or you'll miss things.  The torque goes up when the spark plug fires, and is lowest just before it fires.  If you only sample once per rev, then you might catch it at the peak, you might catch it at the valley, or you might catch it in between.  And if you sample synchronous to the shaft, then all the averaging in the world won't help, because you're sampling at the same point every time around.

---

That's an interesting point regarding synchronous sampling and potentially measuring force at the precise instant in the rev where little force is being exerted.  I can see how it would be important to chase the zone of the force peak within the rev.

Force is measured from an Omega OM5 full bridge strain gage signal conditioner.  The OM5 is hooked up to a Revere load cell.  I don't know how the OM5 module computes its measurements and if it incorporates any kind of sample averaging system.  The torque output I have seen from it so far on an existing Innovate SSI-4 based data acquisition system looks fairly regular, but the SSI-4's LogWorks software may be sampling and averaging in the background.

Omega OM5

Revere Load Cell

Trunnion Mounted Arm and Load Cell

Message Edited by el bob on 03-27-2009 10:49 AM

[CoastalMaineBird]

 I don't know how the OM5 module computes its measurements and if it incorporates any kind of sample averaging system. 

I strongly suggest that you find that out. 

[el bob]

---

el bob wrote:

---

CoastalMaineBird wrote:

According the Nyquist theorem, if I wanted to capture all the important information, every last force change event within a single rev, I would have to identify the highest component frequency of the force signal and then sample at twice that rate.

It's not just a good idea, IT'S THE LAW!  ;->

 Since I'm not interested in intra-rev data, I can sample once per rev.  I have an option to sample at a fixed 60Hz, or possibly use synchronous sampling to time each sample with one complete rev, 60 pulse edges from the trigger wheel counter input.  It seems like a matter of project preference, but there might be something I'm missing that makes this a more clear cut choice.

--- This depends on how you're measuring torque.  If there's averaging built into the torque meter, then you're OK sampling once per rev.  But if you're measuring torque straight out of a strain gauge or something, then you've got to sample faster or you'll miss things.  The torque goes up when the spark plug fires, and is lowest just before it fires.  If you only sample once per rev, then you might catch it at the peak, you might catch it at the valley, or you might catch it in between.  And if you sample synchronous to the shaft, then all the averaging in the world won't help, because you're sampling at the same point every time around.

---

That's an interesting point regarding synchronous sampling and potentially measuring force at the precise instant in the rev where little force is being exerted.  I can see how it would be important to chase the zone of the force peak within the rev.

Force is measured from an Omega OM5 full bridge strain gage signal conditioner.  The OM5 is hooked up to a Revere load cell.  I don't know how the OM5 module computes its measurements and if it incorporates any kind of sample averaging system.  The torque output I have seen from it so far on an existing Innovate SSI-4 based data acquisition system looks fairly regular, but the SSI-4's LogWorks software may be sampling and averaging in the background.

Omega OM5

Revere Load Cell

Trunnion Mounted Arm and Load Cell

Message Edited by el bob on 03-27-2009 10:49 AM

---

That's a very neat way of running the controller.  I can't say I get it all right now, but I'll keep re-reading it and working through it.

---

CoastalMaineBird wrote: 

 I don't know how the OM5 module computes its measurements and if it incorporates any kind of sample averaging system. 

I strongly suggest that you find that out. 

---

I called Omega tech support and spoke to a fellow named Chris.  The OM5-WBS-1-C full bridge strain gage signal conditioner "does not have memory," and does not average strain gage readings, but it does update its output five times per second.  I can't say I totally understand how this works, but the five outputs/second (5Hz) is the end result. 

[AnalogKid2DigitalMan]

I think Omega may have misled you on the description. Its output is continous but the bandwidth response is 5Hz. This means it will filter out and attenuate the portion of the input signal which is over 5Hz.

-AK2DM

[el bob]

---

AnalogKid2DigitalMan wrote:

I think Omega may have misled you on the description. Its output is continous but the bandwidth response is 5Hz. This means it will filter out and attenuate the portion of the input signal which is over 5Hz.

-AK2DM

---

 

Hi AK2DM, thanks for the info.  It didn't make a lot of sense to me at the time.  I'll try and call again Monday and see if there's a whitepaper on this OM5 module I can read.

If the engine changes force output on the load cell sixty times in a second (just a hypothetical), does this mean that the OM5 strain gage signal conditioner will filter out part of the input signal?  I havn't seen a lowpass filter in action outside of simple MATLAB scripts.  I'm curious to see what the load cell signal looks like before and after the filter on an oscilloscope.

Is it not possible to edit posts after a certain amount of time has passed?  I incorrectly quoted my own post instead of Steve's consistency of timing post.

Message Edited by el bob on 03-28-2009 08:08 AM

[CoastalMaineBird]

Is it not possible to edit posts after a certain amount of time has passed?  I incorrectly quoted my own post instead of Steve's consistency of timing post.

I believe that you can only edit a post if A) it's yours to start with, and B) it's still the last post.  Once somebody (even yourself) adds post #9, then post #8 becomes non-editable.

If the engine changes force output on the load cell sixty times in a second (just a hypothetical), does this mean that the OM5 strain gage signal conditioner will filter out part of the input signal?  I havn't seen a lowpass filter in action outside of simple MATLAB scripts.  I'm curious to see what the load cell signal looks like before and after the filter on an oscilloscope.

You can play with the filter examples in LabVIEW if you want to "see it in action".

The basic answer to your question is yes, it will filter out the changes.  It's not necessarily that it has an active filter, it's just that it cannot respond that fast.

Think of an oral thermometer used when  you have a fever.  If your body temperature was going up and down several times per second, do you think the fluid would follow that fast?  

No, of course not, because it physically cannot.

If you had a one-cylinder engine and a constant load, the shaft will get a torque pulse (and a speed increase) every time the plug fires. The weight of the piston carries it along for a while.  When the compression stroke comes along, the gas in the cylinder resists compression, thus slowing down the shaft (and reducing torque), then the spark plug fires and kicks the whole thing off again.

On a four-cylinder engine, you will get four pulses per rev.  I don't know about 8-cylinders,  they may fire in pairs, they may not.  Anyway, the point is that the engine doesn't put out a constant  torque, it's a pulsating force. A flywheel acts to mitigate the pulsations (it's a low-pass filter), but it doesn't eliminate them.

The SAE may have a standard procedure for dealing with all this, you may want to research that.