gemellocattivo.com

Which means "Evil Twin". Lets see your projects where you change boring into fun or create the fun from scratch.
It is currently Thu Mar 28, 2024 4:46 am

All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Load sense method(s)
PostPosted: Wed May 20, 2015 7:42 pm 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4250
Before I can really proceed on spark I need to do something for load sensing.

The simplest thing is call MAP the load and move on...but that really doesn't work very well because MAP changes with throttle position and barometer so the ECU can't tell if the MAP is low because the throttle is partially closed of you've driven up a mountain. It will still deliver the correct fuel/spark you asked for at say 70kpa but if it's 70kpa because the throttle is closed you generally want 1 mixture and if its 70 because your wide open throttle on pike's peak you want a different mixture.

Sooooooo.........

VE wants to come from MAP and maybe be a 3D lookup to correct for any changes in VE related to baro.....or maybe just a normal 2D but with a 1D baro % correction.

Target lambda probably wants to be either TPS or MAP/Baro. I'm thinking MAP/Baro is more straight forward.

Spark probably wants to be....hmmmm...MAP seems right for this one.


Top
 Profile Send private message  
 
 Post subject: Re: Load sense method(s)
PostPosted: Thu May 21, 2015 8:49 am 
Offline

Joined: Sat Jan 03, 2015 5:40 am
Posts: 208
Can we use a blended speed density (MAP) + Alpha-N (TPS) based table with a baro sensor?

My setup, like yours, is with ITB's and although they're not oversized I think our MAP signals will be nearly useless once the 12 butterflies open up a bit....

The blended table seems to be the workable setup for applications running ITB's.

Edit: Just to keep things interesting, I may also revert back to MAF if driveability and/or emissions suck. I'll try to keep the ITB's, but put intake air boxes on them with MAF's upstream of the boxes.

My goal is to be able to pass emissions testing, and a normal OBD2 scan.


Top
 Profile Send private message  
 
 Post subject: Re: Load sense method(s)
PostPosted: Thu May 21, 2015 11:12 am 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4250
Have you been reading the MS forum? :?:

its a cesspool of bad information :!:

ANY setup has very little (aka NONE) MAP signal at WOT so that is something everyone has to deal with. TPS does provide more resolution near WOT and is immune to big cam reversion confusion so its traditionally been the favorite with racers but it provides WAY less resolution then MAP at lower throttle positions so it's hard to get the driveability as good.

With TPS load sense it's not linear so you can't just interoplate and smooth stuff, every single cell in the table needs to be tuned...then then needs to be converted into better units to work properly with accel/decel stuff. Not a concern for racing, but a problem for the street.

Blending is certainly possible and a simple way I've done it is use TPS load sense but connect the baro line to MAP and you automatically get MAP dominating at low load and TPS at high and this is what I was originally planning on my setup but this is much more work to tune. I read on adaptronic site they like TPSxMAP which is basically exactly the same thing.

I'm thinking fire up with MAP based load and see what I have...its easiest and will probably be just fine. Once it's running mapping TPS position to MAP is easy so a conversion to a more complex load calculation is also pretty easy and builds on the tuning you've already done.

That's my thought anyway....sometimes more knobs to tune is better and somethings it just feels like you should turn knobs just because they're there.....stupid EL console! :)


Top
 Profile Send private message  
 
 Post subject: Re: Load sense method(s)
PostPosted: Thu May 21, 2015 8:51 pm 
Offline

Joined: Sat Jan 03, 2015 5:40 am
Posts: 208
Naaaa, that's the wrong side of town for me. Besides, if I had, I wouldn't admit it :)

You're going to be ready to run before me, so let's see how things work with your setup. My block is still at Steve Demirjian's shop waiting to go onto the CNC :(


Top
 Profile Send private message  
 
 Post subject: Re: Load sense method(s)
PostPosted: Thu May 21, 2015 9:21 pm 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4250
I can't imagine my car being done before anyone's.....now I have to change an engine for Lana.

The way I'm setting up the script, changing stuff will be pretty easy so no problem testing whatever you want to test.....thats what makes this setup cool.

I got the actual HW today and.....its glued shut and it looks like the connectors dropped through the case then soldered to the board :shock:

What I'm going to need to do is power it up, load a model and toggle a pins to be sure they are doing what I think they should be doing. Jim doesn't seem as confident about knowing what's in the hardware exactly as he was on our phone call so I'm unclear where spark 11&12 might be going if they are in fact going anywhere. I see a sticker on the case that says Mods making me thing they do customize units.....hopefully that's just the model they load and all boards are the same or I'm going to need to get fancy opening it up. first thing is a model that PWMs fuel and spark 11&12 and see what if anything is blinking.


Top
 Profile Send private message  
 
 Post subject: Re: Load sense method(s)
PostPosted: Sun Oct 11, 2015 3:56 pm 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
I found this forum from the old O5E forum. I'm a controls developer on a university SAE Collegiate Design Series program.

We use 'charge' as our primary engine load and 'pedal load' for driver load. They are treated differently in different parts of the software. We use electronic throttle control, so they are not directly tied together.

Charge (mg) is calculated using the ideal gas law (P*V = n*R*T). We convert n (mole) into m (mg) using the molar mass of dry air. Then we solve for m. The resulting equation is Mair (charge) = (Pcyl * Vcyl)/(Tcyl * Rair). Pcyl is measured MAP, Vcyl = (EngineDisplacement/NCyl)*VE, Tcyl is measured manifold air temp, and Rair is a constant. The result is charge. We have VE offsets for each cylinder, so VE is an array, making Charge an array also. It is also common to have VE per bank (left/right) and charge per bank.

Charge is used as the load everywhere in the engine management side of the controls. For Fuel, we use air charge to calculate fuel charge by multiplying it by desired F/A ratio, which is calculated from stoich F/A ratio (a table lookup from ethanol %) and desired equivalence. Desired equivalence comes from the ETC code, but is limited by a lean limit table which is indexed by RPM and Charge. Spark is calculated as a table lookup from RPM and Charge also, with a modifier for desired equivalence.

The goal on the engine side is to be able to calculate the optimal fuel and spark at the current engine conditions (all measured), desired equivalence is the only input directly from the ETC code.

On the ETC side, pedal load is used as load. It is calculated from a table lookup from Pedal (raw %) and N/V ratio (RPM/MPH). Pedal load itself is a % of torque from min MAP to WOT (max boost) at the current RPM (min MAP usually results in negative torque). Pedal load is used to determine desired equivalence per cylinder (fuel enrichment near WOT, and cylinder deactivation at light loads). These and parts of the air model are used to determine the TPS command (since a given Charge requires a different TPS at different RPM's).

For mechanical throttle, we initially used Charge for everything but this was bad with the turbo (fuel enrichment was delayed as boost built). We later incorporated some of the ETC code, even with mechanical throttle, and it worked quite well.


tl;dr we use air mass as engine load, and treat driver load separately from engine load.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke


Top
 Profile Send private message  
 
 Post subject: Re: Load sense method(s)
PostPosted: Mon Oct 12, 2015 10:11 am 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4250
apalrd wrote:
I found this forum from the old O5E forum. I'm a controls developer on a university SAE Collegiate Design Series program.

We use 'charge' as our primary engine load and 'pedal load' for driver load. They are treated differently in different parts of the software. We use electronic throttle control, so they are not directly tied together.

........


Welcome.

Hopefully the o5e forum isn't dead yet...just holding on the new HW design.

I was on an FSAE team too many years ago, great project.

What are you guys using for hardware/firmware/Tuner (user interface)?

I'll have to think about what you're doing a bit as it's similar but I think backwards from what I'm doing....but I might not be understanding properly which gets me to the need to think about it.

I'm calculating Mass Air flow and fuel require with the same math you are of course.....but I don't consider that load, I calculate it from the load. Currently load % is MAP/Baro*100, but as John as talking about on an ITB setup I'll most likely need to include TPS in some way because vacuum tends to disappear fast on ITB setups.

Mass for and VE are global, cylinder info (which I haven't added yet) will be local meaning a correcting from the global value. My thought here is its easier to tune the engine then correct the cylinders than it is to tune each cylinder from the beginning, especially when there are 12 cylinders and my expectation after all the flow matching I did is that all 12 will be the same....or so I hope, but cylinder corrections will be available.

I'm not sure about bank correction. In enginelab the bank info is entered directly into Engine Description function and is not available outside that function....so you'd need to enter it twice which opens the door to errors. I can setup a "wizard" that would make them match, but I haven't played with those yet. If I decide to go the path of twin ECUs, then doing banks would work better with ECU1=bank 1. I'll have to see where this goes.

The DBW I haven't done any actual work on yet but the plan is to do basically what you're describing using a tranfer table to convert pedal position to desired TPS....I hadn't thought about tying in MPG or gear selection I guess...maybe.....another thing for me to think about.

I'm sure this will all get much better with time and I'm waiting a bit to see what EngineLab releases for their generic model because I'd like to use as much of their stuff as possible to leverage community work instead of just my own work.


Top
 Profile Send private message  
 
 Post subject: Re: Load sense method(s)
PostPosted: Mon Oct 12, 2015 12:07 pm 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
We use a MotoHawk controller http://mcs.woodward.com/support/wiki/in ... e=MotoHawk and their MotoTune software. MotoHawk is pretty great but MotoTune definitely is not, but MotoHawk supports CCP/XCP also so we are starting to use ATI Vision. We use similar but not identical code for Formula SAE (mechanical throttle) and SAE Clean Snowmobile (electronic throttle). Motohawk includes the low-level and we write the high-level code in Simulink (then it's auto-coded to C and compiled). We use the 128 pin module (which has an MPC565) and 48 pin module (with MPC563), the 128 pin has a lot of useful IO which is sparse on newer MPC5554/MPC5634 based modules (we need a lot of H bridges and frequency inputs, so the V12 quad cam module is what we use). The lack of an eTPU is however frustrating (the TPU3 is accurate but the pulse scheduling inflexibility makes things like multi-strike difficult).

We don't map each cylinder separately. We have only two cylinders, we map VE base and VE offset. VE cyl1 = VE Base + VE Offset, VE Cyl2 = VE Base - VE Offset. VE Base is mapped first, on the engine dyno, then we go back and map VE offset. If we had more cylinders, we would probably do it differently (maybe a lower-resolution trim table added to each cylinder on top of VE Base). For an odd-firing engine (two cylinders fired 180 deg apart) the pressure pulses in the intake cause huge VE differences between cylinders (this is partially because we filter MAP over one engine cycle, if we kept track of MAP separately per cylinder we probably wouldn't need the VE offsets). For an even firing engine I don't think we would need any correction.

We do use Charge as load for the majority of the engine management side. The air calculation is done first, it uses pressure ratio (MAP/Baro) to index the VE table (so pressure ratio is Load for VE). Once air mass is calculated, everything else in the engine control uses it as load, so it is used as the load index on all of the fuel/spark tables and for some of the ETC code. O2 feedback adapts VE, so O2 learning changes Charge - That is why VE and Charge are treated separately per bank (since each bank has a separate O2 controller).

ETC is quite different from a direct transfer function. The transfer function from pedal input to torque request is direct through a table. We use the output of that table as 'driver load' which is used for most driver features (like DFSO, power enrichment, tip-in power enrichment, boost limit, dropping cylinders, etc). The actual TPS setpoint comes from solving the air model backwards - ETC setpoint is an air charge (mg/cyl/cycle) which is converted to airflow (mg/sec) with Ncyl and RPM, the TPS setpoint comes from this airflow.

Edit: More info
Charge can be calculated directly from a MAF sensor and RPM. It's also possible to calculate mass airflow with a fuel flow meter and O2 sensor, we sometimes do this. So we can use the modeled charge, MAF sensor, and Fuel/Air airflow to check and calibrate our model.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke


Top
 Profile Send private message  
 
 Post subject: Re: Load sense method(s)
PostPosted: Mon Oct 12, 2015 1:26 pm 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4250
looked at the MotoHawk stuff some time back....good but the pricing for a retail custom seemed high. They have a massive SAE team discount don't they? That would make it hard to pass up.

Ok, so your "charge" is my "Load" for all practical purposed it sounds like but I'm not currently separating Engine load from driver load. Load based enrichment is handled in the load v rpm AFR table and Tip-in enrichment/foot-off derichment is handled in a stored fuel/%-makeup calculation described at the end of this thread:

viewtopic.php?f=19&t=152

I THINK it will work...but you guys are WAY ahead of me since you have a running engine to test on. :oops:


Top
 Profile Send private message  
 
 Post subject: Re: Load sense method(s)
PostPosted: Mon Oct 12, 2015 3:08 pm 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
Yup, they have a pretty big discount on the software, and some on the hardware. In the OEM low volume and rapid prototyping world, it's really quite cheap and flexible, but not quite in the DIY price range. The new MPC5634M based module is almost $600.

Yup, you're right on load. Charge is load for the engine.

With ETC, the driver request isn't tied to what the engine is actually doing, so we needed to split the driver intent off from the engine load. Once we did that, using the split load method on mechanical throttle engines made a lot of sense and we did it there too.

We actually have transient enrichments twice. One is charge based (x-tau) and one is pedal load based. The charge based enrichment is calibrated to hold a fixed AFR through engine transients. The other is calibrated to add or subtract AFR target during pedal transients as ETC catches up. This is done so we can dune charge based enrichment once for the engine, and tune pedal enrichment several times in different eco modes (for better fuel economy or performance). Eco cals don't enrich at all, and we even dampen the throttle response intentionally for them.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke


Top
 Profile Send private message  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group