Tuners Rejoice! Free Tuning For M4.4!


Recommended Posts

I'm sure that's what we all thought it did because of the name of the map, though @Calvin Sonnik specifically says:

Quote

The Map "delta ignition angle at AC on" or 'KFDWWEAC' controls the level of timing drop during Idle>Part Load transition

.

Dropping the timing (retarding, as shown in his logs) gives less torque, not more. Even if it would be advancing, it shouldn't need a whopping 20 degrees of timing difference just for the AC compressor - it ain't that heavy. It seems the map does something else entirely, from what Calvin says. I'm just wondering if it only does that with the AC on and not ever otherwise, or why it would need to advance timing with the AC on.

Edit/ Well he beat me to it by a few seconds. Any native german speaker who can speculate on what "AC" means? Seems like a direct translation from the original DAMOS.

Edited by Boxman
Link to comment
Share on other sites

According to manual/Vadis the ECU will compensate torque for AC Compressor running.
This map has probably nothing to do with that compensation, but it is only used when the AC Compressor is active.
Factor should be -0.75*x  (negative value)

If AC compressor is activ KFDWWEAC is used. if not KFDWWELL is used.

code:00006605 code_6605:
code:00006605                 mov     DPTR, #0xF8AF
code:00006608                 movx    A, @DPTR
code:00006609                 jz      code_6631
code:0000660B                 mov     DPTR, #0xFCC8
code:0000660E                 movx    A, @DPTR
code:0000660F                 mov     B, A            ; B-Register
code:00006611                 mov     DPTR, #0xFCC4
code:00006614                 movx    A, @DPTR
code:00006615                 mov     DPTR, #0x36F8   ; KFDWWEAC        UEF: delta Zuendwinkel bei AC ein
code:00006618                 jb      RAM_20.7, code_661E ; RAM: 20.7 S_KO  D:PORTE1.7 N2PT  (KOS56) :  Schalterbit, AC_kompressor akti
code:0000661B                 mov     DPTR, #0x37F8   ; KFDWWELL        UEF: delta Zuendwinkel wenn LL war
code:0000661E
code:0000661E code_661E: 
code:0000661E                 lcall   code_2CDA
code:00006621                 mov     DPTR, #0xFCDC
code:00006624                 movx    @DPTR, A
code:00006625                 jb      RAM_2E.1, code_6631
code:00006628                 mov     RAM_39, A
code:0000662A                 clr     A
code:0000662B                 mov     DPTR, #0xFCDE
code:0000662E                 movx    @DPTR, A
code:0000662F                 setb    RAM_2E.1

 

Link to comment
Share on other sites

That is very odd. 

I tried activating the AC compressor and did not see a change in the timing pull on the idle>part load transition. 

Also the numbers on the map match perfectly with the timing pulled. 

So im a bit confused about this. 

Unleas the parts I was looking at were when the AC compressor was cycling on and off.

i guess my answers were not as definitive as I thought. I'll need to find a car with a compressor that does not kick off occasionally while running. Or I'll need to take a video and system nc it with the data log to make sure the AC compressor is on. 

Also is the KFDWWELL map does not correspond to the timing pull I have seen. Unless the load scale is wrong. 

Edit: The maps don't match perfectly everywhere. Pics to come.

Looks like the maps might be limit maps? Left map is KFDWWEAC Right map is KFDWWELL. Bottom graph is green for actual timing and red is per the ignition map. In this datalog i am positive the AC compressor was not on, because a hose was cut at the time this datalog was taken, so the pressure switch would not even let the compressor kick on. also i always have the compressor off while tuning.
3gOe2ht5cK4W.png

 

Edited by Calvin Sonnik
Link to comment
Share on other sites

On 3/18/2016 at 9:08 AM, Piet said:

Yes that's true.

But I added an extra piece of code to the routine just after the readout of the load table which stores the value read from the table into a variable to be send with the logging routine.

Using the old conversion for tps, the value of the cell in the load table  shown with tracing did't match this variable.

This was because the tracing showed the wrong cell.

With X*0.4166667+13.33333 as the conversion for TPS the right cells are shown and the tracing exactly matches  the variable.

Also at other points in the xdf a conversion of X*0.4166667+13.33333 is used.

I just want to re-emphasize this real quick, as this error caused me to have horrible boost spikes. I noticed in my logs that my load request was much higher than what my engine could attain in regions where the turbo is not efficient (so <3500 RPM), even after I load-matched with history tables the actual load I reached in those regions. Since that 'load matching' was off by 13.3333 degrees, this would lead in many cases to a load request higher than actual load, meaning that in turbo-inefficient regions the TCV Duty Cycle would reach 100%. As a result, going full throttle after having been in such region, would give a horrible boost-spike due to the 100% duty cycle. 

After I noticed it was reading different cells than expected in my tables, I went looking for an explanation and saw this post. Fixed the problems right away. Maybe the ADX's in the wiki should be updated, as this is pretty important. Without, it is impossible to build an accurate load-request and TCV Pilot table.

Idle TCV angle will be 13.33333 degrees, but that seems accurate as the valve is never physically at 0 degrees anyway.

Edited by Boxman
Link to comment
Share on other sites

Tuning load on big turbo's - New method - Target Load, TCV Duty Cycle and LDR (TCV) Control Mechanism

After having found the cause of my horrible boost-spikes, I'd like to share my findings and propose a better method for mapping engines with a new BIG turbo (or upgraded TCV Valve). The standard turbo control algorithm doesn't keep big turbo's in check (at all). Unless properly accounted for by altering the LDR control parameters, the standard turbo control values introduce a pretty serious risk of engine damage when using bigger turbos. This is caused by slower spool times of big turbos. I'll start with a tl;dr:

  • Original LDR algorithm ("Ladedruckregler", translates to "boost pressure control") is not attuned to big turbos
  • As the big turbo is still busy spooling up, the LDR algorithm already "overcompensates" heavily, maxing out the TCV Duty Cycle before the turbo has spooled up
  • Once the turbo is spooled, overcompensated TCV Duty Cycle causes a huge boost spike as the turbo is essentially "free" to build max boost.
  • LDR algorithm doesn't control this spike quickly, risking engine damage if knock occurs (which will occur if no protective measures are in place)
  • A different method of tuning can mitigate this risk.

LDR (TCV) Control Mechanism

A short word on the LDR Control Mechanism; I think this mechanism is mainly intended to compensate for unforseen ambient factors such as different weather, ambient air pressure, dirty air filters etc etc, to ensure factory levels of power are reached at all times, even if these ambient factors are at play. When low on power for whatever reason, the algorithm will compensate by increasing boost pressure. Additionally I think it's also intended to compensate for slight mechanical differences between two different engines from the factory, as Volvo flashes every engine with the same ECU software. I do not think it was was ever intended to compensate for our tuning ambitions: to just compensate fully for what we ask of our engine. We usually ask for load values way outside the default Volvo specs.

With that said, I think the original tuning strategy should be altered from "edit Target Load, then edit TCV duty cycle pilot" to "edit TCV without LDR control, then edit Target Load", especially when switching to a big turbo..

"Standard" (old) tuning methodology

So, as far as I know the 'accepted' tuning method is as follows: one wants to increase engine power, and does so by increasing the "Target Load Setpoint" table to something higher. The LDR algorithm will try to reach the new higher requested load values by increasing boost pressure through controlling the TCV Duty Cycle, giving extra power. When you're satisfied with the new load values, fine-tuning is done by smoothing over the TCV Pilot table for a smooth build of pressure. For the stock turbo this usually works fine. 

With a big turbo, spooling is generally slower and it results in something like this:

(top panel: Load (orange), load request (pink), Air mass (red). Bottom panel: TPS (blue), RPM (red), TCV Duty Cycle (Green))

BoostSpike_Spike.thumb.PNG.2a33dd991eba0ce0f6190b4fc93cd5de.PNG

On the left you see the TCV Pilot Table. Note that in the lower RPM regions, TCV Duty Cycle is pre-emptively maxed out way above the Pilot Table values by the control algorithm, because the turbo is not yet done spooling up. The algorithm simply thinks "I haven't built enough pressure yet' and doesnt take spooling time into account. Once it is spooled up, the big turbo causes a boost spike and a load of 15.2 is reached when 13.1 is requested.

In my case I'm protected by appropriate water/methanol injection, but without you will for sure have serious knock events here, risking engine damage.

Proposed tuning method

I'd suggest a completely different tuning method; instead of altering Target Load and trying to reach the requested load with TCV control algorithms, I think initial mapping of a bigger turbo should be dictated by the turbo without any active TCV control at all except for the TCV Pilot table YOU insert. 

Since it is impossible to predict how fast and at what RPM your turbo will spool and be properly efficient, I think one should tune for power by manually setting TCV Duty Cycle based on RPM using the TCV Pilot table, while completely disabling the LDR routine during the tuning process. So no automatic alterations of the TCV Duty Cycle. The actual realistic loads attained (as read out from the datalog) at certain TCV Duty Cycles are completely under the tuner's control, and should then be used to build a completely new Target Load Setpoint map. This Target Load Setpoint map then automatically corresponds 100% with the TCV Duty Cycle map, which should (theoretically) mitigate all boost spikes.

Active LDR control algorithms should only be re-activated after this is done. As a final step, the LDR parameters should be attuned to your turbo's specific characteristics to avoid aggressive overshoot. 

So the proposed tuning method is:

  • Disable TCV control algorithms (LDR routine) altogether, such that the TCV Pilot table is used 1:1 without any real-time alterations. The load attained at a certain RPM is attained with a pre-set TCV Duty Cycle.
  • Start with low Duty Cycle values, and slowly increase duty cycle in regions where more power / load is desired
  • The turbo will follow 100% the values you have put in the TCV Pilot table
  • Once desired load is reached, log a few WOT runs and build the Target Load Setpoint map from scratch with the values found through History Table logging in Tuner Pro. Use values slightly lower than attained in the real-world scenario.
  • Re-activate the LDR routine and lower the parameters accordingly such that the risk of overshoot is lowered.

Remember that 'slow' LDR control is not necessarily a bad thing - you will simply avoid overshoot. In cases where you're lacking boost, the system will simply not quickly increase boost to maintain requested load. This is not a bad thing, but more a safe strategy imo. With properly set TCV Duty Cycle tables you will never be above load-request (and thus overboost) anyway, so a quick boost lowering is not required. A slow LDR is a pretty okay thing.

So how do we disable this LDR routine to start things off?

Disabling the LDR routine

More research needs to be done here as I'm not yet sure what each table does, but I shut down the entire LDR routine by altering these three tables:

  • LDR P-Part: all values to 0
  • LDR THrottle angle threshold: all values to 110 (or max)
  • LDR KFP2: all values to 0 (this disabled the routine)

BoostSpike_Tables.PNG.e96c459bddea6dd7ff890057284bcee9.PNG

Only putting the threshold on 110 and zeroing the P-part did not disable the routine. I'm not sure if the P-Part and angle threshold tables are required to disable the routine.

With these tables zeroed, the boost logic will 100% follow the TCV Duty Cycle Pilot table without any deviations:

BoostSpike_OpenLoop.thumb.PNG.50711702640aea0bdf6e7e925b3d1335.PNG

As you see my load is still way under load request, but this was just a test to see if  the algorithm worked. I can now increase my TCV Duty Cycle table to reach the loads I want to see, and then copy those loads in my Target Load Setpoint tables.

The most important thing to take away from this is that you completely avoid boost spikes when exploring the operational range of your new, big, unknown turbo.

Speculation on LDR tables:

I think the LDR control is a PI-like system, where the P-part table is the "P" factor (rpm dependant), and the "KFP2" table acts like an "I" factor. Lowering the "I" and "P" table should provide less aggressive though also slower control.

Regarding the Throttle Angle Threshold: i have no idea how this works and what it does, as I expected it to disable the routine if my TPS was <110 degrees. Evidently it didn't, since I had to zero out the P-Part and KFP2 tables to disable the LDR routine.

Also I have no idea what the "1, 2, 3, 4" axis on the LDR KFP2 table stands for.

Any help on determining what these tables do exactly is appreciated, as it will help me perform the latest tuning step (which is attuning the LDR algorithm for my specific turbo), where I want control to be slow in certain regions and fast in other regions.)

Edited by Boxman
  • Like 1
  • Upvote 1
Link to comment
Share on other sites

@Boxman From my experiences tuning a stock 19T, It looks like the I-Part is the smaller and slow correction, similar to LTFT_PL but without memory. I think the 1,2,3,4 in the Y-Axis on the I-Part (KFP2) is a "depth" map. It changes the I-Part based on how far you are from the setpoint, so kinda like a built in P-Part for the I-Part? 
I have severely lowered all of the I and P-Parts especially in the lower RPM range, and i still get overshoot. The P-Part is most of the correction even though I lowered it.
One thing you must remember is this is not a standard PID loop. DO NOT TUNE THIS LIKE YOU WOULD INDUSTRIAL EQUIPMENT. I learned about PLCs and PID loops for manufacture control a few years back when i was studying manufacturing tech. In a standard PID loop you have an input signal, your signal goal, and your output. The PID loop is then used to change the output to make the input match the goal. With the LDR control it has a Input signal (Current Load), Signal Goal (Requested Load), Output Signal (TCV Duty Cycle) AND it has a base map that corrections are based off of. The P-Part, I-Part, (D-Part?) then correct from the base map, not Zero. So if the P-Value is increased in a standard PID loop it decreases overshoot but can increase settling time, if I increase P-Value in the LDR control it increases overshoot and settling time. Also there are limiters that limit correction speed and amount. Capture.thumb.PNG.8753c5dcad82d627639b16574f6bce01.PNG

Link to comment
Share on other sites

I have also made a few spreadsheets that do math for tuning using data logs and history tables.
I finally made one semi user friendly.
This one is for adding timing into the ignition map by section and has provisions to only add timing where knock is not detected and it has data about that load cell.
There are options to change the minimum number of samples needed to consider the cell for adding timing, and the maximum average KR-Count, so there can be an allowance for a knock event or two.
I'll do a few more of these spreadsheets for AFR regulation and anti-knock.
Let me know if you find them useful. Not my fault if ya kill an engine with this.
 

Ignition Power Adder.xls

Link to comment
Share on other sites

Good stuff to know on that LDR routine. It seems overly complex for a system that imo mainly makes proper tuning a pain. Since we are tuning ourselves anyway, I think it's best we find the appropriate TCV Duty Cycle map on our own and just use that table open-loop style. Seeing as you have exactly the same issues even when tinkering with the LDR settings, I'm not sure I'll even re-enable LDR control once I found the appropriate settings.

I'm going to build my load-map with this and see how it fares in open-loop. I'll take the deviations that come with colder/hotter weather for what they are right now, as I prefer those 0.x deviations in load over the 2.x load overshoot any day.

I'll look at the ignition thing you made, but haven't gotten to the stage of tuning ignition properly at all yet, since I had so much trouble stabilizing my load. Though I plan on tuning for 0 knock, and am pretty reluctant to purposely 'use knock'. I don't want to have any during any WOT pull, not even for experimental reasons.

Edit// @Calvin Sonnik, it says I can't download your attachment though.

Edited by Boxman
Link to comment
Share on other sites

Have you tried using the boost control mod yet?
It keeps the ldr routines deactivated until a set pressure mark is reached.
This prevents the tcv duty from inflating itself to max if there's no turbo pressure at all yet.
After that it limits the tcv duty until a second set pressure is reached, again preventing the tcv duty to max out prematurely.
It almost completely eliminates the overshoot issues.

Edited by venderbroeck
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share