Audirama
Jr. Member
Karma: +3/-1
 Offline
Posts: 30
|
 |
« on: August 30, 2024, 12:36:37 AM »
|
|
|
I realize there is a place for my question. I am eager to find help as it seems knowledge on the dl501 is scarce and most people I encounter do not understand much about it.
I have an Audi 4.0t with MED17.1 I am having an issue with AMAX, for shifts the car will overrev and not shift until the rpm falls then finally shift or sometimes it wont shift at all for the 2-3 shift. has anyone ever encountered this issue? I have redone all tq tables and set minimum ignition timing for gear shift lower. I feel theres not much I can do on ECU side and TCU might be the culprit but my tcu tuner does not know what is going on either.
When i review my logs I do not see throttle closure from the ecu so I dont think the issue lies on the ecu side. Many people including myself dont truly understand the relationship between dl501 and the ecu and how to synchronize them. All i know is it is very different from the ZF and I have been chasing my tail and reading forum posts from 13 years ago trying to figure this out lol
I have attached a log of a 3rd gear pull and also an LC, if anybody has any ideas please let me know, any help is appreciated
|
|
|
|
« Last Edit: August 30, 2024, 12:48:30 AM by Audirama »
|
Logged
|
|
|
|
Audirama
Jr. Member
Karma: +3/-1
Offline
Posts: 30
|
|
« Reply #1 on: August 30, 2024, 12:46:17 AM »
|
|
|
edit: logs added to the first post
|
|
|
|
« Last Edit: August 30, 2024, 09:47:41 AM by Audirama »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #2 on: August 30, 2024, 01:17:58 AM »
|
|
|
Bad ECU file, bad TCU file or both.
There's no issues with this transmission up to 1000nm on stock clutches, if you know what you're doing.
|
|
|
|
|
Logged
|
|
|
|
Audirama
Jr. Member
Karma: +3/-1
Offline
Posts: 30
|
|
« Reply #3 on: August 30, 2024, 09:43:53 AM »
|
|
|
Bad ECU file, bad TCU file or both.
There's no issues with this transmission up to 1000nm on stock clutches, if you know what you're doing.
I appreciate the guidance PRJ I read a lot of your old posts for info and tips. I have found that you have answered nearly all the questions I've had at some point in history lol In all honesty this is a problem going on for us making higher power on this platform. I know of at least 4 other tcu tuners that are having this issue. It seems where I am, nobody really knows what theyre doing. I actually read one of your old responses where you said, if you are getting throttle closure on shifts its ECU side not tcu side so thats why I thought maybe my issue lies on the TCU side since it is not trying to close throttle on shift. But truthfully I do not know. As far as ecu side, I follow the methods from the s4wiki and with proper tq reporting (or trying) but i started with an OTS map that did not do that and took a different brute force tuning approach so I am sort of undoing it all and trying not to miss anything. If the issue is on ecu side I would love to fix it, can I post my file here for review? as far as tq, I am making a lot of power, unsure if its 1000nm, but its close. Last time i logged tq indicated tq peaked at over 800 in 3rd gear and clutch tq was at 780 I believe, so I may be close but I cant say for sure I am hitting that limit. My current logger does not log tq in nm only % but I am willing to buy vehical to see more data from the trans if possible. Anything that can help us figure out what is going on. My clutches are getting cooked everytime I flash a new file and try to do a 1/4 run and it does this |
|
|
|
« Last Edit: August 30, 2024, 09:49:42 AM by Audirama »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #4 on: August 30, 2024, 12:02:04 PM »
|
|
|
You need proper gearbox tune, that's all. ECU is not supposed to close throttle on shift. All those people who only know how to change maps in calibration and torque limiters are not going to solve it. There is a fundamental limitation that needs fixing  |
|
|
|
|
Logged
|
|
|
|
Audirama
Jr. Member
Karma: +3/-1
Offline
Posts: 30
|
|
« Reply #5 on: August 30, 2024, 02:57:46 PM »
|
|
|
You need proper gearbox tune, that's all. ECU is not supposed to close throttle on shift. All those people who only know how to change maps in calibration and torque limiters are not going to solve it. There is a fundamental limitation that needs fixing I know you dont sell tunes but are there any TCU tuners you recommend? I'm on my 2nd tcu tuner now, about ready to buy PCM flash and fall down a rabbit hole at this point scouring the internet for documentation |
|
|
|
|
Logged
|
|
|
|
jcsbanks
Full Member
Karma: +19/-3
 Online
Posts: 146
|
|
« Reply #6 on: August 30, 2024, 06:36:21 PM »
|
|
|
In DS1 4.0T OTS maps, KFMIRL is from a stock map except the 80-100% torque columns. KFMIOP is inverse as it should be.
We really tried to do the minimum bend possible to get up to 300% load able to be requested, but whilst trying to keep it linear as well as actually increasing torque up to the load limit.
It is a compromise. It could be that you could get a perfectly linear table scaled up to 2000Nm if you change Com_facTrq_C and Com_trqFacOfsMLB_C as per the funktionsrahmen and the scalings of Nm to % torque and then consider all the implications across torque % across the rest of the maps, but I've not tried it personally, so I don't know whether it would help anything.
For DQ500/2.5T we got it nicely linear to 400% load along with CAN scaling changes in Com_facTrq_C and Com_trqFacOfsMLB_C as an example which was overkill for stock internals, but is only a starting point for going higher.
You also have some custom options in Tra_swtTrqPrtInCAN, but with a TCU tune you can just set it to 1.
We're happy to hear any criticisms or suggestions of what we could improve on the ECU side in our OTS maps, but we gave it a lot of thought based on what we could study and test and all our regular OTS tunes don't request closer than 200hPa of the stock pressure sensor limits so don't run huge torque anyway. None of our code changes remove any flexibility you have in calibration.
|
|
|
|
« Last Edit: August 30, 2024, 06:38:54 PM by jcsbanks »
|
Logged
|
|
|
|
Audirama
Jr. Member
Karma: +3/-1
Offline
Posts: 30
|
|
« Reply #7 on: August 30, 2024, 10:15:36 PM »
|
|
|
In DS1 4.0T OTS maps, KFMIRL is from a stock map except the 80-100% torque columns. KFMIOP is inverse as it should be.
We really tried to do the minimum bend possible to get up to 300% load able to be requested, but whilst trying to keep it linear as well as actually increasing torque up to the load limit.
It is a compromise. It could be that you could get a perfectly linear table scaled up to 2000Nm if you change Com_facTrq_C and Com_trqFacOfsMLB_C as per the funktionsrahmen and the scalings of Nm to % torque and then consider all the implications across torque % across the rest of the maps, but I've not tried it personally, so I don't know whether it would help anything.
For DQ500/2.5T we got it nicely linear to 400% load along with CAN scaling changes in Com_facTrq_C and Com_trqFacOfsMLB_C as an example which was overkill for stock internals, but is only a starting point for going higher.
You also have some custom options in Tra_swtTrqPrtInCAN, but with a TCU tune you can just set it to 1.
We're happy to hear any criticisms or suggestions of what we could improve on the ECU side in our OTS maps, but we gave it a lot of thought based on what we could study and test and all our regular OTS tunes don't request closer than 200hPa of the stock pressure sensor limits so don't run huge torque anyway. None of our code changes remove any flexibility you have in calibration.
You guys do great work, I'm very happy with DS1, I did not have any issues with the shifts until I started making more power and I do believe it is on the TCU not the ECU side. Take what I said with a grain of salt, it was just an observation based on other tq tables I've seen online. But I am still learning nonetheless and have no room to criticize anyone's approach. I will try your recommendation as well. I do have the TCU flag set to 1 already but i will try your recommendation with Com_facTrq_C and Com_trqFacOfsMLB_C |
|
|
|
|
Logged
|
|
|
|
jcsbanks
Full Member
Karma: +19/-3
Online
Posts: 146
|
|
« Reply #8 on: August 31, 2024, 12:33:03 AM »
|
|
|
You guys do great work, I'm very happy with DS1, I did not have any issues with the shifts until I started making more power and I do believe it is on the TCU not the ECU side. Take what I said with a grain of salt, it was just an observation based on other tq tables I've seen online. But I am still learning nonetheless and have no room to criticize anyone's approach. I will try your recommendation as well. I do have the TCU flag set to 1 already but i will try your recommendation with Com_facTrq_C and Com_trqFacOfsMLB_C
Just changing those would allow >1000Nm to be sent on CAN, but that won’t actually happen whilst 1000Nm = 100% and changing that involves a lot. It probably won’t solve any immediate problems, but may be part of a future recipe in sending linear but very high torque between ECU and TCU. I do not know what the TCU will do with it and whether it will help anything, but DQ500 appreciated a rescale on CAN as it was set lower on that platform by default even just for OTS. |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #9 on: August 31, 2024, 03:36:31 AM »
|
|
|
In DS1 4.0T OTS maps, KFMIRL is from a stock map except the 80-100% torque columns. KFMIOP is inverse as it should be. Yeah and those are not scaled correctly, they should be extrapolated not set to 80 and 100 But regardless, the ECU and TCU tune have to be done together. The IRL/IOP scaling must be provided by whoever is doing the TCU. The only other option is running way too much pressure all the time and that's no good either. |
|
|
|
|
Logged
|
|
|
|
jcsbanks
Full Member
Karma: +19/-3
Online
Posts: 146
|
|
« Reply #10 on: August 31, 2024, 05:22:58 AM »
|
|
|
Yeah and those are not scaled correctly, they should be extrapolated not set to 80 and 100 I don't understand. If keeping 1000Nm = 100% (the maximum container value for the milsol_w axis), how would you associate that value with higher load? What should be extrapolated? Presently the load values associated with 80 to 100% torque are increased to allow more load and KFMIOP is the inverse. Perhaps I have a basic misunderstanding here, but the idea was to at least have them inverse, not misrepresent torque at lower loads, try to keep it linear but also progressive. I think the underlying problem is that with 1000Nm = 100% we're out of container for the loads we want and should probably make 2000Nm = 100%, but if there is a better way to represent it within that confine that would be desirable. Thanks. |
|
|
|
« Last Edit: August 31, 2024, 05:35:26 AM by jcsbanks »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #11 on: August 31, 2024, 06:34:52 AM »
|
|
|
I don't understand. If keeping 1000Nm = 100% (the maximum container value for the milsol_w axis), how would you associate that value with higher load?
What should be extrapolated? Presently the load values associated with 80 to 100% torque are increased to allow more load and KFMIOP is the inverse.
Perhaps I have a basic misunderstanding here, but the idea was to at least have them inverse, not misrepresent torque at lower loads, try to keep it linear but also progressive. I think the underlying problem is that with 1000Nm = 100% we're out of container for the loads we want and should probably make 2000Nm = 100%, but if there is a better way to represent it within that confine that would be desirable.
Thanks. There is nothing you can do with 100% being 100%, but the inverse is only important for the ECU. For the TCU it is important that the map is linear. If you set 80% = 80% at higher RPM instead of at least trying to interpolate the value between 100% and 70% or whatever there is, then that is much worse for the TCU. In laymans terms the torque to load relationship must be a as straight of a line as possible. If you introduce a sharp kink into the line, then in case of DSG it all goes to shit. ZF8HP works differently, it does not matter there. |
|
|
|
|
Logged
|
|
|
|
jcsbanks
Full Member
Karma: +19/-3
Online
Posts: 146
|
|
« Reply #12 on: August 31, 2024, 07:06:19 AM »
|
|
|
There is nothing you can do with 100% being 100%, but the inverse is only important for the ECU.
For the TCU it is important that the map is linear. If you set 80% = 80% at higher RPM instead of at least trying to interpolate the value between 100% and 70% or whatever there is, then that is much worse for the TCU.
In laymans terms the torque to load relationship must be a as straight of a line as possible. If you introduce a sharp kink into the line, then in case of DSG it all goes to shit.
ZF8HP works differently, it does not matter there.
Can any of the TCUs make practical use of the ECU controlled torque scaling so that 2000Nm = 100%? In terms of shifts, microslip control, clutch holding capacity etc where the engine torque is say 1750Nm? |
|
|
|
« Last Edit: August 31, 2024, 07:08:13 AM by jcsbanks »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #13 on: August 31, 2024, 07:12:10 AM »
|
|
|
Can any of the TCUs make practical use of the ECU controlled torque scaling so that 2000Nm = 100%? In terms of shifts, microslip control, clutch holding capacity etc where the engine torque is say 1750Nm? The ECU can't calculate over 1000nm, this is a compile time constant checked in dozens of places. The DL501 can read up to about 1600nm, the internal torque variables are mostly signed words with 0.5 scalar. On DL501 you hit other issues way way before that, there are certain limitations on some inner calculations. If you do not take care of them then anything over ~800nm will slip anyway, so the 1000nm in the ECU isn't the problem in the first place. |
|
|
|
|
Logged
|
|
|
|
jcsbanks
Full Member
Karma: +19/-3
Online
Posts: 146
|
|
« Reply #14 on: August 31, 2024, 07:35:00 AM »
|
|
|
The ECU can't calculate over 1000nm, this is a compile time constant checked in dozens of places.
The DL501 can read up to about 1600nm, the internal torque variables are mostly signed words with 0.5 scalar.
On DL501 you hit other issues way way before that, there are certain limitations on some inner calculations.
If you do not take care of them then anything over ~800nm will slip anyway, so the 1000nm in the ECU isn't the problem in the first place.
For DL800 and ZF8 I was thinking as people have run them at very high torque, and since the ECU container is 0.1Nm/bit iirc it invites ECU patching if the TCUs could make use of it and it makes the ECU calibration cleaner. |
|
|
|
|
Logged
|
|
|
|
|
