Fly Wheel Sensor - Arduino/stepper for generator speed control

[Dave_Anderson]

Hello, new to Arduino and new to this forum. I have a problem that I have been mostly able to solve -- at least in my own mind -- through research and experimentation till now. I have some electronic background in the dim past, but am very handy with DC and computers(plus mechanical, etc. etc.).

So the problem is, I have a large industrial generator that came with my home, mid-80's vintage. The damper on the mechanical governor is NLA and the closest replacements I have found are not satisfactory.

So, in a nutshell, I need to control the speed of the generator under varying conditions and loads and I need to control it fairly precisely. Variations in speed translate into variations in both voltage and AC Hz in my main home circuit panel. Speed oscillations are triggered by changes in load, for example the 1.5HP well pump turning on, or one of the 3/4HP booster pumps, furnace, refrigeration compressor, etc. etc.

I have settled on an Arduino controlling a stepper connected to the carburetor shaft on the generator, stepper position to change based on sensing of engine speed over/under setpoint.

OK to skip this paragraph, broad info... but I have been playing with an arLCD unit(Uno R3), stepper motors/drivers, looked into the PID library and read Brett Beauregard's excellent writeup, I wrote code to implement a touch interface on the arLCD, to test the control of control motors with a step and direction controller, and more. I know the generator control circuits pretty well, and have essentially full wiring diagrams though many components are proprietary black boxes. There is enough info to navigate the various system interlocks and make use of the important ones.

At this point the challenge is to safely and accurately monitor engine speed, mains output frequency, or some proxy.

Output frequency needs to be 60Hz ±1.

Frequency spec dictates engine speed 3600 ±60 RPM or 60 ±1 revs/second.

Tachometer pulse from the conventional ignition would be 2 pulse/rev(4 cyl. engine) or 120 pulse/sec

Finally, there is a gear tooth sensor on the flywheel that seems to be seeing about 49 teeth around the circumference. This based on two separate readings of ~61.5Hz on the mains output and ~3.03KHz on the gear tooth sensor with a DMM. BTW this sensor has two wires, one is ground and I see 300mVAC across the two. Seems I will need an op-amp to boost this enough to be read as high/low. Note that this sensor connects into one of those black box interlock systems I mentioned earlier, so whatever I do ought to be pretty high impedance, like my DMM.

I have been a little chicken about connecting my scope to this system; one of these days I need to get a battery powered scope.

Let me just note here that I have seen this thread and I am not feeling the need to time every tooth: Fly Wheel Sensor - Best Approach?

I am thinking that using the gear tooth sensor would be ideal, since that presents a proxy for RPM inside the control box where I want to mount my speed control. Mains/Tach signals are either dangerous or low resolution.

I seem to recall having read that there is an option to use one of the timers as a counter. I can't find that so I am looking for help here(and if I am going about this all wrong please feel free to set me straight).

What I thought I understood was that I can just let a hardware counter count until I am ready to check it, then take that value, reset counter to 0, check elapsed time and arrive at an RPM reading. An 8 bit counter should be plenty, that's enough to count for over 5 revolutions.

If this is feasible then I wouldn't need to worry much about timing. I could just let the hardware count teeth for about 1/2 revolution(~25 teeth, 1/120sec), make an adjustment if needed, rinse, repeat.

If it is not feasible to use a hardware timer in this way please suggest alternatives.

Yes I know I could count digital inputs by polling for state, my concern there is that then the Arduino might be too busy to properly run the LCD and check for user input. I may just replace the arLCD with an Uno once I am done with development but during development I think a UI would be handy.

[wildbill]

I have no idea how to do what you describe with a hardware timer, but a common approach to this problem if you're not confident with polling the input is to use an interrupt. I happened to be playing around yesterday with this method for a signal in the 1000Hz range which was working nicely, so 120Hz should be very plausible.

[MarkT]

Can you provide more information about the existing mechanical govenor and damper?

[cattledog]

I am thinking that using the gear tooth sensor would be ideal, since that presents a proxy for RPM inside the control box where I want to mount my speed control. Mains/Tach signals are either dangerous or low resolution.

I think your first step make a decision between the gear tooth sensor and tach signal.

Why do you think that the tachometer output at 120 pulses/second at target speed is too low of resolution? What is the voltage of the tach signal? Is it a square wave or a short pulse?

Regarding the magnetic reluctance gear tooth sensor, you will need to process the low voltage ac output into a 5v square wave for the Arduino. Is there a gap of missing teeth anywhere on the flywheel?

Once you decide on the signal source, counting pulses with either an interrupt, or a timer/counter is not an issue.

You could also use the FreqMeasure library.
FreqCount is often used for higher frequencies, but may be considered as well particularly if you use the gear tooth sensor.

[Dave_Anderson]

wildbill:
...use an interrupt. I happened to be playing around yesterday with this method for a signal in the 1000Hz range which was working nicely, so 120Hz should be very plausible.

I am leaning more toward the 3KHz AC signal since it is not as inherently noisy as the tach signal. Also the tach signal can have variations that could confuse the PID algo, as the system switches between different loading the vacuum advance and centrifugal advance on the timing will skew the controller's sense of whether the motor is speeding up or slowing down. Granted this can be expected to transpire over a very short time period as the system transitions from one (hopefully) steady state to another, but in my opinion this is the most important operational period/scenario to get right.

Am I wrong in thinking that using an interrupt to count pulses would likely interrupt the movement of the stepper? Perhaps if all it is doing is updating a counter most of the time then the few times the stepper is interrupted it wouldn't be too much of an issue. However, if steps end up being missed then the PID will have the wrong idea about how many steps were output. Consider:

• PID says move stepper 20 steps.
• After 10 steps, an interrupt occurs:
• The PID calculates the next amount/direction to step and starts sending steps.
• Steps are all sent(Let's say 20 more)
• Next interrupt with count > setCount triggers calculation with result R
• PID acts on what it thinks it knows, it assumes 40 steps gave result R, but it was only 30
• Now PID sends a larger-than-needed number of steps to get result R2.

Or... am I overthinking it?

[Dave_Anderson]

MarkT:
Can you provide more information about the existing mechanical govenor and damper?

Sure. It's basically a fly weight governor, functionally not very different from the type used on steam engines(I think James Watt invented the device). It is pulley driven and connects directly to a bellcrank on the carburetor throttle shaft.

The governor itself is pictured at the top right of the attachment. On the top right lever, scan down from the two holes at the end of the lever, past the single hole, and a bit below that you will see a notch in the right side of the lever. The damper touches there and compresses when the lever moves to the right.

The best replacement damper I found replaces an old diaphragm dashpot that is NLA. Here is a link to the Parker-branded version. Not shown but easy enough to find in Parker's catalog, I also have a nose piece that eliminates side load on the damper.

This setup works beautifully, until it has run for a couple of days and with the heat and movement the silicon leaks out. I have been through more than a couple of these. Bottom line from Parker, it was never intended to withstand the heat of living on an internal combustion engine and they will not replace any more "abused" parts, nor can they offer a suitable alternative.

I have to run for a bit, will answer remaining replies later tonight.

[Dave_Anderson]

Dave_Anderson:
...not as inherently noisy as the tach signal...

To clarify, there is no designated tach signal. It's a rudimentary system with a reluctor pickup instead of points. Common practice with aftermarket tachometers is to attach them to the negative side of the coil primary. This is what I am referring to as "tach signal" which is going to be relatively noisy.

[cattledog]

I am leaning more toward the 3KHz AC signal since it is not as inherently noisy as the tach signal.

No problem, you just have to convert it to a signal the Arduino can read, but you appear to have a handle on the electronics from the previous thread.

I doubt that using external interrupts to count or time the flywheel teeth at your speeds will cause problems for the PID or the stepper if the isr is short and done properly.
Using the Timer is somewhat more complex but is probably more precise and you can either time the pulse separation with the input capture feature, or count them with the external clock source input.

It would be helpful to review Nick Gammon's tutorials on both Interrupts and Timers.

Using one of the Stoffregen frequency libraries mentioned earlier is also an option.

[Dave_Anderson]

I meant to post this last night but just at the instant I clicked on "Post" the power went out, taking out my broadband as well... California PG&E situation. My ISP went down as well as my cell carrier.

Fortunately I was able to save this post in a text file before shutting down. Will reply to new cattledog post in a minute...

cattledog:
I think your first step make a decision between the gear tooth sensor and tach signal.

I think that absent new info I am going to go with the gear tooth sensor and FreqCount for my next experiment. That's going to be a bit involved, as I need to drag my old Tek. scope down to the generator shed, measure the gear tooth signal properly, and build an amplifier to interface with the arLCD. Then I'll whack together a sketch and run the counter through some tests. Thanks for the pointer, I just wan't looking in the right place it seems.

cattledog:
Why do you think that the tachometer output at 120 pulses/second at target speed is too low of resolution? What is the voltage of the tach signal? Is it a square wave or a short pulse?

I misspoke. I meant poor quality, noisy, smells of elderberries...

cattledog:
Regarding the magnetic reluctance gear tooth sensor, you will need to process the low voltage ac output into a 5v square wave for the Arduino. Is there a gap of missing teeth anywhere on the flywheel?

Much too archaic for that. It's reading off of the starter ring gear.

cattledog:
Once you decide on the signal source, counting pulses with either an interrupt, or a timer/counter is not an issue.

You could also use the FreqMeasure library.
FreqCount is often used for higher frequencies, but may be considered as well particularly if you use the gear tooth sensor.

Perfect, thanks for this. It's exactly what I needed to get unwedged.

[Dave_Anderson]

cattledog:
No problem, you just have to convert it to a signal the Arduino can read, but you appear to have a handle on the electronics from the previous thread.

I doubt that using external interrupts to count or time the flywheel teeth at your speeds will cause problems for the PID or the stepper if the isr is short and done properly.
Using the Timer is somewhat more complex but is probably more precise and you can either time the pulse separation with the input capture feature, or count them with the external clock source input.

It would be helpful to review Nick Gammon's tutorials on both Interrupts and Timers.

Using one of the Stoffregen frequency libraries mentioned earlier is also an option.

Thanks for your help, I will look into those tutorials tonight, especially the one on timers.

[Dave_Anderson]

Still lots more reading to do, but I am curious as to why you(cattledog) presented two sets of each timer and interrupt libraries. Is it because the latter set is possibly more efficient or some other reason?

Side note, I connected up my scope to the gear tooth signal and I simulated a circuit that ought to trigger the counter nicely. Interestingly, the scope seems to have picked up some runout on the ring gear. Attached...

One last piece of data is to actually count the gear teeth. Best way to be sure of the count, given my equipment.

[system]

Hello Dave.

How about fix a magnet to the flywheel and use a Hall Effect sensor to detect it. The sensor can be a digital input to the Arduino. Yr sketch can poll this input and easily compute rpm.

John.

[cattledog]

Good progress. I hope the fires are out in your location and the power is back.

I simulated a circuit that ought to trigger the counter nicely

You will need to keep this signal under 5v. I'm not a hardware guy, so I can' really comment, but if in the actual application, the signal is not fast enough rising/falling or too noisy, then you can add a Schmitt trigger.

Still lots more reading to do, but I am curious as to why you(cattledog) presented two sets of each timer and interrupt libraries. Is it because the latter set is possibly more efficient or some other reason?

Im not quite sure what you mean by the two sets of each timer and interrupt libraries. really wasn't certain of the input you would use, and the count rate, so I gave you both of the Stoffregen library references. It sound like FreqCount is the better fit to your gear tooth input at about 3000 counts per second. You can certainly code this without using a library if you want.

I'm not clear about the update period required for your PID and system requirements, but at 3000 cps and a 50 ms counting window you can expect 150 counts so the counting error of +/- 1 count in a period should not be an issue for your 60Hz +/- 1.

I'm thinking that the rpm measurement is going to be the easy part compared to the rpm control

[Paul_KD7HB]

Dave_Anderson:
Sure. It's basically a fly weight governor, functionally not very different from the type used on steam engines(I think James Watt invented the device). It is pulley driven and connects directly to a bellcrank on the carburetor throttle shaft.

The governor itself is pictured at the top right of the attachment. On the top right lever, scan down from the two holes at the end of the lever, past the single hole, and a bit below that you will see a notch in the right side of the lever. The damper touches there and compresses when the lever moves to the right.

The best replacement damper I found replaces an old diaphragm dashpot that is NLA. Here is a link to the Parker-branded version. Not shown but easy enough to find in Parker's catalog, I also have a nose piece that eliminates side load on the damper.

This setup works beautifully, until it has run for a couple of days and with the heat and movement the silicon leaks out. I have been through more than a couple of these. Bottom line from Parker, it was never intended to withstand the heat of living on an internal combustion engine and they will not replace any more "abused" parts, nor can they offer a suitable alternative.

I have to run for a bit, will answer remaining replies later tonight.

Have you considered making a mechanical linkage so you can mount the dashpot away from the engine?

Paul

[Dave_Anderson]

NissanCedric:
Hello Dave.

How about fix a magnet to the flywheel and use a Hall Effect sensor to detect it. The sensor can be a digital input to the Arduino. Yr sketch can poll this input and easily compute rpm.

John.

Hi John,

I already sort of have this, with the existing gear tooth sensor. Which has 50x the resolution and is already wired to t terminal strip in the control box.

[Dave_Anderson]

cattledog:
Good progress. I hope the fires are out in your location and the power is back.

Thanks, all is well. No major fire fire close by, power was back midday Saturday. The generator kept us going but its behavior underscored the need to finish this project.

cattledog:
You will need to keep this signal under 5v. I'm not a hardware guy, so I can' really comment, but if in the actual application, the signal is not fast enough rising/falling or too noisy, then you can add a Schmitt trigger.

Thanks for the tip, I looked around and don't have anything suitable for a Schmitt trigger, I'll see if I can get something here for the weekend. I was able to bring my output to 5V pretty easily by changing R2 to 100K(attached), so I'll try the simpler version just to see how it flies. I'll probably sub a 150K pot when I prototype it.

cattledog:
Im not quite sure what you mean by the two sets of each timer and interrupt libraries. really wasn't certain of the input you would use, and the count rate, so I gave you both of the Stoffregen library references.

You did indeed point out two very promising libraries as well as two very rich and detailed tutorials which I somehow imagined were additional libraries. Carry on.

cattledog:
It sound like FreqCount is the better fit to your gear tooth input at about 3000 counts per second. You can certainly code this without using a library if you want.

I agree, that looks to be the one. Thanks again for pointing me in the right direction, including the tutorials.

cattledog:
I'm not clear about the update period required for your PID and system requirements, but at 3000 cps and a 50 ms counting window you can expect 150 counts so the counting error of +/- 1 count in a period should not be an issue for your 60Hz +/- 1.

Still pondering. I agree about the sampling rate, way overkill. I like that that came more or less for free though. It's a good thing(until it isn't). I was thinking I could sample a portion of a revolution and have a very accurate measure of the speed, then send out steps to the stepper, then spend some time doing something interesting with the display. But something like the sample of ~3 revolutions that you suggest might be more sensible, as it would average out the power/drag variations in rotational speed that occur during each revolution. I am going to have to run some experiments and find the limits of how fast the system can respond to throttle input, meaning I'll have to gather run data once I get it hooked up mechanically/electrically. Test & tune.

cattledog:
I'm thinking that the rpm measurement is going to be the easy part compared to the rpm control

I have a feeling you're right about that. I'm going to try to mount the stepper in a way that I can quickly switch back and forth between it and the mechanical governor.

[Dave_Anderson]

Paul_KD7HB:
Have you considered making a mechanical linkage so you can mount the dashpot away from the engine?

Paul

No, I became weary of the heroics, and decided to modernize. Maybe if I had thought of it before I tried nearly every damper and dashpot that looked remotely workable...

In any case, with the amount of force normally exerted on the damper any extension would have to be very stout, which would bring its own challenges. +1 for creativity though, thanks!