Listeroid Governor Control

[Samo]

Thanks Ed,

I do like the zero sampling idea, that makes sense to back off the servo if the load is zero or unknown. In terms of runaway, the mechanical governor is still the main control, so I'd expect it to back off too. However "expect" is not good enough... I'm going to test that assumption.

I don't think the Servo I use would be strong enough for end pull, and it needs some buffering to protect it from the direct movement of the governor. I'll try it for an experiment and test that assumption too.

cheers,
John

[Tom]

Ed, I don't think a runaway is possible due to the limited amount of pull on the servo. The worst I see happening is that engine over speeds to 700 rpm or so. Ingenious design Samo with the servo between springs. Good readable code too.

[EdDee]

Hi Tom/Samo,

I may just be a bit paranoid!

Was thinking about my governor hiccups and the best way to allow for mech wear on linkages/fine tuning.... I ran around in circles rebushing all the hinge points and removing slop to the point that the governor eventually started to bind if the lube dried out... In the end, all I found that was needed was a SMALL spring pulling on the pump rack to pretension the linkages(in line with the IP rack)... probably way less than 1oz load...This neatened up the seesaw and got things nicely stable... I also found, that with this spring in place, governor mech adjustments became quite precise....in real terms, it amounts to around 1/2 to 1 1/2 turns on a 6mmx1 nut to adjust the frequency +- 5%... Ideally, have the pretension spring on the closing side of the pump, so if a linkage loses a pin, the rack pulls closed and the beast shuts down.... On my unit, it is the other way round, it is pretensioning open rather than closed, not an ideal situation. The reason for this is that my rack doesnt have a place to hook the spring into.... When I rebuild the pump, I will employ a drill and sort that small matter out...

Given the small amount of spring tensioner travel required to fine tune the frequency when slop is catered for(+-1 to 2 mm on my setup), you might be able to end-pull the spring quite well if you reduce your pull radius. I, personally, am not wild about R/C servos and the like....I have put too many heli's into the ground when they have failed on me due to vibration, hence the suggestions....(Incidentally, when the servos have failed, they tended to fail in such a manner that they locked fully one way or the other, might be worthwhile to see your overspeed rpm(safety please!!), with  the servo held fully in max throttle position with no load on the engine...

Just a thought....

Cheers
Paranoid Ed

[Samo]

Thanks Ed,

I can replace the servo with an actuator, they are typically much harder to break. However there's no positional feedback in the ones I've looked at, so I'd have to implement that myself or make one using a stepper motor. The software does completely control the travel range of the servo, from 180 degrees right through to total paranoia! That means I can set a safe max engine speed.

Actually I've been quite busy after work tonight, I've implemented the software change/suggestion on zero mains detected for backing off the speed, and that works. Also, I've turned off the servo from a 2400 watt load, then turned off the load, Hz jumped to 53, but haven't tried a bigger load than that yet.  The better the mechanical governor the less impact/work the servo does. So I've still got work to do there for my setup. On that topic today (sans servo)  I also tried the exact springs (7/16 x 3 x 0.047 and 9/16 x 3 x 0.054)  mentioned elsewhere on the forum but both hunted (too light) for my 10/1. But the servo works!

Software for the record: www.mrx.com.au/pickup/Guvna/Guvna_Fine_Control.txt  (updated)
Control Box:                  www.mrx.com.au/pickup/Guvna/ControlBox.jpg

cheers,

John  

.

[veggie]

Samo,

Very nice project. something similar to what I am working on (also with an Arduino).
I just glanced at your code.
It looks like you are converting the difference between the Target HZ and the Actual HZ into a percentage and then converting that result to an integer to be used as the "offset" value.
I am wondering what happens if the "rate of change" in speed occurs at a faster rate than the software correction can keep up with?
Have you had any cases where you apply load and the engine RPM continues to drop regardless of servo corrections?
I suppose the mechanical governor would help to prevent any drastic fall off in speed. That's why I like your idea of still using the original machanical governor. Sort of a fail-safe preventing a complete collapse in rpm's.

One thing I have been playing with is a applying a larger correction factor as "rate of change between" the ACTUAL and the TARGET increases.
In other words, exponentially increase the correction value as more correction is needed.
This helps the software (and the servo setting) stay ahead a overload droop situation or an over-speed situation.

Thanks for sharing your project,
Veggie

[overbore]

Anyone see a market for a 60 cycle kit to be sold to us?  It appears that many of us are "the market" for an entrepreneur .
overbore

[dieselgman]

On our commonly installed larger gensets we use an electronic governor product that uses a magnetic pickup... has adjustments for frequency selection and sensitivity and droop, uses a very small actuator on the fuel pump and augments a mechanical governor in a somewhat similar fashion to what has been shown here. The idea is sound and proven. The off-the-shelf hardware costs quite a bit though. If I remember rightly, about $300 for the control, plus additional for pickup and actuator.

dieselgman

[Jake65mm]

Gary are you using PG controls?

On our commonly installed larger gensets we use an electronic governor product that uses a magnetic pickup... has adjustments for frequency selection and sensitivity and droop, uses a very small actuator on the fuel pump and augments a mechanical governor in a somewhat similar fashion to what has been shown here. The idea is sound and proven. The off-the-shelf hardware costs quite a bit though. If I remember rightly, about $300 for the control, plus additional for pickup and actuator.

dieselgman

[Samo]

I am wondering what happens if the "rate of change" in speed occurs at a faster rate than the software correction can keep up with?
Have you had any cases where you apply load and the engine RPM continues to drop regardless of servo corrections?
I suppose the mechanical governor would help to prevent any drastic fall off in speed. That's why I like your idea of still using the original machanical governor. Sort of a fail-safe preventing a complete collapse in rpm's.

Not yet Veggie, I let the mechanical governor lead and help it a bit, because if the rate of change is too aggressive interplay occurs between the mechanical governor and the electronic fine tune. Then they start chasing each other. So far with my limited testing smoother is better.   

One thing I have been playing with is a applying a larger correction factor as "rate of change between" the ACTUAL and the TARGET increases.
In other words, exponentially increase the correction value as more correction is needed.
This helps the software (and the servo setting) stay ahead a overload droop situation or an over-speed situation.

Veggie, this code below does exactly what you've written. I'm using integer math results, so every value is x100 for precision. As an example here I take the absolute frequency minus target frequency, then divide to something sensible (smooth) and add 1 because I don't want a zero result.  So example for 51Hz (( 5100 - 5000) / 20) +1 = 6, move the servo on six units, at a higher frequency 52Hz  ((5200 - 5000)/20) + 1 = 11, as you can see the further away from the target the bigger the servo move. 

    //Adjust the servo more, the further away from the target frequency, + 1 because working with integers and I don't want a zero move.
    FreqStep = abs((frequency - TARGETHZ) / FREQDIV ) + 1;

cheers
Samo

[Thob]

You can decrease the time between "updates" and still keep the averaging of the frequency by using a simple trick.  Each time you get a frequency sample, you add it to the prior sum and subtract out the oldest sample (you have to keep track of all samples).  That way, you have an average of the frequency at every sample.  You have to get the first (n-1) samples before you can start, but after that you can update more often.

You can also eliminate the "divide by n" (for n samples) by multiplying your target by n up front.  So if you average 5 samples, you simple add them up and compare to 250 (for 50 Hz).

If you're measuring time between samples to get frequency, you can eliminate the reciprocals and just work in "period" as well.  For 50 Hz, the period is 20 milli-seconds, or for 5 samples 100 MS.

[dieselgman]

Some of our sets use the GAC (Governors America Corp) setup atop a Stanadyne rotary pump... It is the GAC I was thinking of in my comment because of its very modest "helper" mode alongside the engine's main mechanical governor. The GAC actuator makes only very small adjustments to the pump output to hold a pretty tight frequency control. Woodward and many others have similar setups though.

dieselgman

[Samo]

Thanks Thob,

Some good ideas there...  I do like working in Hz over milliseconds, it correlates better to the Genset metering for me. However I will buffer the history and try that approach as you suggest, will let you know how it goes.

cheers,

John

[BruceM]

The interaction between the two systems (oscillation)  is an important aspect, as you have pointed out well, Samo.  The electronic compensator must be the slower of the two to have stability, so that rules out the sort of fast compensation for large load changes I was (very) erroneously thinking of; it would certainly just result in oscillation of the mechanical governor.  I was WAY out to lunch to suggest it.

A direct electronic governor could reduce load transient response, but the safety/failsafe issues are serious ones with big cast iron flywheels.

Very impressive, Samo. 

[Samo]

I have a couple of hair-brained suggestions for enhancements:  (that you've probably already considered).
..............

2. Transient performance upgrade:  by sensing AC current draw, throttle correction for big changes in load could be applied immediately, BEFORE the frequency sags or overshoots, thus reducing both maximum error and load transient response time. This does increases the real time complexity of the software considerably, but I'd be happy to contribute if need be.  When you decrease your frame time, you'll have to allow for the normal compresssion/power stroke speed variation so as to avoid an undamped oscillation.  Your current frame rate was well chosen for a slow smooth correction, but for this I'd want a bit faster and with acceleration dampening.  I realize this is probably lipstick on the pig, but it's hard to resist sometimes.

Best Wishes,
Bruce

Hi Bruce,

I think I've cracked this now....

On your suggestion I'm adding a Current Transformer to the Generator output, and adding monitoring of the current draw to the software. I've determined through some monitoring that there's a linear fuel response for current draw. The figures I'm posting below are typical of the measurements I've taken:

@       0 watts servo position = 100
@  1200 watts (5A) servo postiion = 170  (+70)
@  2400 watts (10A) servo position = 243 (+142)

This means that I can pre-position the servo as soon as I get a current reading, and I can do this from just 1 current reading because I can predict the entire current to servo position map. The servo can be pre-positioned within the first 0.5 seconds, before the flywheels loose momentum.

Once the servo is in the "ballpark" then the slower time adjustment to 50 (or 60) hz will take place. Then once stable, I've confirmed another current to servo position, or at least confirmed the mapping....

Well that's the theory anyway... working on the current transformer input and it will take me most of this week to put into practice. I hope all that makes sense. Will post again with results good or bad.

cheers,

John

[BruceM]

That might work, Samo, if the load related offsets are relatively small so don't cause either delay in the mechanical governor response or outright oscillation. 
Looking forward to your results!