|
nubcake
|
 |
« Reply #15 on: October 18, 2016, 07:30:51 AM »
|
|
|
To me it seems that mov r3, word_381b1a
cmp r3, #0FFh
will set the V(underflow) flag when word_381b1a<FF, right? Try using the carry (cc_C) flag. |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #16 on: October 18, 2016, 07:38:38 AM »
|
|
|
Thanks for your contribution prj, I see this is clearly the best approach to switch both kfzw maps for substitutes when you have the variable cam in place. I thought I found a shortcut (and in theory it should work  ) to do without a call to a new subroutine when you have a fixed cam, but I'll do this when the last attempt fails too. Its still nice that I have messed with the code because I learned new stuff  Btw, do you use the o2 signal in/out of the ecu or the heater pins? I found that the ecu reboots when I put another voltage on the o2 input... If your ECU reboots you have errors in the code. I've always used rear o2 for map switch... never ever had any issues with it. |
|
|
|
|
Logged
|
|
|
|
TijnCU
Hero Member
Karma: +60/-4
 Offline
Posts: 690
flying brick
|
|
« Reply #17 on: October 18, 2016, 07:48:14 AM »
|
|
|
Could be I am running in circles because I am trying this on the bench... but if I use cc_V I start with zwnws=kfzw2 and if I use cc_C it starts with zwnws=kfzw1. But neither will switch. I am going to code in the new subroutine now to verify this  prj, I tested that pin without code modifications. Maybe there is a built in safety for overvoltage, but I assumed I'd better not short pins that cause the ecu to reboot. Then I found shorting the in/out pin worked without reboots. |
|
|
|
|
Logged
|
|
|
|
|
nubcake
|
|
« Reply #18 on: October 18, 2016, 08:33:24 AM »
|
|
|
Could be I am running in circles because I am trying this on the bench... You most likely are. That code is not executed until the ignition is on at the very least. |
|
|
|
« Last Edit: October 18, 2016, 08:36:17 AM by nubcake »
|
Logged
|
|
|
|
TijnCU
Hero Member
Karma: +60/-4
Offline
Posts: 690
flying brick
|
|
« Reply #19 on: October 18, 2016, 08:40:27 AM »
|
|
|
But still its weird that the map does not change while the variables that set the kfzw map in my code do change? I mean it should still select the input regardless of engine running because it follows the code... If it had a startup setting I would not be able to force one of the maps to read in the first place (at least that was my attempt to verify if I could actually change this). I put super odd values in kfzw2 and kfzw1 to verify and I get exactly that output in zwnws when I log it.... I wrote the following code, hex is included to visualize the differences in operands: calls (DA) #81h (81), 8100 (00 81) ; calls sub_818100
sub_818100
<unswitched>
mov (F2) r12 (FC), word_381B1A (1A 9B)
cmp (46) r12 (FC), #03E8h (E8 03) <threshold 10v
cc_C (8D) <switched> (03)
mov (E6) r12 (FC), #kfzw1 (90 23)
rets (DB)
<switched>
mov (E6) r12 (FC), #kfzw2 (50 24)
rets (DB) |
|
|
|
« Last Edit: October 22, 2016, 02:54:10 AM by TijnCU »
|
Logged
|
|
|
|
TijnCU
Hero Member
Karma: +60/-4
Offline
Posts: 690
flying brick
|
|
« Reply #20 on: October 18, 2016, 11:20:36 AM »
|
|
|
It works! I placed a nop at the first original jump and inserted the new code at (8)18100. I can now switch on the bench. Only funny thing I see is when switched to kfzw2 sometimes it jumps from -3 to 1.5 degree but maybe that is due to interpolation inside of the kfzw2 field combined with unstable power supply or something. Who cares, first asm victory Tomorrow I will test this in the car, I have removed the nops and only replaced the 2 kfzw2 adresses with the call to the new routine. I think I get a bit funky results because on the bench fnwue is not 1 (0.8 something) but while the engine is running it is always 1 with a non vvt camshaft. |
|
|
|
« Last Edit: October 18, 2016, 01:08:18 PM by TijnCU »
|
Logged
|
|
|
|
TijnCU
Hero Member
Karma: +60/-4
Offline
Posts: 690
flying brick
|
|
« Reply #21 on: October 21, 2016, 02:06:20 AM »
|
|
|
Funny spikes in the csv are from logging at 50hz it seems. On 20hz I can not see any strange fluctuations in the ignition output. I have tested my ecu in the car this morning, but it still will not run good. Idle is fine, but as soon as I touch the pedal it almost stalls and has a hard time to get back to a stable rpm. Ignition is all over the place, I logged and found that fnwue is swinging around 0.1-0.9 badly I need to do another baseline log with the original file to doublecheck how it behaves, but from what I remember it was steady at 1 before. Super weird, I did not alter the fnwue function in this file. I could hardcode fnwue to 1 in this routine, but I'd rather understand why it fluctuates while my cam is fixed. I verified that the ecu is okay, on the normal tune it runs without problems. |
|
|
|
« Last Edit: October 21, 2016, 02:17:09 AM by TijnCU »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #22 on: October 21, 2016, 03:31:54 AM »
|
|
|
Why not just use my code...
|
|
|
|
|
Logged
|
|
|
|
TijnCU
Hero Member
Karma: +60/-4
Offline
Posts: 690
flying brick
|
|
« Reply #23 on: October 21, 2016, 04:25:18 AM »
|
|
|
It basically is, just edited it to suit my ecu.. The switch itself works perfectly on the bench so the code is functional. I have removed the nops and only replaced the 2 kfzw2 adresses with the call to the new routine.
This is the call at the kfzw2 lookup adress calls #81h, 8100 and this is the subroutine that you posted, only with my adresses and input. sub_818100 <pins open> mov r12, word_381B1A cmp r12, #0FFh cc_C <pins shorted> mov r12, #kfzw1 rets <pins shorted> mov r12, #kfzw2 rets AHA! The flash is fd up. I just tested the base version where I put the code in and it behaves exactly the same. I think because I did a revision to get rid of my rough road controller fault code I must have set a wrong bit somewhere... It behaves exactly the same (going nuts as soon as I touch the pedal). I test my old version with new code now.. Yup, now it works  damn, I have lost so much time on this stupid troubleshooting, but its my own fault (thinking that setting 2 ASR CAN configs to 00 could not possibly be the cause...). Learn from my mistake, readers!  I'll first get to work on calibrating the kfzw maps and then maybe test my own idea later on for people that don't want to get into asm. |
|
|
|
« Last Edit: October 21, 2016, 07:41:25 AM by TijnCU »
|
Logged
|
|
|
|
TijnCU
Hero Member
Karma: +60/-4
Offline
Posts: 690
flying brick
|
|
« Reply #24 on: October 22, 2016, 02:44:56 AM »
|
|
|
I've just tested my rear o2 output on the bench again, and I have made a mistake when I configured this. I was manipulating pin 68 (Ro2 INPUT) while the variable that I use is actually pin 69 (Ro2 OUTPUT). That one directly correlates to the voltage that is fed. In my head I had to do something with the input wire to manipulate the ecu, so my plan was to short the 2 pins with a 12v powered relay (my automatic switch trigger is 12v) but now I see that I can just feed the 12v in pin 69 and it will read 1228 raw on the bench (12.28v). So just a little change in the subroutine and I can remove 1 wire from the ecu connector again I want to thank nubcake and prj that have been helping me with this asm starting adventure, and I will soon try to make a "patch" version for anybody that only wants to make changes in the hex binary like I initially was planning to. I'll update the opening post when I do so. Next adventure is writing code for the SAI 12v output to trigger my soon-to-be exhaust cutout There is also another thing that I would like to do, I want to write code that adds or subtracts a value to or from zwgru with the clutch, set and reset button of the cruisecontrol (maybe with a max of #Ah, that value needs to be stored in RAM obviously) to make a quick tool for realtime correcting timing for MBT on the dyno. When you are logging load and rpm its easy to make notes about how much timing is added or subtracted and you dont need to reflash all the time. Need to figure out a couple of things before I get started on that. The result is basically a lemmiwinks function but without cycling the ignition. |
|
|
|
|
Logged
|
|
|
|
Tim
Newbie
Karma: +6/-0
Offline
Posts: 12
|
|
« Reply #25 on: October 22, 2016, 07:41:51 AM »
|
|
|
There is also another thing that I would like to do, I want to write code that adds or subtracts a value to or from zwgru with the clutch, set and reset button of the cruisecontrol (maybe with a max of #Ah, that value needs to be stored in RAM obviously) to make a quick tool for realtime correcting timing for MBT on the dyno. When you are logging load and rpm its easy to make notes about how much timing is added or subtracted and you dont need to reflash all the time. Need to figure out a couple of things before I get started on that. The result is basically a lemmiwinks function but without cycling the ignition.
Great work TijnCU, thanks for sharing your work as its progressed. Interesting stuff about realtime correction, I've been having a look at that myself on EDC15 changing SOI, pilot and main etc. without going down the whole checksum delete or countless reflashings. If it's anything similar it may be possible to use the existing ASCET-Bypass hooks in the functions and change the RAM variables to suit. Maybe it could be of help to you |
|
|
|
|
Logged
|
|
|
|
|
nubcake
|
|
« Reply #26 on: October 22, 2016, 09:24:04 AM »
|
|
|
There is also another thing that I would like to do, I want to write code that adds or subtracts a value to or from zwgru with the clutch, set and reset button of the cruisecontrol (maybe with a max of #Ah, that value needs to be stored in RAM obviously) to make a quick tool for realtime correcting timing for MBT on the dyno. When you are logging load and rpm its easy to make notes about how much timing is added or subtracted and you dont need to reflash all the time. Need to figure out a couple of things before I get started on that. The result is basically a lemmiwinks function but without cycling the ignition. dzwoag and dzwkg are sometimes not used (maps for them are flat), but the code is there anyways. You could use that code (modify input to said maps or something like that). Just a pointer. |
|
|
|
|
Logged
|
|
|
|
TijnCU
Hero Member
Karma: +60/-4
Offline
Posts: 690
flying brick
|
|
« Reply #27 on: November 01, 2016, 01:04:00 PM »
|
|
|
Thanks for the suggestions, I'll look into it! Here is my result from the auto-mapswitching in daily driving: Acceleration on petrol (1) and lpg (2)  On the cruisecontrol switching from lpg to petrol to lpg.  Very happy with the result Now its time for adding more timing on lpg under load! (was always very conservative to ensure no excessive retard when driving on petrol in case of lpg failure or empty tank) |
|
|
|
« Last Edit: November 01, 2016, 01:08:27 PM by TijnCU »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #28 on: November 02, 2016, 12:57:40 AM »
|
|
|
You will find that you will be able to add 6+ degrees.
|
|
|
|
|
Logged
|
|
|
|
TijnCU
Hero Member
Karma: +60/-4
Offline
Posts: 690
flying brick
|
|
« Reply #29 on: November 02, 2016, 01:10:13 AM »
|
|
|
Yes, I expect somewhere between 5 and 8 degrees. How is your experience with lpg timing above 4000rpm? From the research I have done it seems that the flamespeed relatively increases with higher rpm causing the mixture to need less timing at higher rpm (about the same as petrol or even a bit less). Haven't done real world testing with this since my engine currently doesn't make any power at high rpm anyways  The Variations of brake thermal efficiency for gasoline and LPG fuels at WOT operating condition is
shown in Figure 6. The characteristics of these curves shows that the brake thermal efficiency is more for
gasoline at lower speeds and in the speed range of 3000 RPM to 4000 RPM both fuels have nearly same
efficiencies. LPG combustion exhibits higher thermal efficiency than gasoline after 3500 RPM. Since the
ignition temperature of LPG is higher than that of gasoline, ignition delay and thus combustion duration
is more for LPG [1]. This decreases the average burning rate. To accommodate this effect, engine
consumes more fuel which in turn decreases its efficiency. Hence LPG has lower efficiency at lower
engine speeds. At higher engine speeds, the higher flame propagation speed of LPG negates the effect of
ignition temperature. Here the time duration for each cycle is very low which demands more rate of
combustion to get the complete combustion of the fuel. The lower propagation speeds of gasoline flames
cannot afford the requisite combustion rate; instead the engine takes more fuel to generate the required
torque. The collective outcome of these factors lowers brake thermal efficiency of the engine for gasoline
at higher engine speeds
 |
|
|
|
« Last Edit: November 02, 2016, 02:36:38 AM by TijnCU »
|
Logged
|
|
|
|
|
