Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - mjn

Pages: 1 [2] 3 4 ... 8
16
Other Slow Speed Diesels / Re: fuel limiting adjuster
« on: September 14, 2007, 05:24:27 PM »
The fuel limit adjustment is used to prevent wasted fuel when the engine is overloaded.  It is not directly related to the fuel delivery valve.  Here is how I suggest you adjust for maximum fuel delivery with a minimum of waste.

Start the engine, and load it down until it starts to emit black smoke.  Any further fuel added will just be wasted.  Turn the fuel limiting adjuster in until the black smoke almost goes away.

For reference, here is what the fuel delivery valve and spring looks like on my Changfa 195:


I don't have a good picture of the fuel limit adjuster, but here is where it screws onto the engine.  The red line points to the injector pump plunger.  The green line points to the governor fork.  The fuel limit adjustment screw sets the maximum amount of travel for the governor fork.


17
Listeroid Engines / Re: Source for spin on type filter mount.
« on: September 04, 2007, 06:24:18 PM »
You can try summit racing. (summitracing.com)

The permacool filter mount is available for $37. http://store.summitracing.com/partdetail.asp?autofilter=1&part=PRM%2D81794&N=700+400006+304356+115&autoview=sku
 is rated for 2 microns and uses 1-14 thread.  This is  same thread as the Caterpillar 2 micron filter Part# 1R-0750.  These are available at napa auto (part # FIL3528)



Another filter head is the "goldenrod" available at Northern Tool for $25.  This filter head is intended to be attached to a 1 inch pipe, and as such, it does not have any mounting holes. http://www.northerntool.com/webapp/wcs/stores/servlet/product_6970_910812_910812

I have heard that this filter is rated for 10 microns.  I have one of these on my Changfa engine.  I have not yet found a comparable part at Napa auto.

18
Other Slow Speed Diesels / Re: Changfa wiring
« on: August 14, 2007, 05:13:54 PM »
Here is one way to wire a Changfa engine:


Since you don't have the original switch, you can make do with two SPST switches (two wire).  One is the "start" switch (preferably momentary), and the other is the "charge" switch.  Both switches have one side tied to the plus side of the battery.  The other side of the start switch connects to the small terminal on the starter.  The other side of the "charge" switch is tied to the output from the regulator.  (On my engine, the regulator output is a red wire.)

After starting, close the "charge" switch which connects the battery to the regulator.  When you turn off the engine, be sure to turn off the "charge" switch to prevent the battery from being discharged through the regulator.



19
Engines / Re: Electric fuel control system for listeroid 6/1
« on: July 18, 2007, 03:19:29 PM »
I read the final report in the article mentioned in the first post.  The bottom line, is their implementation failed to work. 

Quote
Our control system is working, receiving data, and responding to it, though note in the sort of way that we would hope. Although our hardware is sound and functional, as of this writing we are still burdened with software difficulties that prevent our control system from operating effectively and consistently

Sadly, the article does not include any software.  They implemented a simple linear speed adjustment which caused the RPM to run away until it was manually stopped.  Their hardware implementation was valid, but their software was lacking.

A PID loop in a microcontroller is reasonably simple.  Tuning the gain variables is where the work is. Here is the PID code from my controller (somewhat simplified for clarity).


  error=TARGETRPM-rpm;
  pterm=error*pgain;                   // calculate the proportional value

  if( !(LIMITHI && pterm > 0)) {    // limit integral runaway if at upper limit
    sumerror += error;
  }
  iterm = igain * sumerror;            // calculate the integral value

  dterm = dgain *  (rpm-lastrpm);  // calculate the derivative value
  lastrpm = rpm;

  pid=pterm + iterm + dterm;

  setstepper(currrenposition + pid);  // apply the PID change


However, I think the proper application for a PID controller on a listeroid is to assist the governor, not replace it.  Even though I'm still tuning my PID controller on my Changfa, I have seen a huge improvment in performance because the RPM no longer slows down when load is applied.

Now, my generator starts my air conditioner easily.  Before adding the controller, the a/c would start, but not cheerfully.  I am now working on eliminating the overshoot which happens when load is removed.  (I'm already within my 5% frequency goal, I'd like to eliminate the overshoot entirely)


20
Everything else / Re: Computerized engine controller
« on: June 30, 2007, 12:10:13 AM »
Here is how the stepper motor links up with the governor spring.  It is almost as if this stepper assembly was custom designed for this application.  The wires are a total mess at this point because in order to change the programming on the controller, I have to disconnect everything from the engine and take it back into the house.  Eventually, I will tidy this all up



It is a little dark, but you can see where the stock speed lever has been disconnected, and the spring hooked onto the stepper post.

 

Here is the view from the other side.  You can see the screw with limit switches at both ends and the governor spring in the 1800 rpm run position.

--
Martin

Here is a 26 second video showing the controller starting the engine http://video.google.com/videoplay?docid=4096640855777707869.  Here is the sequence of events:
  • Off screen, I turn the switch from "manual" to "automatic".
  • The stepper moves all the way back to the zero position.  At the same time the glow plug relay energizes.   
  • As soon as the glow plug timer expires (about the same time as the stepper getting to zero) the glow plug relay is turned off and the engine starts cranking with the decompression relay energized.
  • Simultaneously, the speed control moves towards the "start" position (set for about 1000 rpm).
  • As soon as the RPM exceeds the minimum crank speed, the decompression relay is turned off.
  • Once the engine rpm exceeds the "start RPM" limit, the starter is disengaged and the controller enters a brief delay for oil pressure to exceed the minimum.  If oil pressure does not rise within a fixed amount of time, the engine will shut down.
  • The engine is allowed to warm up at 1000 rpm for 10 seconds.  For the final version this warmup will wait for the water temperature to reach a minimum value before continuing.  For debugging purposes I didn't want to wait that long.
  • Control of the engine rpm is then passed to the "PID controller" which calls for a big bump in speed.  You can see the speed overshoot and the controller back off and then back on a bit.  I'm still working on eliminating the overshoot.

Here is a 21 second video showing the engine stop sequence.  http://video.google.com/videoplay?docid=5327822853975211849
  • Off screen, I turn the switch from "automatic" back to "manual"
  • The stepper moves toward zero.
  • The controller waits for RPM to reach zero, and for oil pressure to drop below the minimum.
  • The stepper moves back to the 1800rpm run position in preparation for manual operation

21
Everything else / Re: Computerized engine controller
« on: June 27, 2007, 07:26:08 PM »
I appreciate everybody's comments here.  This project is far from finished.  As things progress I'll be incorporating your suggestions.

I agree with Bob that the optimum design is probably a hybrid which involves the classic "murphy switches" and computer control. Even though this controller may not represent the best form of protection, it is far better than what this engine came with (nothing). 

I think one of the reasons for the general hatred of computer controls is the dreaded "black box".  The good old discrete components could be traced, analyzed and repaired, but when the computers came in, you no longer could fix the problem yourself.  There are few things that I dislike more than being dependent upon somebody else to solve my own problems.  That is why I have a generator in the first place.  I don't want to rely on the power company to keep the food in my freezer from turning into mush.

It is for this reason that I am being fully open with my system.  I don't expect anybody to ever build an identical copy of this, but if they ever want to build their own, they have all of my design available as a reference.

For those people who don't find joy in building a computer controller by hand, I suggest the murphy ASM150 which is a computer (gasp..) controller which provides basic start/stop and protection. http://www.fwmurphy.com/products/genset_controls/asm150.htm

Regards,
Martin

22
Everything else / Re: Computerized engine controller
« on: June 26, 2007, 05:50:38 PM »
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.

23
Everything else / Re: Computerized engine controller
« on: June 26, 2007, 05:08:48 PM »
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.



24
Everything else / Re: Computerized engine controller
« on: June 26, 2007, 06:04:05 AM »
Quote
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.
Quote
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.

Quote
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.

Quote
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.

Quote
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.




25
Everything else / Re: Computerized engine controller
« on: June 25, 2007, 11:26:29 PM »
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.

26
Everything else / Re: Computerized engine controller
« on: June 25, 2007, 09:49:35 PM »
Quote from: max.network23 on June 25, 2007, 08:35:40 PM
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

27
Everything else / Computerized engine controller
« on: June 25, 2007, 08:17:42 PM »
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



28
Listeroid Engines / Re: Temps & Break-In
« on: June 20, 2007, 05:32:49 PM »
Quote from: phaedrus on June 20, 2007, 04:31:05 PM
About that freeware program Ron uses "convert", Ron, where? I'll give up. I gave up the slide-rule and went to calculators, so I guess and can give up that (now) old fashioned way and go native by putting the number-cruncher in the 'puter.

I use google to do conversions.  If I enter 4400 watt in horsepower google responds with:
   
4400 watts = 5.90049719 horsepower


If I run the engine for an hour, how many btu's are created,  I enter 4400 watt hour in btu.  Google gives the answer:
4400 watts hour = 15013.4232 btu


Or if my old buggy has a speedometer calibrated in furlongs/fortnight, I can use google to convert the units to something more reasonalbe (like angstroms/microsecond)  http://www.google.com/search?q=10000+furlongs%2Ffortnight+in+angstroms%2Fmicrosecond


Here is a handy-dandy link which gives you the speed of light in furlongs/fortnight
http://www.google.com/search?q=speed+of+light+in+furlongs+per+fortnight

(Very useful for trying to communicate with people not familiar with current units of measure)

29
Other Slow Speed Diesels / Re: Chinese horizontal singles
« on: June 18, 2007, 04:46:26 PM »
Bob you could be perfectly right about the "Self Lubricating Governor Spring (tm) patent pending".

However,  the breather valve has an altogether too convenient 8 mm opening.  A piece of 5/16 tubing slips in as though it was designed for that purpose.  I suspect that some accountant told the Chinese factory that they could save .001 Yuan by leaving off the breather tube.

I don't get a lot of smoke or oil, but it is enough that I wanted to do something about it.

30
Other Slow Speed Diesels / Re: Chinese horizontal singles
« on: June 17, 2007, 06:38:56 AM »
My Changfa 195 has a breather valve in the area under the fuel tank.  it just vents into the air.  At full power, a haze of smoke/oil comes out.  I used a piece of vinyl tubing to route the vapors back to the intake.  This helps eliminate the film of oil that collects on the speed control lever and spring.

Pages: 1 [2] 3 4 ... 8