NefMoto

Hello, i'm facing a problem with this dsg DQ500.

The gearbox is from an RS3 audi with the ST3A0L1000000 software. Gearbox is mounted, car is work but perfectly.

The problem I have is that when I shift up, the clutch slips .

With the Damos I have been able to adapt something like the times of changes, the changes with D and S, I have increased the torque limiters, but I can't make the clutch don't slip when I shift up.

Anyone of you have tried to work this gearbox and help me a little to solve the problem?

Looking for an hand  :) , thanks!

Sure, you communicate correct torque on CAN-bus ?

If yes, try to re-adapt torque-to-pressure by tech-In function and fast adapation drive

Yes, I did what you said before.

The problem is that the dsg dq500 is installed in a car that has 600NM of torque and I need to reprogram and adapt the gearbox.

The modifications with the DAMOS have helped me tune it better, but I'm missing something so that the clutch doesn't slip

You really got problems only on PONUS during torque-handover ?

Clutch will not slip as long as it "knows" the correct troque at gearbox input and all nessessary maps are able to handle 600Nm.

So extent all maps and take care torque graditens during torquehandover are high enough to handle the complete torque while troque-handover times.

It's probably that the torque gradients during the torque transfer are not correct... I was researching and I haven't found much information about this

Search for something like

Khs_DMKommendUeberMax_ko

KhsdMRampeSchnelleUe_ko[K1]
KhsdMRampeSchnelleUe_ko[K2]

But form my experiences hydraulic of DQ500 will limit the max gradient for torque, exspecially on K2.
So if you are at the limit of hydraulic, you need to longer troque-handover

Hello, with 600Nm and ori sw, clutches souldn't slip. Any logs of calculated torque ? If miscalculated, not enough clutch clamping force. Any logs of pressure on clutch ?

what car/engine is this gearbox bolted to?

In a turbo retrofit for the VW R32 MKV
Power:   445 hp / 327 kW
Torque:   580 Nm

Your engine is tuned wrong, the reported torque is not correct, that is why you have problems.
Probably you are reporting 350-400 Nm when you actually have 580 Nm. Of course the gearbox will slip in this case.

i did not understand yet....which one is this map that reported torque to tcu...anyone of you can explain better? ???

Or it's configured for manual trans :)

Sorry ?!

You tould you are not bending troque on CAN, running 600Nm on flywheel and now you are asking, in with way troque in ECU is calculated / witch maps to extend ?

If you are running around 600Nm at flywheel, you need to be able to send more the 650Nm indicated on CAN.
For this MDNORM needs to be updated first.
Witch value you are running at MDNORM ?

After MDNORM is chance ALL %MDNORM baced maps need to be chanced to


I am quite prj is correct with his objection, without knowing your software

Doesn´t care, if you have problems only in torque-handover, as he told
 ???

It's important, if it's set for manual trans it will ignore torque intervention and it will try to shift at full torque...

yes, but this is a differnd point:
You are right, upshift will be unconfortable, if you don´t react on torque-interventions, but it is not a "must". DCT will "shoot" the clutch and synchronisation will be done by force. Unconfortable to workable and "fast" under full-throttle

During torque-handover there is not torque intervention.

So if kenneth26r has only problems during torque-handover, as he worte, it makes not difference if the ECU will not reakt to torque-interventions or not  ;D

But I think, are a "some" additional problems to fix ;)

Dude, take it from some people with a little more experience on R32T and DQ500s, if the ECU is coded for manual only, it WILL upshift like a bag of shit.

Yes it is a must, it won't ever shift properly because there will not be enough pressure at WOT to hold the clutch and ramp down the RPM without slipping. It will simply exceed the physical limitation of the gearbox.

What is the difference between uncomfortable and "a bag of shit" ?!

At the end, it will upshift, doesn´t matter of quallity, but it will !
"promisted"
(I worte the same ;) )

Not true:
every DCT has enough pressure to shoot the clutch and drag the engine speed down as long if the clutches can handle the input torque at all.

It is a MUST defined by Level2-security of DCT!
Maximum useable pressure of DCT is NOT used for torque-follow, it is just used for shoot-clutch to drag engine speed down in case of no responce of troque-decrease request.

Ones again:
this upshift will work, but is quite unconfortable, but it will work !

DSG shift is not instantly release offgoing clutch and ramp incoming to max, they are both applied simultaneously, ongoing is faded in, offgoing is faded out.
If offgoing clutch is still dragging at that point (überschneidung), then without torque reduction it will not shift until the offgoing clutch is fully released, there is not enough pressure physically on ongoing to fight offgoing + overcome engine max tq, especially if it is high.
Your pump is making a certain amount of pressure, even if the solenoid valve is fully open you can never ever exceed the base pressure.

So no, no shift will happen until the first clutch is fully released!
At this point this is not anymore normal shift progress and the DSG at least on VAG will usually go into limp mode. What you are describing is extreme edge case, it's not relevant here.

At fast-torque-handover (schnelle Überschneidung), DCT will.
Only in normal torque-handover both clutches simultanous fade.These are two differend "normal" modes of torque-handover.

Not,  there is NO torque-intervention during torque-handover. Torque-intervention is only in synchronisation activ.
The shift itself is allready completed, when torque-handover is done and the ongoing clutch will carry the engine torque.
I think you are now mismatch "shifting" though the differnd phases of a shift process.

When ongoing clutch will takeover the complete engine torque, clutch is still slipping.
To stop now slipping, you can overshoot the clutch or decrease engine torque by request.
But this is synchronisation, the last phase of "shifting"

Of cause there is enough pressure for ongoing clutch to fight against offgoing.
Is status is called "bracing", because is braces both shafts to eatch other.
You can feel or measure it when decreasing vehicle acceleration during torque-handover.
The goal is, not to brace the gearbox during torque-handover and have a smoose torque-handover.

Just calculate the summe of offgoing- and ongoing clutch during torque-handover and you will see how often summe of clutch capacities is higher the engine torque. In this case you are bracing the gearbox and decrease engine speed because, engine torque is lower then torque of the two clutches.

Right, but the complete base pressure is not used at the clutch for torqueflow and maxium allowed input torque. So you have still a amound of pressue to "overshoot" the clutch.
Just exactly for shoot the clutch (or overshoot) when torque decrease is not taken over by ECU and DCT will forced decrease engine speed to actual shaft speed.

This is level2 security of DCT and a MUST by FUSI.

Defintion of "shift" is this case is incorrect. Synchronisation will not start until torque-handover is not finished. This is correct.


Not true:
to shoot clutch will allways happend the engine speed decrease is too low or engine is not synchron is allowed synchron time.
This is normal behaviour of DCT and will not give any DTC or limp home.

Every Engine-Powered-Upshift (Zwischengas-Rückschaltung) will end with a overshoot of clutch at DQ250/DQ381/DQ500 and others too
Also  shiftmode "AMax" or "fast-torque-handover" (minimal overall shift time, used e.g. at speedlimiter or AMax detection) will just instand open offgoing clutch and parallel overshoot ongoing clutch to use inertior energy of engine to increase acceleration during shift.



Short summery of this discussion:
overshooting clutches is allways used at DCT, when engine speed will not synchronice to shaft speed and engine-torque-decrease-request is not enough or is not take over by ECU.

So:
it is possible to upshift without torque-interventions.
That meens that a manual ECU, witch does not care about gearbox interventions will also work, but you will have a lot vibrations and bad shifting.
But at the end, it will work!

Of cause, it is no goal to run a vehicle like this, but ones a gain it is possible by DCT.


Now we can go back to the problem of the topic :)

This is only if you are running gearbox within operating specifications.
If you are running more than the stock torque capability of the gearbox, this is not always true.
In case of DQ500 here, yes it will have enough, it is specified for 700nm stock.

But if you run 600 Nm on stock clutches of DQ250 then this is not true anymore. No torque intervention and it won't shift at all.

Also if you try to disable torque intervention completely on DQ250 (it is possible via some switches), then the shift will be mega slow, even on cars that do not make a lot of torque.
And you can see that the pressure is ramped to max, but it takes a very long time to synchronize the RPM.

So your theory is good, your actual practice is lacking.

If you are running DCT out of stock troque capabiltiy, you MUST extend application to be able to run with the input troque. If not, complete security functions will be off and shift abilitiy and qualitiy is done. You SHOUD not do his in any way, if you want to have a more or less relaible systems



Running 600Nm on DQ250 will not work with original clutches. Extending pressure to max will not be able to keep somehow 500Nm but at least not 600Nm ( tested on benech more then one time ;) )
Using clutches with other friction will need an customized torque-to-pressure so it DCT at the will run like stock, but with more torque capacity.
If you do differend, you do not unterstand DCT operation in compleate

Depenting on application, but as you worte it work. As long, as clutch capacity is any bigger than engine torque, you can drag engine speed down, then it´s slipping. Physical laws ;)
That´s what I am talking about. Not more, not less :)

Visa-verse:
"My theorie" is practice, working in DQ-Software. Take a deep looking into it ..
Your practice seem to be try-and-error, but not based on software conditions of DQ250/DQ500

You are tuner, I am .... ;)

And now stop this discussion and do not let us make an argument of it:

I know, what I am doing, you seem too on your quatity level.
But both are differend, based on condition of work

No...please don't stop talking ...because it's much interesting "listen" what both of you have to say... there are lack of documentations about these arguments... :'(

I'm researching and testing. You have commented several things.


The ecu is configured for automatic trans ... this is not the problem.

I would like to share two videos.
In them you can see the difference with which I try to explain.

In the first video, it slides a bit. In my case, it's more than in the video.
https://www.instagram.com/p/B3sLSeWoZcS/?igshid=93es6zb4jni7

In the second, there is almost no slippage.
https://www.instagram.com/p/35mt2bShso/?igshid=ds7hp348piu4

Yes it will work, but you need to either patch the code, to bypass in-code clutch limit or force wrong adaptation, but then you always have too much pressure even when not needed. Both ways it works, tested many times.
Think about how pressure is calculated from ikp0/1 and this is how you can make the hack. Correct solution is something like 5120 mod for ECU, but for clutch torque.

DQ250 main pressure is 20 bar, and you hit in-code limitation far far far before that.

For someone who allegedly knows so much, you do not even know that there is no torque to pressure in VAG DSG?
It is friction coefficient -> ikp adaptation -> microslip controller.
And for microslip controller I is feedforward from torque essentially, this is why correct torque is so important to report. After that you have code limitation for clutch torque at 500nm on DQ250. No such problem on DL501 or DQ500.
Torque to pressure is a straight line between ikp0 (kiss point) and ikp1 (200nm), which you can not adjust, it is determined during adaptation - nothing to "customize" there.

Your torque reported from engine is wrong, as was said.
You are running 600nm, what are you reporting to gearbox? 350nm probably. Log the torque instead of posting useless video.
So fix your engine software to report correct torque and the gearbox will shift smooth like butter without any slipping.

There is no way to make a VAG DSG shift properly if you do not have linear reported torque compared to actual gearbox input torque. You will either have bad shift quality at low torque or you will have bad shift quality at high torque.
PDK has an offset correction map for clutch pressure based on input torque that makes this a non-issue, but I am not aware of a such thing in VAG DSG.

I had mounted the DSG DQ250 before and it worked without problems with that torque

Are you telling me that the ecu tuned by HGP-Turbo is wrong?

Post logs of engine torque from DQ500 gearbox WOT in 3rd or 4th gear.

If the torque is not correct, then your ECU tune had underscaled torque and your DQ250 had fudged pressure adaptation values.

There is so much bullshit chat about nothing.
Post logs or stop posting.

Jochen, you're a knowledgeable and funny guy, und ich habe schon deine beitraege irgendwo anders gelesen.

BUT in the case of DQ250 you clearly have no clue what you're talking about. I have probably over 1000 cars running over 600Nm on stock DQ250 clutches, and at least 50 of them making in the vicinity of 750 to 780Nm of real clutch torque on STOCK clutches.

There are code limitations (which prj has mentioned too, weird, huh?) to overcome before you try to run over 500Nm on stock DQ250 clutches, and because you are "....." you are exactly proving my point about not being aware of the WHOLE picture :)

So please, stop insulting your own intelligence by making such bold statements, just because you are "...." (starts with an "A" finishes with an "R") and because you think you know it all, when in fact you don't really. As I said before, I value your input on most of the threads, because yes you have that "...." approach, but you're lacking hands on experience in extreme cases that were never factored in by the OEMs.

LG

Back on point to the R32T owning OP...........

If you've looked at your flash and you find things like iop/irl or the load axis changed or stock that'll generally give you an understanding on the strategy used, although some will mix and match and f**k it up somewhat!

Yes your flash data may look like it has stock torque figures, but it just means air/fuel scaling is done more alongside the usual ambient/pressure sensor (or lack of) changes like dk/vacuum/throttle reset, plus rl/bgmszs/open/closed loop & exhaust gas temp aspects applicable for modelling amogst others. In short, your flash data changes should start to match up to the Bosch strategy attached below with some data interpretation mods that I've just mentioned.

As it is very much applicable to both tuning and regarding your DSG (it's all maths/logic & data interpretation), your 250 box has a number of changes based on what they've done - best bet 1st then is to reverse it against a stock one to see, then integrate the changes (or thereabouts seeing as it's simple maths/logic changes in data and a factor change can have the same influence as a few map changes), into the 500 box as a base for the logic. Then any further changes mentioned, gears etc after.

Start with nmot as a base in reversing/learning changes on your file seeing as it's a fundamental principle of both ecu/tcu operations and as below strat dictates - the tune will soon make sense!

Sorry, but what you decribe is chance of "torque-to-pressure" (or a torquebased "current-to-pressure"), even if there is no one special map for that ;)
clutch adaption will not work automatically, if you just chance count of clutches or friction and letting base application constant.

But ones again: I will not have an argument about this


Same to you:
my experiments are differend. Starts with the definition of "running" or how long will DCT handle > 500Nm of input-torque..
For sure because I am on a differend quality level based on condition of work.
And again, I will not have an argument about this



so pls. back to topic and be gentle to eatch other ;)

I never said it would. Hence why clutch description in calibration must match reality, otherwise clutch will grab way too hard if you have higher friction coefficient or different size.
But torque-to-pressure - such thing does not exist in calibration, it's not how DQ250 works.

And for anything above 450 Nm input torque you must patch the software, because otherwise clutch torque will be clipped at 500 Nm no matter what you do. Unless you cheat the entire process.

Yes, not in calibration, but at the end troque capacitiy at clutch based on pressure at clutch.
Physicaly ALL DCTs works via "torque-to-pressure".

DQ250/DQ381/DQ400e/DQ500 etc. control pressure via current at values and clutch adaption is a current-based correction, your are right. But at the end, this is the way "pressure-to-troque" is realised in software and mechatronic. As you know, there are still two importend pressure-sensors.

Application and testing clutchbehaviour will allway have torque and pressure as base. Thats the major values to measure and to judge.
So of cause there is "torque-to-pressure" at DQ250 and it is the way DCT work

Ones a again, we are argumenting basic definition of differend ways to work

I am not disputing this.
The way you said it, was very misleading - like there is some magical torque to pressure map in the calibration.
When actually there is not.

It calculates the characteristic (which is ... a straight line) based on inputted values and adaptation.

dose anyone know the maps for the paddles shifter?

You're right.

The reported torque of the motor is incorrect. Only report arround 300-320NM of 580NM...

They did it with bad intention.

For now, I don't want to correct the ecu. I wish I could patch the code of TCU, to force wrong adaptation and have fudged pressure adaptation values like the DQ250.

Regards

Good luck.

Correct way is to tune the engine properly.

The scaling from the MDNORM on the CAN bus only goes up to 512NM and that is not enough for turbos. This would lead to malfunctions on the bus, which is why the MDNORM on the Turbo is usually set to 320NM and the gearbox corrects it. It is right?

No, that's total bullshit.
There is a scaling variable on CAN to double the range. There is no problem to have proper mdnorm.

Your problem is not only mdnorm, your problem is that the calibration is shit and the torque is not linear... if it was exactly halved 1/2 it would still work most likely, because ikp would be 2x higher and everything would fall into place.

i have everything working good on dq500 but i need to improve these things

Take off
- clutch engagement
- engagement delay time

Launch
- launch shifting times
- launch shifting delay

Paddles
- shift delay

His tq will likely be as per factory, 350nm 2.8, 410-420nm R32, CAN rpm/tq amount same as factory in the flash etc if it's an RC/RL 0-100% interpretation rather than extension, the rest is maths - %'s, fractions etc calc'd off the oem logic.

+1, correct !

double or tripple, if needed. But accurisy will also change

This is the problem of most ECUs tunings, witch have very bad influcens to clutch behaviour during slip.

Why you kenneth26r tell differend, when I asked you, if you troque on CAN is correct ?  ???

Not trying to change course of this discussion, but does the dl501 gen 2 from the s4 b8.5 platform correlate to anything you guys are talking about? As in torque limitation. Yes I do know there’s limiters but what about hard limiters?

But is it not important to have the same MDNORM Value in ECU and TCU? I have an A6 4F with EDC17 (CDY engine and 6HP19A automatic transmission). Torque and injector opening time maps are extrapolatet to higher torque and rail pressure. So linearity of the torque model should not be an issue. If I change the map Maximales Moment am Can to higher values than 630 Nm I see less torque in the TCU and the up and down shifts are shit. So I thought that the ecu sends a percentage value of the actual torque on can bus and the Norm values help to define right input for shifting tables and so on.
I think it differs also with can version. On UDS Can versions I never had this problems and on MD1 ecus this Max Moment am Can is most time 0.
So what do you mean with scaling factor?

I must say, that I have similar problems with DQ500 from RSQ3 build in a Polo with 2.0 TFSI CDL engine with EFR turbo and 2bar + boost. I'm trying to get it right and I can say that playing with the torque model in ecu have really big influence on shifting quality. Till now I haven't found the right way to get it perfect. But I think it just needs a little more time.

At PQ/PL-based CAN-communication there is only one source for MDNORM and scaling (ECU)


What exactly you´ve changed ? MDNORM or MDMAXKBI ?
"Maximales Moment am CAN" ist normaly MDMAXKBI and only used for display on kombi and tuning-protection.


Check values on CAN-bus itself. If you changed everything correctly, troque in ECU, on CAN and in TCU MUST be simular.

it differes just CAN generation based: all PQ / PL based can bus systems work with %MDI troque based on MDINorm (witch is simular to MDNORM in ME7).
MQB CAN bus got differend torque communication.

Okay, I understand that. But then, in the 6HP19A must be a hardcoded limit, if Max Moment am Can is changed to values below 630 Nm the norm value read with vcds in the gearbox is the same as set in Max Moment am Can. All values above that result in a norm value of 630Nm and also actual engine torque values are lower than that. (in ecu I can read inner torque of 750 Nm)
Max Moment am can below 630Nm result in perfect partial load shifting behavior.

Would here help a scaling factor like Faktor für Ausgabe Motormomente am CAN (Com_facTrq_C) to get for example 2*630 in TCU?


 I think Maximales Moment am CAN (Normierwert MDI) (Com_trqMaxNorm_C) is the same as MDNORM and what you mean is Multiplexinfo (Com_trqENG5MuxInfo0_C). As I said I'm talking about EDC.

Take a deeper look in EDC17, but this should be simular to early EDC..
Com_trqMaxNorm_C is the right value for Normierwert MDI.

Your problem is, 630Nm is maximum value for MO2_max_Mo, signal is only 6bit and factor 10.
So, if you change Com_trqMaxNorm_C in EDC higher than 630Nm, CAN bus is limited and will still send 630Nm (FF FF FF). TCU will calculate torque on 630Nm and torque modell is bended ..
(I never need to chance this value in this range in my projects so fare, so did not have in mind the maximum of MO2_max_Mo  :-\ )
So, no chance send higher value in CAN doesn´t care if Diesel or Pentrol..

You need to rescale MO2_max_Mo on CAN-DBC, witch has effect on all participans on AntriebsCAN because you chanced DBC and interface between all controlers.

Thanks, I thought about something like this. So there is no solution to get more torque than 630 Nm into the tcu.

But which value has MO2_max_Mo? Is it the factor 10 on the 6bit value?

In tcu I have the map: Skalierungsfaktor für normiertes Motormoment. The value is 10. In RS6 TCU file this factor is set to 20. but changing the value to 20 changes nothing to the norm moment in my case from what I see in VCDS, it stays at 630. Never tested it while driving.

I tested it on the MED9 with DQ500, it takes MDNORM values above 630 Nm, when I set it to 850, it's 850 aswell in the TCU.

Also looked into the files of V8 TDI, the scaling factors for all Can Messages in ecu are the same as they are in the V6 files. MDInorm is 1000 Nm instead of 620 Nm. All maps regarding to Botschaftslänge and Moment have the value 8, so are you really sure, that more than 630 Nm are not possible on that Can Bus generation without scaling new all can participans?

witch  Vehicle, witch CAN-Bus-Version ?
The limit is CAN version based. It can differ between plattform or versions.
PQ-based CAN-Bus got the limit of 630Nm in all versions (upto V566)

V8 and V6 are not PQ. They are PL but Audi A6 C6 (V241) is also limited to 630Nm on CAN.
Never take a look to RS6, but e.g. R10-Touareg should also use 1000Nm. Both are not PQ-based and may use there own DBC-Version, like the Bugatties too
MO2_max_Mo is a 6bit value, see attachmend. Bit 7 and 8 is used for multiplexer-value.
On PQ-based CAN, the scaling factor is 10, so no chance to send more the 630Nm without chancing the factor.

It is possible to recale MO2_max_MO.
If you do on ECU, you chance  the CAN Interface, witch is fix in DBC based on defintion.
If you chance this defintion, you need to chance the scaling on every controler, with reads this value from CAN.
Scaling factor is not communicated on CAN, so no "autoadjust", when you chance it in ECU application.

It's a VW Polo 6R with CDL eingine from TT S and DQ500 from RSQ3. So car is PQ25 and Engine and Gearbox is PQ35.


My Car is Audi A6 C6, so limited to 630Nm.

Okay with this post you answered all my questions. Thank you

No, RSQ3 is MQB based, not PQ.
MQB can change MO_Faktor_Momente_02 in ECU and it will be send on CAN, so easy to change the limit for torque on CAN.

Okay, but the car has PQ platform. Kennbuchstabe is NZU, the gearbox is an 0BH, it has no immo inside, like normal MQB cars, or RS3 with 0DL gearbox.

Yep, agreed. Maybe it's MQB "based" but the whole car is PQ and VERY similar to 8P RS3 if it wasn't for the lack of MED9 ECU.

Guys! i have a problem with full throttle shift
car is shifting earlier than i want/ i have found 25 SHALT tabele 3d maps 14*21
but also i have found 3 2d maps, which located at #26A34 #28364 #269E0 which seems to be full throttle shift tables because it have 2 byte size
but during testing car still shift earlier
who knows dq500 logic and can help?

Hello Piar,

In which mode do you want to modify ? Drive ? Sport ?

all modes
drive\sport\amax(start from launch)

Drive : SHALT tabele 3d maps 14*21 at adress 24250

Sport : SHALT tabele 3d maps 14*21 at adress 2440C

I have changed this maps with no luck
shift point is takin place earlier than written in this tables

Damn, so I suppose one of the 2d maps IS a limiter. Don't know which one, but if you know the currently speed for upshift, you can search and try, difficult without the FR.

Damn, so I suppose one of the 2d maps IS a limiter. Don't know which one, but if you know the currently speed for upshift, you can search and try, difficult without the FR.

That's really hard man, daaaaaamn, wow, condolences, sorry for your loss, duh sorry bra.

Does anyone have any pointers of what CAN frame IDs are used for clutch pressures on a PQ35 car with DQ500?

same problem here

can you say that it is possible? i mean have you ever seen or driven a car in S and it shifted at a hight rpm?

All i found are videos from cars shifting in M...

on my car the shifts in D are @ higher rpm than the shifts in S and i tried everything to change it

prj the info you posted is invaluable, thanks a lot! I have been trying to undertand the stategy for so long. I always that that there would be a map like daten moment zu hauptdruck KL but for clutch pressures. From your post I understand that the pressure adaptation determines the kiss point or at which pressure the clutch discs start to move the car (ikp0). Then there is a fixed point at 200 nm and the line that connects those two has a fixed gradient, which if i'm not wrong should be close to 5 bar / 200nm. So one way to increase pressure would be to force a wrong adaptation, then the kiss point would be shifted at a higher pressure, and the fixed gradient would then shift the requested pressure in the whole range, like an offset, but this has obvious problems, the car would start very violently and perhaps jerk between shifts too.