|
britishturbo
|
 |
« Reply #90 on: January 25, 2013, 10:53:23 AM »
|
|
|
I dont think it will not log anything for one or two teeth missed, it will correct, look at the FR.
If it's "not a hardware problem", what are you suggesting then? A bug in ME7? That's pretty bold.
Have you looked at GGPDG at all before writing this? Do you know where nmot_w comes from and how it gets calculated?
It's really not normal to have a noisy nmot_w. And there are very very few things that affect how nmot_w is set up in the first place in ME7.
If it's oscillating like that, it means that either the actual revs are oscillating like that as well, which would indicate pre-ignition, but I think OP's engine would have been melted by now in that case or a problem with the crank trigger pickup.
Sorry I miss spoke... what I meant was I don't think it's a hardware issue with the crank sensor... I didn't mean to imply that it was a software issue... I'm not sure what the problem is, I'm just throwing out there I would expect to have other side effects if it was the crank sensor. |
|
|
|
|
Logged
|
|
|
|
|
julex
|
|
« Reply #91 on: January 26, 2013, 07:12:06 AM »
|
|
|
/bows to prj.
Last night's update:
Used borescope and planted it just above the ckp hole, spun the crank two revolutions tooth by tooth (that took a while) while watching the screen, they were all good, no sight of any damage whatsoever. Everything aligned perfctly, etc.
So I moved onto the electrical components and what do you know. Remember the cable rip at ckp that prompted me to get a new one? It also almost killed one of the wires at sensor plug but it the damage was invisible since mine has actual weather boot. The wire was literally hanging on 1 strand of copper which separated upon light pull once I wiggled it.
So I spliced connector from different harness using enviro heat shrink splices, then topped it off with two layers of heat shrink tube. Preliminary light throttle pulls 2-7k show no more of the rpm wobble but I will confirm today after doing couple of WOT pulls once I get out of town, so to speak.
My idle rpms seem more stable too. Previously they would be dancing a bit without any corresponding engine sound changes.
|
|
|
|
|
Logged
|
|
|
|
|
britishturbo
|
|
« Reply #92 on: January 26, 2013, 08:10:35 AM »
|
|
|
Awesome! Glad you got it figured out.
I guess I was wrong about it not being the crank sensor haha. It happens.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #93 on: January 26, 2013, 12:01:15 PM »
|
|
|
Ok, and NOW do pulls, and log what phila_dot suggested. Sorry for getting you to buy unneeded coils, but I did not have the car here, etc  |
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #94 on: January 26, 2013, 12:44:26 PM »
|
|
|
Best news ever. Glad you got it sorted!
|
|
|
|
|
Logged
|
ME7.1 tuning guideECUx PlotME7Sum checksumTrim heatmap toolPlease do not ask me for tunes. I'm here to help people make their own. Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your ex
|
|
|
|
julex
|
|
« Reply #95 on: January 26, 2013, 05:51:02 PM »
|
|
|
hmmmm, Still got ARMD intervention but the RPMs don't dance around anymore. There is a tiny bit of non-linearity in the RPM slope though which I can only associate with timing changes (due to retard) and my flexible shaft in TDI tranny and possible intermittent traction loss (but not likely in third, in second gear though I was all over the road  ) I can't describe it but the flexible shaft makes me feel sometimes like driving with big rubber shaft especially in shifts/load transitions. I also have an unforgiving LWFW twin disc unsprung clutch which has zero cushioning so any changes in load, road condition etc get directly conducted to flywheel/ckp. At this point I am REALLY interested in dampening ARMD response to high load "bucking" of car as I feel that any possible hardware shortcomings got addresses here. Since my previous experiments wit KFDMDARO resulted in null results, what else can one touch to tell ARMD to ignore jerking at high load condition? KFDMDAROS? |
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #96 on: January 26, 2013, 07:41:59 PM »
|
|
|
can you post logs including dmar and the various armd variables?
|
|
|
|
|
Logged
|
ME7.1 tuning guideECUx PlotME7Sum checksumTrim heatmap toolPlease do not ask me for tunes. I'm here to help people make their own. Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your ex
|
|
|
|
julex
|
|
« Reply #97 on: January 31, 2013, 01:02:53 PM »
|
|
|
Still chasing it, so far I suspect that the KFDMDARO table we know to exist @ 0x1DE1C is not really the one in use, I wonder if similarly to ME 7.1.1 ECU (which has three variants of this map), M-box also has more versions... When logging KFMDMARO output via out_KFDMDARO_w @ 0x3828E6 (word, unsig, 0.00305176 factor) I am getting flat "5" output even if I put all "FFFF" ("100" in table) in all fields in KFDMDARO. It must be pulling from othjer variant of this table as my changes don't affect output at all.
Can somebody with assembly know-how check where the heck is that table really located? Unless I am wrong again ofc....
Thank you.
|
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #98 on: January 31, 2013, 01:29:41 PM »
|
|
|
I posted every variable from the entire function in that ecu file.
Now that you mention it though, I think I do remember that some of the map addresses floating around where wrong.
I'll check when I get home and verify the map locations.
|
|
|
|
|
Logged
|
|
|
|
|
julex
|
|
« Reply #99 on: January 31, 2013, 01:30:58 PM »
|
|
|
Stumbled upon something...
Locations:
0x1DE1C
0x1DE7C
hold the values for two *DARO* tables. I am fairly certain that what we defined as KFDMDARO table @ 0x1DE1C is really KFDMDADP and real KFDMDARO is next up, at 0x1DE7C.
This would make sense as my logging to date showed no apparent change in KFDMDARO output while (now I noticed while posting!) KFDMDADP output was indeed at a 50 (improper conversion factor for the variable I listed in previous post, it should be 100).
I will confirm shortly after logging session but I think I found the way to attenuate the ARMD for any torque request you want, stock 50% and up is more than enough to remove ARMD intervention while in WOT.
|
|
|
|
|
Logged
|
|
|
|
|
s5fourdoor
|
|
« Reply #100 on: January 31, 2013, 01:50:08 PM »
|
|
|
Stumbled upon something...
Locations:
0x1DE1C
0x1DE7C
hold the values for two *DARO* tables. I am fairly certain that what we defined as KFDMDARO table @ 0x1DE1C is really KFDMDADP and real KFDMDARO is next up, at 0x1DE7C.
This would make sense as my logging to date showed no apparent change in KFDMDARO output while (now I noticed while posting!) KFDMDADP output was indeed at a 50 (improper conversion factor for the variable I listed in previous post, it should be 100).
I will confirm shortly after logging session but I think I found the way to attenuate the ARMD for any torque request you want, stock 50% and up is more than enough to remove ARMD intervention while in WOT.
Definitely looking forward to a simple description of this and exactly what tables to modify when you have reached a conclusion of your work. |
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #101 on: January 31, 2013, 02:19:28 PM »
|
|
|
Julex thanks for your work (and phila, as usual)
let me know and i will release a new XDF as soon as I get the right locations.
|
|
|
|
|
Logged
|
ME7.1 tuning guideECUx PlotME7Sum checksumTrim heatmap toolPlease do not ask me for tunes. I'm here to help people make their own. Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your ex
|
|
|
|
littco
|
|
« Reply #102 on: January 31, 2013, 02:56:48 PM »
|
|
|
Stumbled upon something...
Locations:
0x1DE1C
0x1DE7C
hold the values for two *DARO* tables. I am fairly certain that what we defined as KFDMDARO table @ 0x1DE1C is really KFDMDADP and real KFDMDARO is next up, at 0x1DE7C.
This would make sense as my logging to date showed no apparent change in KFDMDARO output while (now I noticed while posting!) KFDMDADP output was indeed at a 50 (improper conversion factor for the variable I listed in previous post, it should be 100).
I will confirm shortly after logging session but I think I found the way to attenuate the ARMD for any torque request you want, stock 50% and up is more than enough to remove ARMD intervention while in WOT.
As it's gear related have you tried leaving 3rd gear stock and 4th setting the 50+ row up at 100% to override the intervention and see if that helps your issue? I can't say I've had the same issue as you but I have set KFDMDADP on all gears 2 and above and the 42&50 rows to 100. I don't have KFDMDARO or KFDMDAROS on my file so only ran with this. |
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #103 on: January 31, 2013, 03:25:29 PM »
|
|
|
KFDMDARO
0x1DE7C
KFDMDAROS
0x1DEDC
KFDMDADP
0x1DE1C
SMK08MDSW (mkar_w axis)
0x1DF8E
DMARMX
0x19B9D - tmot axis @0x19B97
|
|
|
|
|
Logged
|
|
|
|
|
julex
|
|
« Reply #104 on: January 31, 2013, 04:10:28 PM »
|
|
|
My ARMD interventions are over!
Solution:
1) inspect xdf pack. If KFDMDARO is at 0x1DE1C, change it to 0x1DE7C
2) alter KFDMDARO at column "50" (% of torque engine is generationg, this is NOT load!) and put in 100% for all gears, or however you feel it should be appropriate.
Page 638 diagram explains how it works. Input dmarv_w is compared to output of several tables and appropriate bits are set. KFDMDARO gets %torque (x-axis) and gear (y-axis) and resulting threshold is returned. If dmarv_w is larger than table value, you get intervention in torque % amount via fast path timing change.
Setting a cell to 100 causes the condition to be no longer valid and rpm deviation is ignored.
|
|
|
|
|
Logged
|
|
|
|
|
