Computerized engine controller

[mjn]

There have been several discussions in the past about engine monitoring, and speed control.

I am in the final phases of debugging the software for my computerized engine controller.   The controler provides full automatic operation from startup to shutdown.  During operation the cpu monitors all critical engine parameters.  If anything strays out of bounds, the controller initiates an "emergency stop".

Engine RPM, water temperature, oil pressure and injector line temperature are all monitored.

Once the engine is up to temperature, the controller switches the engine to WVO fuel, and will also do a purge upon shutdown.

The final piece of the system (I'm still debugging) is a PID controller to provide accurate speed control.   The stock governor on my engine allows the RPM to sag by 100 to 150 RPM from no load to full load.  The PID controller maintains the RPM at 1800 from no load to full load plus or minus 1 RPM.

This is all implemented using a single Atmel ATMega8 cpu.  The speed control is via a stepper motor and leadscrew which hooks up to the governor spring.  The circuit is built with wirewrap and hand solder (no printed circuit board...sorry).  The software is written in 'C'.  Once I have it debugged, I'll release the full source under a BSD or similar license.

Here is a state diagram of the system operation (Click here for pdf version http://martin.nile.googlepages.com/statediagram.pdf)


I also support full manual operation of the engine.  After shutdown, the controller moves the speed control back to the normal run position, so if there is any problem (dead battery etc) the engine can be started by hand.

Here is what it looked like before I hooked it up to my engine:

I still need to implement the hour meter, and I would like to be able to change any of the runtime parameters without having to reprogram the cpu. 

You can read about the whole thing on my generator controller page: http://martin.nile.googlepages.com/automaticgeneratorcontroller

[max.network23]

Very cool set-up. I understand some of the pain you are going through. I have played with some of the smaller Atmel product line. (ATiny11/12)

Nuts & Volts magazine (Or is it Servo?) has been running a multipart article about using a wireless remote control to change run-time parameters on robots. Very similiar to what you want to accomplish.

If I may suggest, it appears the 'only' thing you need to do is add a small lcd and 4-5 push buttons. Two buttons would scroll through menus & variables and the others would select and increment/decrement values.

[rmchambers]

That is very slick indeed. 

[mjn]

If I may suggest, it appears the 'only' thing you need to do is add a small lcd and 4-5 push buttons. Two buttons would scroll through menus & variables and the others would select and increment/decrement values.

All part of the plan... I currently have it plugged into my laptop, but long term I want to have an LCD display.  I just bought a 4X20 lcd on ebay for $4.00.   Unfortunately, I'm getting pretty short on flash memory on the cpu.  I'm using 7600 out of 8192 bytes of memory.  Hopefully I'll have enough room to code a simple menu system.  Otherwise, I'll upgrade to an ATMega168 which has 16k of flash memory with the same pinout as the Mega8

[Tugger]

Awesome...great work..
I planned on researching a basic stamp controller over next winter todo this very thing...
Basic is what i learned in school 26 years ago..(maybe some of it stuck)..
The only thing extra i wanted to include was to start a second engine/generator( and controller) and phase the second engine/generator to the first, closing a contactor when in sync...
cheers

[mjn]

This was supposed to be my "winter project".  Unfortunately, it took from February thru June to get the software written.  I've got a 6/1 listeroid in pieces waiting for me to finish with this project.

[mobile_bob]

MJN:

a couple of questions if i might

1. how fast is the reaction time on the screw actuator to no fuel?
for instance if you loose load at max power, and the engine surges, how fast will it unscrew and lower the rpm?

2. most of the micro controllers are single instruction sequential in operation, are the atmel chips the same in this regard?

3. have you considered parallel processing such as ladder logic?
where many functions are done concurrently?

4. are you familiar with the PLC's which are programmed in ladder logic?
do you see a problem in using them?

i like the idea that you are working on developing your system, pretty cool!

the only issue i have in a control system is the proprietary nature of the software, hardware etc.
when i grow old and forget how to work on or are unable to work on the system, i think at least for
me it would be prudent to look into industry standard controllers to do the duty for me.
my thinking is maybe i could get an industrial repair/programmer to service the system if need be.

your thoughts?

anyone else see it differently?

bob g

[Doug]

I see where your going Bob.....

MJN is way out there on the edge. Reminds me of a home brewery I know a fellow built using an Intel 186 industrial computer. Cool stuff well above my level!

PLCs have advantages and disadvantages, scan time and JSR commands are basicaly the exact same thing in both so I don't see an advantage of using industrial automation if you can program and compile for a MP based system.

Ladder logic isn't all its craked up too be. The latest generation of machines I see are being powered by Intell Pentium chips. Not because they are doing any multi tasking, but because the damb programs are getting so long in ladder and waiting for information to be exchanged between machines is slowing them down. Ladder is also a clumsy way of telling a machine what you want it to do. Newer systems and especialy eroupean machines use stuff that looks like a combination of Boolean algebra and Martian, but its fast!

The solution is raw speed tossed at the same one instruction at a time. Not my solution, I'm starting to hate everything requires communication to do it job and these huge programs with stupid crap like " Voisy's bay shipping register " or " mystery coil " that joker tech guys add to mess with my mellon.

Ever faster proccessors for ever growing ladders......

Evermore ape like I walk on my knuckles now, grunt and try and forget everything about anything automated beyond a reasoanable level. Make it stand alone with a courtesy feature of exchanging data, small programs, hard wire back ups.......

old 8 bit processors have there advantages
end rant

Still like the Z80 and could probably still make it o stuff ( I think I could even still make a diode matrix for one to boot ), but I can't burn a cd, won't carry a cell phone and get the messages out of the blinky light on the phone, thats th wife's job.

Modsoft.....
AB APS....

These were ugly dos based programs for the 984 compacs and SLC500. But even though the hard ware has remain basicaly the same. New Machines from Rockwell ( AB ) won't accept programing formt he APS software.
And the 984 will but have you found a modern PC lately that will run a windos ap?

[mjn]

1. how fast is the reaction time on the screw actuator to no fuel?
for instance if you loose load at max power, and the engine surges, how fast will it unscrew and lower the rpm?

Here is a graph showing system response time from zero load to full load.  I did not graph the full load to zero load response time, but the controller catches itself before the rpm overshoots by 20 rpm.

From zero to full load, the rpm stabilizes within 5 seconds.  From full load to zero load, the rpm stabilizes within 3 seconds.

2. most of the micro controllers are single instruction sequential in operation, are the atmel chips the same in this regard?

The cpu is totaly sequential, but at 16 million instructions per second, I can get a lot done in a short amount of time.  All of the time critical functions are implemented in interrupts.  Interrupts are typically serviced within 4 cycles.  The most time consuming interrupt is the stepper motor which runs at 600 steps per second.  The tachometer is implemented entirely in hardware, (Other than the cpu handling counter overflow when rpm is less than 1 rotation per second).  The realtime clock requires 250 interrupts per second, but the service routine is very short.

3. have you considered parallel processing such as ladder logic?
where many functions are done concurrently?

I've never worked with ladder logic.  I'm primarily a computer programmer, so my solution reflects that.

4. are you familiar with the PLC's which are programmed in ladder logic?
do you see a problem in using them?

I highly suspect that a full blown PID controller would be tough to implement on a plc, but I'm not really familiar with the capabilities.

the only issue i have in a control system is the proprietary nature of the software, hardware etc.
when i grow old and forget how to work on or are unable to work on the system, i think at least for
me it would be prudent to look into industry standard controllers to do the duty for me.
my thinking is maybe i could get an industrial repair/programmer to service the system if need be.

That is one of the reasons I designed the system to be fully operational without the controller.  If the cpu goes haywire, I just turn it off and start the engine by hand.  Everything still works like it did without the CPU.   Note however, that none of this is proprietary.  The schematics and full source code are available.

[mobile_bob]

Martin:

i am impressed with the actuators response time, most particularly the response at loss of load
where an engine could see significant overspeed
but if yours will catch it at around 25rpm overspeed that is damn good in my books

Doug:

as far as ladder logic goes, (at least as far as i am concerned) with what i am trying to control
i can see no reason that the code (ladder) needs to be as bloated as something a microsoft code
writer might find attractive.

on the contrary, for most all control of not only an engine, but likely the whole system, it would
seem to me that any code whether in basic, c or ladder could be done fairly simply.

now i should also say i am not a programmer or a code dog, but i have worked a bit with the bs2 basic
and something hit me like a hammer. that being the different ways of coming to the same conclusion.

a code engineer will do a million things with 10 dollars of chip, and the resultant code will be quite complex

a hardware guy like me can do a few hundred things, with perhaps 100 dollars in parts, with the resultant code
being quite basic.

now if i was to build systems to sell, i would have to design like the big boys do,, 10 dollars in parts and thousands of lines of code

but i am not in it to sell, so i will spend a bit more in parts, divide the load, and dramatically reduce the code.

i have proven this to my satisfaction using pbasic on the bs2, i have little doubt that using ladder would be any different.

i am a big fan of software driven interrupts

bob g

[GuyFawkes]

so you have a servo motor driving a screw thread, and a moving threaded block that controls rack position.<p>

force required to rotate thread and servo motor by pushing or pulling threaded block is essentially infinite, eg it exceeds the material strength so shit will just break first.<p>

Racking my brains and I can't think of any example anywhere of a throttle being driven by a screw thread.<p>

I can remember reassembling a detroit after the control arms were mixed up (unbeknownst to me, and no I didn't check) and can remember well the hopeless feeling of trying to shut down the rack by force (two of us) against the hydraulic pressure.<p>

the default, fail safe and natural position of the rack should always be closed, your system, while clever, makes it quite simple to envisage an error or failure of one component on the circuit to drive the rack fully open, which will dangerously overspeed an engine and possibly lead to a runaway, both of these are potentially fatal, flywheel bursting events....<p>

even substituting a linear actuator for a stepper won't help, it is just an "unrolled" stepper, and as long as the power is on it will lock in place and not allow the rack to close normally.<p>

can I suggest you re-visit this design before releasing it to the public, a BSD style licence will not absolve you from a lawsuit being filed against you should anything go wrong...

[rmchambers]

From what I read from MJN's description the stepper motor acts upon the spring for the rack not the rack itself which would in theory allow the mechanical governor to close the rack down if the stepper motor got stuck. 

Martin, did I understand your linkage correctly?

Robert

[mjn]

The stepper motor does indeed act on the governor spring.  I am really only "helping" the built in engine governor. 
If something breaks the connection between the controller and the engine at the worst possible moment, then your scenario is completely valid.  Since I'm merely helping the built in governor, I don't know if my engine will overspeed to self destruct with the stepper stuck in the "full on" position. 

I know that the overspeed code works because I tripped the ESTOP several times while tuning my PID controller.   (I have the speed limit set to 2100rpm even though the engine is rated for 2200 rpm.)

I have attempted to address the some of the worst case scenarios in my design:

If the stepper motor mechanism fails at the worst moment, the CPU will see overspeed, and initiate an emergency stop.  Estop involves closing the speed control (which might be broken) and pulling the decompression lever.  The decompression lever is guaranteed to shut things down.

If the CPU hangs at the worst possible moment, a hardware watchdog timer will expire and force a reset.  Upon reset, the cpu will see overspeed, and initiate an ESTOP.  The watchdog timeout is short enough, that the cpu will probably catch the overspeed condition before it becomes an ESTOP scenario.

If the stepper motor fails at the worst moment, and I lose the tachometer, the CPU will see loss of tach signal and initiate an ESTOP regardless of how fast the engine is going.

Your point is well taken regarding the liability.  My point about the BSD license, is that I want the source to be fully open.  There are other licenses which limit the liability of the author.

[mjn]

I mis-spoke last night when I quoted the "recovers within 20 rpm".  The numbers were flying past on the screen and the number which stuck in my head was the wrong one.  It turns out that within the first sample period (.1s) after the load going away, the rpm has reached 1818 rpm.  At that point the controller starts backpeddling, but the rpms peak at 1860rpm .4 seconds after the load goes away.

Here is the graph of how the two governors handle the "full to zero load" condition



At the moment, I still have some minor overshoot and a 5 rpm steady state error to get worked out.  In theory, increasing the Igain should correct the steady state error, but it introduces significantly higher overshoot and more oscillation before settling at 1800 rpm.

[GuyFawkes]

The stepper motor does indeed act on the governor spring.  I am really only "helping" the built in engine governor

that's an improvement on what I was picturing, but it still ain't perfect....

you are talking about various failure states of "your kit" and saying different sections will catch other sections failing, if you know anything about these things you know there are plenty of scenarios where that simply won't happen, you get a catastrophic failure of the whole system, and then in dying it "helps" the built in engine governor by trying to apply a wide open rack.

what I am talking about is a system where the default state is "rack fully closed" and you have to jump through hoops to achieve any other state, both by electrical and code design, eg the system has to juggle well enough to keep ALL the balls in the air before it will even consider allowing the engine to run.

the servo and threaded bar is a no-no from that point of view, because even if you latch a second system onto say oil temperature (first system reports to the PIC) which simply cuts all power to the servo, you still can't drive the threaded bar from the wrong end, whereas (in this example) if you used a linear actuator (a servo motor unrolled into a straight line) if you cut all the power it goes into free mode and even a weak spring can drag it through.

if you used a linear actuator you need a system to account for scenarios where the control signals die but actuation current it still there, because as you know actuation current "locks" steppers into place.

yes I know this makes things more complex, but that's what has to be done in industry, and if you adopt these methods as a starting point (bosch used a held-open-when-powered solenoid controlled fuel valve in their injection pumps) it does add complexity to some areas, on the other hand it simplifies other areas because it eliminated duplication... put half a dozen different methods in series to the aforesaid fuel solenoid and any one of them tripping into the default open circuit state will cut the fuel, then you just need to make sure each possible scenario hits at least two of them and you have plausible fail safe reliability.

cheers