dimented24x7

iTrader: (2)

I was thinking about the origional topic of WB O2 closed loop control. Taking a brief look at the current PID loop, most of that code could probably be reused. My thoughts would be to use a linear voltage vs afr output to the ecm and have the mean O2 volts ride along the curve as the AFRs change and set the thresholds for the adjustments about that. The loop would essentially work the same way as it does with the NB, but would have the same actions throughout a range of desired AFRs (Id probably only select one at any one time to minimize complications). I dont think this would work well for PE or high load, though. The computer is too slow to support a fast PID loop and the corrections may be too sloppy when your in PE. Not only that but I wouldnt like the idea of having the AFRs constantly swinging around when the engine is under high load. Obviously how the O2 volts are handled as well as the gains and such would need SERIOUS reworking. Im thinking of looking deeper into it.

It has really good appeal to me as the 8 bit A/D converter can resolve things as well as a blind nursing home patient with cataracts. I have a good deal of error in my MAF readings at low airflows so my AFRs come in descrete values, and not across a smooth range. This means that most of the time I cant run at an actual AFR, so to run at stoich, Im entirely dependant on the PID loop. It would also mean that one could run leaner then stoich with correction from the ecm. Would come in handy for saving fuel when your cruising. Im thinking of seriously looking into it now that I have my WB. I dont think Id use it all the time, but it I was going on a trip with the car, id probably use it to do the corrections. The wear and tear on the WB could easily be offset by the fuel savings in that situation.

gta324

What are theese changes?
Adress my.bin new WB bin
$758 C8 88
$770 C0 80
$772 C0 80

/N.

Z69

My downloaded 58_WB bin has:
$758 88 1C
$770 80 00
$772 80 01

BBZB
$758 C8 1C
$770 C0 00
$772 C0 01

From AYBN_hac.src
When he made the bin 32k, things got moved around.
The prom id was at C000 with the 16k bin due to the $4000 offset when loaded on the prom.
In a 32k bin it is offset on load to $8000. So the prom id is now at $8000. Hope I did that right. I haven't messed with any 16k bins.

gta324

I copied all the values between 0x0000 to 0x076F from my current $58bin and then did a diffrence check in tunerpro and found those as undefined and I cant se why they have been changed in the WB code......

I want to understand everychange before I test it in my car.......

Z69

You got in before I finished my edits.....

Looking at it again, the copy address might need to be changed.
Someone more familiar with $58 than I am.

edit: I'll try

Try to copy through 74F instead.

gta324

Ok, so now its seems ok, but what do the changes do?

58_WB bin has:
$758 88 1C
$770 80 00
$772 80 01

BBZB
$758 C8 1C
$770 C0 00
$772 C0 01

Should "we" name this code to something else then $58 or $AA to make it easier.....??? (have its own TDF/xdf files and so on)

/N.

Z69

LC770 FCB $C000 ; 1, EPROM ID WD, MSB
LC772 FCB $C001 ; 2, EPROM ID WD, LSB

These are the addresses the aldl subroutine uses to go get the data from. The data that is transmitted out the dianostic port.
It's simple list of go here, here, here for this data.
So the ALDL list needs to be updated to look at the correct location to get the actual prom ID and not some garbage data.
Since the bin was expanded. The physical location(address) of this data was changed to $8000 & $8001. This particular data is on the prom. A lot of the aldl data is in ram so it was not moved by this patch.

A different xdf/ecu isn't really needed. F95 is almost the bottom of the cal area. The xdf uses the bin address to locate data. Which for the cal data, was not moved. 1981TTA only moved the code portion of the bin. Most people don't have the aldl list in their ecu file. Only data referenced by the code as stored on the chip needs changed. Which is a code problem and 1981TTA had to take care of that prior to publish. The xdf still looks at the same "line" in the bin regardless since he did not actually move the tables around. Your about at my limits for explanation.
Rbob or someone else will need to step in if I'm not getting this across adaquately.

gta324

Nothing to worry about then

only the $0758 adress left to be expalined.....

/N.

Z69

$758 is still aldl stuff and was changed for the same reason.
Don't know what that location is for though.
No comment in either of my hacs for it.


edit:
Not for aldl. But the numerical change suggests it was changed for the same as the other two.

RBob

iTrader: (1)

The data at address $758 points to the ALDL chatter packet.

RBob.

dimented24x7

iTrader: (2)

1981TTA, have you gotten anywhere with the closed loop wideband idea? If nothing else, maybe all of us could collectivly kick that side of it off with some of the theory needed to get it to work.

1981TTA

Sorry I've been away for the last couple of days. Things at work kicked up a notch or two....

gta324, I answered your PM before reading this. You'll notice Z69 and I are in complete agreement on the reasons for the changes. RBob is correct about the second part. You guys must have been looking over my shoulder when I moved things around. Very impressive! You guys are good! When doing a compare, just about any change of $Cx or $Cxxx to $8x or $8xxx was due to the expansion of the code space. By all means keep asking questions. I can completely understand wanting to understand all this before turning it loose in the car!!

I would agree a different "name" isn't needed (yet) for XDF purposes. But, for clarity when talking about specific masks and functions, we have $58 and $60. It might be a good idea to come up with a way to separate this latest mask from the rest. Although I don't know if it's used otherwise, $59 would have a neat meaning. A little better than $58 but "lesser" than $60! I do look forward to the day the WB changes can be merged into $60. But, until things are stable enough to do that, we're left with the middle ground. Until the day of the big merge and assuming there are enough people willing to test, I'm more than happy to continue to make changes.

1981TTA

Got a few things going and a few offers of help on $8D that might get things moving quicker. I'll keep everyone posted. I'm very certain we'll need people to test the results. I'll definitely take you up on that offer!

1981TTA

Thanks for the kind words. And, thanks for the references. I'll take a look at this over the weekend to see what I can find. I'd expect the Base Pulse Multiplier table range would be treated like any other MAP-based table expansion..??? I'll probably have a better idea after some research.

1981TTA

Dimented, I very much agree with your ideas about the existing closed loop logic. In my first attempt at this, I could get reasonable behavior with a simple PI algorithm and the Zeitronix sensor. Much of the "transport delay" type of modifications would seem to remain as applicable for WB as NB. Potentially, the use of different gains for EGR vs. non-EGR operation, too. I know we could remove the NB voltage-based gains since the WB is naturally taking care of that. I haven't really taken the time to work on this further since late last year. It's getting about time to start again.

I very much welcome any ideas on what and how to do the algorithm. I've received some good ideas from others that state as you do that we probably won't want to remove fuel during PE. But, the ability to add it in the proper amount, if needed, could be a very beneficial thing. Your idea of a "controlled" lean cruise is another cool thing to try. My original intent of this thread was to use it as a sounding board for ideas. Definitely keep them coming!

Z69

What really got me motivated on this was a post on one of the Buick boards. It was a CL WB setup.
Used it during PE WOT etc, bit selectable to turn off....
Found it...
WB control
No info on how he did it of course.
Just that he has it.

JP86SS

iTrader: (1)

Excellent concept he implemented!
I think it would be better using a table for the AFR rather than sticking it to one value.
Sounded like it worked well too.

1981TTA

I noticed an error in the original *.bin file that I've just fixed. (New file on Moates site called $59_05222005.zip.) In addition to the WB sensor changes, I also have pieces of logic laying around that I was using to do closed loop control. Before releasing the first version of software, I *thought* I'd disabled everything via the use of calibrations, commenting, deletion and jump/branch statements. Unfortunately, I missed one.

In the original version of the software, I "jump" over the cold AFR routines when a WBO2 isn't selected. In that version, regardless of temperature, the stoichiometric AFR is the only one that will be used. The updated .bin file has re-enabled this logic regardless of O2 sensor.

In addition to this fix, I've also implemented a "Raw Output" option to the code. A second option word has been implemented to cover this functionality. On a better note, that leaves us with 7 more sensors we can configure!!

One final thing I'd like to wrap up before digging into the closed loop logic. Based on some feedback above, the Desired AFR field isn't the best output for the WB AFR. This will become even more apparent as the ability to choose different AFRs for different engine operating conditions are implemented. So, what should we discard from the existing ALDL list in favor of the WB reading....??

ty1295

I see we have a ALDL count. Never used that option.

Another depending on how you plan to do it, is the BLM.

If you going WB closed loop, is BLM somewhat changed or being removed? just be INT's?

I know when I tune, being the 749 BLM's are worthless with only 2 storages (closed and open throttle) I general block them off, let INT handle it.

Couple others could be spark count (most just look at degrees)

O2 cross counts (may or maynot be useful with wb o2)

I am still excited to see this project move forward.

JP86SS

iTrader: (1)

seems like FP volts would be another possible candidate.
You already have battery volts there.
the run time is another good one providing the datalogging is not using the time as a reference value. That give you two spots.

dimented24x7

iTrader: (2)

While the INT and other things are used to produce the short term fueling changes that makes the O2 cross count around the desired AFR, the BLM is what ultimatly allows the ecm to do fueling corrections. It would stay, at least on my ecm. The loop only runs 40 times a second in the C3 so the matrix of BLMs is really needed to alow a reasonable ammount of correction and give the loop somewhere to start off at.

1981TTA

I was playing around tonight and found another good candidate (I think). There are two AFR values on the ALDL. One is located at word #41 (Cranking AFR?). The other is the more familiar AFR at #55 which I'm currently using. This is listed in TunerPro. But, I don't see it in Datamaster. If it is available there, this would seem to be the best of both worlds!

Regarding the functional questions, here's how I think the first iteration is going to go...... To help everyone work their way into this with the least amount of relearning, we'll use the vast majority of the existing INT/BLM logic....

* The WB sensor's AFR value will be compared to the desired AFR value to determine whether the engine is "rich" or "lean". (Very similar to NB except the WB would comprehend values other than 14.7.)
* The existing O2 transport delay logic portion of the INT will remain intact. The INT update rate can be changed via the existing MAP and RPM-based calibration tables.
* The portion of the NB CL logic that can "bump" the INT based on O2 voltages will be bypassed (for now).
* The existing proportional steps (with EGR dependencies) will be left as-is.
* The BLMs will function pretty much as-is except it will be allowed to learn when not at "stoich".
* O2 MALF codes will be disabled.
* Current fueling modifiers while in PE (i.e. use INT as-is if > 128 else reset to 128) will continue to apply.
* Leave the NBO2 stuff there and calibration selectable so we can switch back-and-forth as needed.

You might wonder why I've gone into this much detail. Well, because that's the functionality that worked on the bench after working on this today!! WooHoo!! Next step will be working in the vehicle tomorrow to do some further testing........

After this level of functionality checks out for stoich operation, we'll implement a desired AFR table and the potential to "learn" during PE. (Probably only enrichen...?) Further changes would include implementing a "real" integrator algorithm with the potential for modifying the current BLM operation.

dimented24x7

iTrader: (2)

I think there needs to be at least some form of error handling. Like maybe something to set a code if the volts from the WB are zero or the O2 fails to cross-count after a certain time interval. In my stock code, at least, they also clear out the prop. gains and skip the int adjustment if the O2 volts get stuck around .450 from an open circuit or something.

1981TTA

I agree! In concert with "errors", we also need to determine when the WB is "ready". Since I don't have details for all sensors, I've started by implementing an engine run time check along with upper/lower AFR bounds to determine readiness. These AFR bounds are also constantly monitored so the CL algorithm will default INT to 128 if the sensor goes crazy.

Implementation of a smarter algorithm to insure there's a change in AFR when fuel is added or subtracted is a good idea. For now, the existing INT/BLM clamps are in place to insure any erroneous WB reading doesn't have any more authority to change fueling than a false NB reading.

ty1295

Is this still true?

I have a $60 code already on my buick thanks to Grumpy. Wouldn't mind trying your code, but obviously I have a lot of tables that have been changed.

This will overide the cylinder select as an example right? Do I just go back and fix that?

vernw

iTrader: (2)

I sure hope you do! I'd like to at least be somewhat of a help on this....

Z69

The cal area has a lot of changes to it in the $60.
You could do a cut and paste to the individual tables to swap your tune. Tedious......
I'm not sure if 1981TTA is doing this concurrently on the $60.
But it would be a lot easier to simply put some wb code into the $60.

1981TTA

Z69 is absolutely correct. The $60 cal area is a LOT different than the "stock" $58. A direct copy isn't possible between the two..... However, if you had a set of calibrations in $58, you could get away with copying the cal area directly. (Well, with the exception of location 0xX758 as mentioned earlier in this post.....)

I'm planning on implementing the WB logic in $60 some time in the future. For now, "new" changes to the $60 source code are on hold while testing/verification is underway. As anyone who's seen or used this code knows, there is quite a bit of functionality in there that wasn't present in $58. Piling on more changes before what's there has been verified would likely be counterproductive...... I can speak personally of my ability to trip over my own changes in the code.

1981TTA

Z69 has generously volunteered to implement the WB sensor support in $8D :
https://www.thirdgen.org/techbb2/sho...hreadid=298357

dimented24x7

iTrader: (2)

Another thing I was thinking is if we could get a derivative term in the current PI(but not the D) loop. The current setup with the crossing NB O2 volts will make a derivative term sort of pointless as teh system is designed to overshoot, anyway, to make the O2 cross-count. But, with damping to prevent the overshoot we could instead have the ecm seek a steady AFR via the WB rather then have the swinging O2 with the integral/BLM centering the AFR around a certain value.

Of course, the flip side is that the loop is so sluggish in comparison with the engine that a derivative term may not be needed.

dimented24x7

iTrader: (2)

Heres what appears to be a good theoretical discussion of PID control: http://www.expertune.com/tutor.html

dimented24x7

iTrader: (2)

I started working on roughing in a routine.

I decided to use the following equations as teh core for my routine:

error = (O2 setpoint - filtered O2)
Prop gain = K(error)
INT = K*(1/Int. time)*integral(error(t) dt))=(1/int time)*integral( prop gain)

Obviously the actual form in the code differs quite a bit. The gain terms, int time, etc are all in tables based off of airflow.

No derivative term, though, nowhere near enough room timewise for that in my code. I added deadband around the setpoint instead to try and break the corrections to prevent overshoot. Basically it scales the O2 error down to zero when the AFRs reach teh dead band. I hope itll at least kinda work.

1981TTA

I would agree the "D" term really shouldn't be needed. My assumption (well, one of many...) during development is that the VE tables are reasonably close or are getting there. Therefore, the feedforward portion of the fueling algorithm should handle the vast majority of driving conditions that would cause a sudden deviation from setpoint.

I was able to get some time over the weekend to try out my first WBCL algorithm in-vehicle. This is the version that simply uses the existing INT/BLM logic with the WBO2 indicating "rich" or "lean" of the desired AFR as described above. I think I remember a post by RBob that described the resolution of the INT term a while back. I'm going to have to go through the math myself to see how big of a "step" in fueling is achieved with a "step" in INT. As the algorithm stands now, the INT would move +/-1 while the WBO2 AFR moved +/- 0.1 AFR. Since this represents the lowest resolution of each variable, things would appear pretty stable. Although I can only test at idle, the algorithm appeared to behave very well.

I did run into some issues with my WBO2 sensor connection. It appears to "cut-out" at times such that it indicates a lean mixture for a few seconds before moving back to what it was reading previously. I think this is due to a poor connection in the rats nest of wires I have floating around the ECM. This problem did make me consider some additional constraints to put on the algorithm. Currently, I only have upper and lower absolute AFR limits to determine whether the algortihm should operate. Now, I'm leaning toward an AFR "band" around the current desired AFR value. Also, I currently don't filter the WBO2 signal/AFR into the ECM. This was originally left out so I could datalog transient behavior. A calibratable filter on the value going into the CL algorithm may be helpful....? Given my sensor reading problems, this may turn out to be unneeded. Maybe a setpoint deadband like you implemented would be better....

The testing continues......

BoostKillsStres

Very nice work. In my GN ecm code for the wideband I adjust the BLM address in a similar single point fashion since the 148 code locks the BLM to BLM cell 15(0-15) value once you reach any decent level of PE. The fun part then is determining the correct frequency for making these adustments and if you want to be able to make faster adjustments if the reported WB A/F ratio is really out of whack to what you've programmed PE to run at. My code is only active in PE w/ a MAF greater than 180 because below 180 its just too easy to let the ecm and stock switching o2 control C/L fueling. I worked on and ran some rull time C/L WB code but the frequency again changes since the airflow thru the system is so small it takes a certain amount of time for the WB so see throttle movement and such. Non PE O/L is also an option by getting all the non PE MAF/VE tables in adjustment since you have the WB to work with to get them in line BTDT too and still like the factory C/L non PE for simplicity. If you can figure out how to adjust the o2 switching values in your code then you can adjust the A/F ratio for all non PE to run a little richer or leaner whatever your car likes and certainly helps for emissions
Anyway, I've rambled too long,
Keep up the good work...

dimented24x7

iTrader: (2)

Now that I think of it Im not as happy with what i have at the moment as I could be. i tried to re-use some of the stock algorithms and I dont think itll work too well. I freed up some space elsewhere so I can now have a little more time in the loop where the PID code resides. Im thinking of adding a derivative term and just using the fast filtered O2 for all the calculations rather then the slow filtered O2 thats based off of airflow. I think it could make for a much better control routine.


The next step is to try and model the engine as a simple airpump with air entering and heated gasses leaving and factor in the transport delays from the tbi to the end of the header. Itll be super-idealized, but at least Ill be able to see the PID algorithm running in MATLAB or something so Ill be able to make a good guess at setting it up. Also helps to see what Im actually trying to accomplish.

RBob

iTrader: (1)

I don't know if this will help, just some ramblings on the stock PID control. The proportional gains are setup in such as way to force the fueling to crosscount (O2 switch rich-lean, or lean-rich). As such the PID loop is forced to oscillate. Reducing the proportional gains will then cause the INTegrator to oscillate. The stock code needs to see crosscounts, it is designed to oscillate.

There are several items that I consider derivative terms. Basically they are resets of certain values. On a crosscount the proportional gain is reset along with some timers (INT delay, prop delay?). Optionally the INT can be reset on AE active or a BLM cell to use change.

For WB control would we/you want a more traditional PID loop, or one that has BLM cells? Stock, the BLM follows the INT. Traditional, the INT is only used to remove that last bit of error that the proportional gain can't eliminate. My thought is that a more traditional PID loop would be better for WB control.

Use a separate section of code that is called when WB fuel control is required. Use proportional gains to get the fueling close, then clean it up with some INTegrator gain. During transient conditions the WB controller would be put in a hold state. This is to prevent wide PID swings from AE or DE.

A reset of the WB fuel control PID parameters may be required under certain conditions. Integrator windup is another issue that may need to be addressed.

Once all this is in place it is an easy matter to implement WB O2 sensor testing. Create a rich or lean slug and check the WB input for a reasonable value and response time.

For in-vehicle code testing have the code monitor a digital input. If the input is active use the WB code, inactive, use stock fuel code. Put a switch on that input so that the fueling mode can be chosen. This way the vehicle can be driven w/o issue, and once that deserted industrial park is reached flip the switch and try out the closed loop WB control. If it gets out of hand, flip the switch back.

BobR.

dimented24x7

iTrader: (2)

My thoughts on the BLMs is taht they can be a good fail-safe in the event of some sort of serious fueling snafu. like a failing pump or a maf that goes **** up. My idea was to have the PG/INT handle all the fueling corrections and only have the BLMs step in when there is an error on the fueling side. they could then do a bit of smoothing so the car is more drivable.

Although, it sure is tempting to dump the BLM routine. I may very well ditch them altogether. With the extra time, I could consolidate the two fuel loops and run the PID routine 80 times a second.

dimented24x7

iTrader: (2)

As far as windup goes, are there any conditions during P/T where windup would ocur? Obviously if it was used during PE the INT could easily windup if the injectors went static.

dimented24x7

iTrader: (2)

Does anyone think that a model would be of any use for simulations?

my entire fueling world revolves around airflow and dutycycle so in that respect the engine is just a large pump that Im dumping fuel into to match the air thats going in. On the buisness end I have hot gasses rushing out through the headers and past my O2 sensor. it would seem that I could at least get some crude information on how the PID loop will react by simulating the change in AFR input for a given correction and the transient times at each given airflow.

1981TTA

I'm not at all familiar with the 148 code. So, I don't know what, if any, methods might be present to help with this condition. In the $58 SW, there are two "transport delay" tables based on MAP and RPM that attempt to comprehend the time it takes for a fueling change to reach the O2 sensor. If it wasn't present already, I'd imagine a similar table based on MAF would be helpful to the 148 code....?

After getting some sort of WBCL algorithm worked out, I want to implement a desired AFR table vs. MAP and RPM. Ideally, after getting VE's dialed in, all you'd have to change to run richer or leaner would be this desired AFR table. No more tweaking VE tables to get things to run at the AFR you desire. And, in the event of any unforeseen operating circumstances, make the proper fueling adjustments. Part of the motivation for this effort was the number of people needing to run "open loop" at idle with healthy cams and other engine mods. The other part was to enable people with only one hole in their exhaust to install a wideband without an NB and be able to keep the CL algorithms happy. With the number of sensors including NB simulators, the importance of part 2 is quickly fading...

As I start to work with the first versions of the algorithm, I can see some strong advantages to keeping an INT/BLM-type of CL system. The biggest is the fact any existing automated VE table modification programs should work with the WB just like the NB. The only difference would be that you might have been running a non-14.7 AFR while generating the data. The close second is the experience/intuition people have with the existing algorithm. Saying "my INT/BLM = 128" speaks volumes to many people. If a similar correction scaling can be maintained, there would be less learning that would need to be done (I think...)

Nonsense! Hearing various ideas (especially from someone who's done something very similar) is extremely helpful! Feel free to ramble further at your leisure!

1981TTA

I would imagine as long as the VEs are reasonable, windup wouldn't be too much of an issue. Any time a "maximum" command to the output won't reduce the error, windup will occur. Whether or not you'd lump transport delays into "windup" (I wouldn't) would just be a matter of definition.....

This would be really cool! But, it's also a LOT of work. By the time you managed to get anything close enough to properly simulate what the engine is doing, you probably could have implemented your designs in the ECM and seen how they *really* worked... This is a situation where an ECM bench would probably be one of the better choices to use. That being said, if you're interested in working on some simulations, I'd be interested in helping out.

If the new PID algorithm responded quickly enough, I would imagine the original intent of the BLM (i.e. ECM "remembering" large corrections to the VE tables) wouldn't be as applicable. Whenever you transitioned to a different part of the table that would induce an AFR deviation due to error, the PID would quickly respond rather than waiting for INT to increment/decrement one-by-one. Definitely a strong case for a more traditional PI loop as compared to what's there. Hmmm.... Maybe a combination of both worlds would be in order.....? Rather than incrementing/decrementing INT one-by-one, it (the traditional PI) would be calculated and applied all at once (with the appropriate transport delay times to insure the engine has responded). Under steady state conditions (AFR error ~ 0), the "I" could be copied to the appropriate "BLM" so the PI wouldn't have to work as hard the next time it was in that cell. Granted, the $58 code only has two BLMs. But, for other masks with multiple BLM cells available, this could be a lot more beneficial..

dimented24x7

iTrader: (2)

I did a simple simulation with the engine basically being a pump and there being a delay from the time it takes the cylinders to go through a work cycle and also from the travel time of the exhaust.

Basically I learned:

1). There can be NO derivative term!!! Theres something called the Nyquist frequency. This is where the frequency of the signal approaches 1/2 the sampling rate. Above this the signal begins to lead the readings and signal appears as noise to the derivative term. It becomes ever more sensitive and basically flies off the handle. This showed up as a bouncing in the simulated AFRs whenever any derivative was present. With our PID loop, the sampling rate is very close to the rate that the cylinders fire. So... put a big thick dash through the derivative.

2). The integral does indeed 'windup' if the gain or the integral time arnt correct and it has much more gain then it should. Basically itll respond much faster then the engine does so itll keep dumping or removing fuel well before it gets any true feedback.

3). The end result of any corrections must be in terms of fueling (PW, DC, etc.), not AFR or raw O2 output. Basically the fuel is the input into the motor and your basically correcting to get the actual fueling to equal the desired fueling at the setpoint AFR. The stock code does this by basically having the integral be very small. Each integral/Prop gain term step in my stock code is 15.26 usecs of fuel IIRC.

dimented24x7

iTrader: (2)

Another problem that I thought of is that the Proportioning term only seeks stability, so itll tend to settle out wherever the hell it feels like it and leave the INT to do the rest of the work involved in bringing the AFRs in line. All fine and good but its sluggish with the int handing it alone. We could use the prop term to help out more but without the derivative, the prop. term will swing around like its on a spring and take some time to settle out, wich will cause overshoot. Teh factory basically just uses the swing in its favor to allow the PID to come to the mean desired AFR more quickly.

dimented24x7

iTrader: (2)

Based on this, I may just keep the narrow band. I could use a traditional PI loop, but it would be relatively slow to finally reach the targeted AFR when small errors are present. With large errors, the prop. gain handles it but once the error gets below a certain level, the PG goes off to the land of truncated bits and rounding errors and no longer helps. Even better is if the gain was too high. It would wink in and out from some extra dimension and cause the fueling to get all screwy.

Just some random thoughts, but during PE, though, the WB could be of use. it wouldnt be able to make the AFRs dead on, but if there is large errors present, the PG would quickly correct for them. You probably could just use a P control algorithm as the INT wont be of much use during the furies of WOT. This would be quite simple to implement and would allow for corrections if the fueling where to stray way off from the desired AFR.

1981TTA

The PI loop can be gained to achieve a wide range of responses. We're just moving the poles of the system around to suit our desires. It's all a balance of response time, overshoot and settling time. A super-fast response time will have overshoot (i.e. underdamped). A super-low overshoot will have a slower response time (i.e. overdamped). In steady state, the P term will go to zero while the I term contains all the correction. Calibrating the gains is all about the compromises/goals a person desires. One of the best defenses is a good offense in that a good feedforward estimate will reduce the work the PI loop has to do. So, the error will stay around zero without moving around too much. In this situation, the gains can be lowered which will give a more stable (i.e. less oscillation) behavior. As you mention, the downside is that if there were a big error, it would take forever for the system to compensate.

1981TTA

The nature of the PI loop is to move "slowly" when error is low and "quickly" when error is high. I do agree some rescaling of variables would be in order. Given a WB AFR reading with a resolution of 0.1, there has to be quite a bit of error before we escape the land of truncation! The stock $58 code contains a separate "P" calibration for O2 voltages outside of a given range. While I don't relish the idea of creating a nonlinear control system and the headaches that can follow, doing something along these lines might be helpful.

Actually, there's no reason PE operation would be any different from "stoich" operation from a controls standpoint. And, you'll need an I term in the event the P correction isn't enough. The practical issues that have been raised regarding the avoidance of removing fuel during PE still apply. A number of people have indicated they'd prefer the algorithm add fuel if needed. But, leave things alone if it's already too rich just to be safe.

1981TTA

I think a traditional PI loop with the "I" being saved to a BLM cell in steady state would be the best. One thing to consider is why we're using a WBCL algorithm. If the goal is to avoid chip buring and leave some stock "kinda close" VE cals in the table while the WB runs around making fueling corrections, we'd certainly want to save the I's at various places due to their likely tendency to change from operating condition to operating condition. For those that are tuning and updating VE tables, the need for a BLM really isn't very big.

As per above, if the VEs are close and a "transport delay" is present, changing from 14.7->12.0->16.0 (highway mode, anyone...) wouldn't be a big deal. The desired AFR would have been used to determine the open loop fueling via VE tables. If the VE table was good for 14.7, it will be good for 12, 16 or whatever. As mentioned above, if the VEs are out in the weeds, a hold state would be required.

For now this is done via calibration and some sort of emulation hardware. During development, I would expect either emulation equipement would be used, a big chip with a bin switcher or an "extra" chip with the new algorithms enabled. Once developed, I would imagine a person would stay with the chosen configuration (NBCL or WBCL) for the life of the vehicle.

dimented24x7

iTrader: (2)

Personally I would think the resolution of the WB input would probably have to be quite fine in order to avoid a stepwise action of the PID loop.

Oh, what the hell, Ill try the WB closed loop at p/t to see how it works. One question though is how to tie the O2 in with the fuel calibration. Ideally the errors should be in terms of fueling and not O2. I would assume, though, that one way to make the WB error tie into the fueling is to fudge it and just make the minumum stepsize of the correction term from the PI loop sufficiently small and set the gains to get the desired output. The other way would be to calculate the error in terms of PW or DC using the MAF airflow. But, the MAF is one of my sources of error so that might not be the best idea. Hmmm...

Z69

As long as the ve table is pretty close, I'd think a PI could made to control well. But people will use it w/o a good table.
A small 2d table with PG or multipliers vs error would minimize the slow vs fast response time issue .
Could also use a multiplier for PE vs non PE to alter the response time some more. Things can always be set to 1 or zereo as needed to prevent them from having an effect.
Non linear can be tuned pretty easy as long as it's not too non linear. You just have to graph the actual response and the curve built into the code. A dip in the afr at x needs a change in the table value for that range. I'm too tired to get it across better. But I had to redo a non linear tune once.
Just had to graph everything out. Then it was clear which values needed changed for the desired effect. Note: this was pre excel so it was graph paper and a calculator.

dimented24x7

iTrader: (2)

Heres anothere brain tickler... What to base the error term on?

AFR itself probably wont work as the AFR is non linear from the standpoint of fueling. I was thinking inverse AFR with the gain + constant based on airflow to estimate the error in injector duty cycle all rolled into one table.