Actions
Forum Thread Details
  • Replies 6 replies
  • Subscribers 39 subscribers
  • Views 865 views
  • Users 0 members are here
Related

More Engine Management

jack.chaney56

In the previous discussion, I presented a base system for engine management. The problem with what was created is, it only runs in steady state. Steady state for an engine is constant rpm and load, no acceleration, and no change to demand. The software components of the system have been intentionally designed to be independent of hardware processor. The specific platform is the Arduino Nano and the 328p processor. The choice was as an exercise to see if it could be done, and to force a level of discipline for the programming model. The other item of note from the previous discussion is, I am a software person primarily, with a working knowledge of electronic hardware. I am happy to admit to shortcomings in any circuits that I present, and encourage correction.

 

This second section will deal with making improvements to the basic software to manage the asynchronous events. Some items will make reference to the previous discussion, so please review for a full description. If something was left out, I am happy to fill in the detail. Jumping in to the first item which is a one time event. The engine start. When the engine is cranking, before ignition timing is captured, fuel is being input, and not burned. To correct the state, once the engine starts, the acceleration is raised temporarily to "burn off" the excess fuel. This is done by adjusting the advance, first increasing, then reducing back to steady state.  Also, during crank (before ignition capture), the advance is reduced to almost zero. Because the advance goes from near zero to a large angle, a measured transition is needed. This is called the ramp in rate. Also, the recovery from the large angle to the steady state angle, is again a measured value. This is called the decay. The startup sequence then becomes a small state operation. Crank > Ramp to max > Decay to steady > Steady State. In each of the states a value is combined as part of the total advance.

 

The ramp in and decay are governed by the RPM of the motor, so a counter tied to the cam signal is implemented. The four states are monitored with a simple switch operation. The values for ramp in and decay are defined in calibration, as well as the values for max and minimum advance. The other part is to implement a counter of some sort that is updated during the cam signal detect (same place as setting cam detected flag). The sequence works sort of like this:

  • Engine off - Retrieve from calibration values for min, max, ramp, and decay.
  • Crank to start - Set advance to minimum until ignition is detected, also set counter to ramp in value when ignition is detected change state.
  • Ramp in - Adjust advance from minimum to maximum with a slope = counter / ramp until max is reached then set counter to decay and change state
  • Decay out - Adjust advance from max to steady state with a slope = counter / decay until steady state is reached then change state
  • Steady State - watch for engine stop

 

SWord updateStartupTrim(SWord t) {
 static SWord ramp;
 static SWord min = 0;
 static SWord max = 0;
 static UByte stState = 0;
 switch(stState) {
 case 0:  // engine off, crank to start
  min = getIgnStartupAdjustment() - t; ramp = getIgnStartupRampIn(); if (ramp == 0) { ramp = 1; }
  ignStTrim = getRpm() > 0 ? min : 0;
  if (getRpm() > getIgnRpmMinRun()) { camTrimCt = ramp; stState = 1; }
  break;
 case 1:  // ramp in
  max = getIgnStartupTrim();
  if (camTrimCt > 0) { ignStTrim = max - (SWord)((SLong)camTrimCt * (SLong)(max - min) / (SLong)ramp); }
  else { ignStTrim = max; ramp = getIgnStartupDecay(); if (ramp == 0) { ramp = 1; } camTrimCt = ramp; stState = 2; }
  break;
 case 2:  // decay
  if (camTrimCt > 0) { ignStTrim = (SWord)((SLong)max * (SLong)camTrimCt / (SLong)ramp); }
  else { ignStTrim = 0; stState = 3; }
  break;
 default: // running
  ignStTrim = 0;
  if (isEngStopped()) { stState = 0; }
  break;
 }
 return ignStTrim;
}

 

The variable camTrimCt is the counter which gets decremented on each cam.

 

Good news is, there are lots of exception and asynchronous activities to manage, so there will be lots offered here

 

Jack

Parents

  • Keep getting interrupted... The piece of information that I wanted to give is about event timing. Several events in an engine system are asynchronous, which means they can happen pretty much any time. The second type of event is the dynamic events that are based on engine speed. These events need to be synchronized to the rotation of the motor. The last type of event are real time, these are tied to timer events providing real time reference. The system here has a 1mS real time operator, and cam and crank signals to provide engine synchronization. Some items need to be calculated during the engine event, but the great majority do not. The engine control operation is actually performed almost entirely via interrupt events.

     

    The first layer is the 1mS event. It performs some simple operations. It keeps a countdown timer to determine if the engine is still running. If the countdown is zero the motor is off, and one group of operations can be performed. If the motor is running, updates to values can be determined that do not change significantly but vary during run time. The 1mS event also provides a command to refresh the A/D values.  The A/Ds also operate in an interrupt process. When a conversion is complete, it generates an interrupt. In the interrupt it reads the value from the register, increments the A/D matrix pointer, then starts the next conversion. The value of the A/D read is added to the record for the individual A/D. The third level is the crank and cam interrupt. Depending on the tooth count and the speed of revolution, these events can be long or short in frequency, so only necessary operations should be performed, and only those that are affected by engine speed. The last level is the mainline of the program that operates as a forever loop. This is reserved for operations that take a long time, or only change at a very slow rate. Most notable operation here is basic communications to the user.  Updates to calibration and reading monitor values are done here.

     

    Process breakdown

     

    1 mS event:

    Engine stopped - update tooth count,  update tach events, update operational constants

    Engine running - update rpm, update advance, update dwell angle, update spark events, update start of dwell events

     

    crank tooth event:

    record event time (high speed clock)

    update Diff (tics between teeth)

    update rotation angle

    calculate value of BASE

    compare angle to tach events (set timer if needed)

    compare angle to spark events (set timer if needed)

     

    timer compare events:

    turn on or off tach signal

    turn on or off coil signal

     

    The mechanics for the timers is; from outside set the timer compare register value, save the value for which coil, and enable the interrupt. Using one compare to activate coil, and another to shut off the coil, the operation becomes simply, for one interrupt, turn on the specified coil and disable the interrupt, for the other turn off the specified coil and disable the interrupt.

     

    For fueling a similar breakdown is performed. In the 1 mS operation; engine off, update operational constants, update injector capacities, set injection strategey. For 1 mS operation; engine running, perform fueling calculation, calculate pulse width for injectors total time converted to angle. For batch or TBI divide by 2 or 4.

     

    crank tooth event, compare angle to injector on or off events. Perform similar operation to coils with injectors. Based on strategy, one or several injectors will be acted upon.

     

    I think that gives everything. I am going to leave coding the details to the collective. If you are able to come up with a working implementation, send me a note. I look forward to hearing if anyone had success besides me. I am still working on my prototype hardware, but the signals from the scope look promising.

     

    Jack

Reply

  • Keep getting interrupted... The piece of information that I wanted to give is about event timing. Several events in an engine system are asynchronous, which means they can happen pretty much any time. The second type of event is the dynamic events that are based on engine speed. These events need to be synchronized to the rotation of the motor. The last type of event are real time, these are tied to timer events providing real time reference. The system here has a 1mS real time operator, and cam and crank signals to provide engine synchronization. Some items need to be calculated during the engine event, but the great majority do not. The engine control operation is actually performed almost entirely via interrupt events.

     

    The first layer is the 1mS event. It performs some simple operations. It keeps a countdown timer to determine if the engine is still running. If the countdown is zero the motor is off, and one group of operations can be performed. If the motor is running, updates to values can be determined that do not change significantly but vary during run time. The 1mS event also provides a command to refresh the A/D values.  The A/Ds also operate in an interrupt process. When a conversion is complete, it generates an interrupt. In the interrupt it reads the value from the register, increments the A/D matrix pointer, then starts the next conversion. The value of the A/D read is added to the record for the individual A/D. The third level is the crank and cam interrupt. Depending on the tooth count and the speed of revolution, these events can be long or short in frequency, so only necessary operations should be performed, and only those that are affected by engine speed. The last level is the mainline of the program that operates as a forever loop. This is reserved for operations that take a long time, or only change at a very slow rate. Most notable operation here is basic communications to the user.  Updates to calibration and reading monitor values are done here.

     

    Process breakdown

     

    1 mS event:

    Engine stopped - update tooth count,  update tach events, update operational constants

    Engine running - update rpm, update advance, update dwell angle, update spark events, update start of dwell events

     

    crank tooth event:

    record event time (high speed clock)

    update Diff (tics between teeth)

    update rotation angle

    calculate value of BASE

    compare angle to tach events (set timer if needed)

    compare angle to spark events (set timer if needed)

     

    timer compare events:

    turn on or off tach signal

    turn on or off coil signal

     

    The mechanics for the timers is; from outside set the timer compare register value, save the value for which coil, and enable the interrupt. Using one compare to activate coil, and another to shut off the coil, the operation becomes simply, for one interrupt, turn on the specified coil and disable the interrupt, for the other turn off the specified coil and disable the interrupt.

     

    For fueling a similar breakdown is performed. In the 1 mS operation; engine off, update operational constants, update injector capacities, set injection strategey. For 1 mS operation; engine running, perform fueling calculation, calculate pulse width for injectors total time converted to angle. For batch or TBI divide by 2 or 4.

     

    crank tooth event, compare angle to injector on or off events. Perform similar operation to coils with injectors. Based on strategy, one or several injectors will be acted upon.

     

    I think that gives everything. I am going to leave coding the details to the collective. If you are able to come up with a working implementation, send me a note. I look forward to hearing if anyone had success besides me. I am still working on my prototype hardware, but the signals from the scope look promising.

     

    Jack

Children
No Data