When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
So are you working with a PIWIS clone tool? If so, I misunderstood. I thought you were working with a developer tool. Like what they use at the factory when they assemble these cars.
In that regard, I can provide you some feedback as that’s been my window into these vehicles for a better part of two decades now. I mostly use Autologic on Porsches as it’s a licensed tool recognized by the manufacturer for use in aftermarket settings like us independent shops. So those procedures are the same on those tools as well. I haven’t really experienced failures doing either calibration. It may just be an interpolation error from using pirated software. I’m sure they didn’t get it all correct when they make these clones.
Now the reason I wanted to try not running a calibration for the distance sensor is because I have a sneaky suspicion developed from my years of servicing these cars, and coming from the VW family, that it’s just not necessary because (applying the k.i.s.s. principle), the distance sensor doesn’t really do anything intricate. It simply provides a reference point, that’s it. It doesn’t engage the forks or apply the clutches. That’s what the mechatronics does. The distance sensor is just the reference point for the TCU to monitor what the moving parts are doing. I also believe that those reference points are checked every time the ignition is cycled. Which would then make the calibration redundant.
I really believe that if your issue is just a failed distance sensor, and if the car was running fine up to that point, and the calibrations were not messed with (reset) previously, you can get away with a sensor swap plug and play, and nothing further necessary. Of course this is just conjecture on my behalf, and a burning curiosity that I cure through trial an error. So far both vehicles were put back into service without calibrations performed, and they are running great. I keep tabs on them, so if that changes I will definitely update here.
Appreciate you posting your comments based on your experience, this is how we advance knowledge.
I do disagree with your comments on the purpose of the distance sensor calibration. My simplified explanation is that during the DS cal the routine moves the shift forks into hard stops (i.e. the furthest the shift fork can travel when engaging the gear). The TCU then notes the DS value at this location and uses this info when engaging the gear going forward. So if the old cal is still present, and if the replacement DS is significantly different from the old DS, the shift forks will move to the wrong place. This is particularly an issue if the TCU doesn't move the shift fork far enough with the new DS.
As to the PIWIS clones, it's pretty apparent IMO these are exact copies of the factory hardware and software. These weren't reverse engineered like Durametrics or Autels, but someone got their hands on the original documentation/software and copied it. I won't get into the ethics of that as it's not the point, but I do think I'd trust the PIWIS clone more than any of the aftermarket tools. The PIWIS clone software comes with the factory Porsche flash files for the units (none of these aftermarket tools do). These weren't reverse engineered but copied. There's no other way they could have been obtained.
We do appreciate your comments here and your willingness to share your knowledge as many shops like to keep that to themselves, so please don't take this as criticism. Just poking at various ideas thrown out here so we can all move the ball forward together. Thanks also for the info on splitting the case, it's good stuff.
I just purchased a 2012 987 S with PDK and the PDK faults were in the back of my head. Great to know there is a solution and a more cost effective solution available then buying a new PDK trans or a junkyard PDK trans. Sounds like replacing fluid every 20K miles is a sensible decision as well to prevent buildup and keep the trans happy. When this get's released, I'll purchase one for backup.
So are you working with a PIWIS clone tool? If so, I misunderstood. I thought you were working with a developer tool. Like what they use at the factory when they assemble these cars.
In that regard, I can provide you some feedback as that’s been my window into these vehicles for a better part of two decades now. I mostly use Autologic on Porsches as it’s a licensed tool recognized by the manufacturer for use in aftermarket settings like us independent shops. So those procedures are the same on those tools as well. I haven’t really experienced failures doing either calibration. It may just be an interpolation error from using pirated software. I’m sure they didn’t get it all correct when they make these clones.
Now the reason I wanted to try not running a calibration for the distance sensor is because I have a sneaky suspicion developed from my years of servicing these cars, and coming from the VW family, that it’s just not necessary because (applying the k.i.s.s. principle), the distance sensor doesn’t really do anything intricate. It simply provides a reference point, that’s it. It doesn’t engage the forks or apply the clutches. That’s what the mechatronics does. The distance sensor is just the reference point for the TCU to monitor what the moving parts are doing. I also believe that those reference points are checked every time the ignition is cycled. Which would then make the calibration redundant.
I really believe that if your issue is just a failed distance sensor, and if the car was running fine up to that point, and the calibrations were not messed with (reset) previously, you can get away with a sensor swap plug and play, and nothing further necessary. Of course this is just conjecture on my behalf, and a burning curiosity that I cure through trial an error. So far both vehicles were put back into service without calibrations performed, and they are running great. I keep tabs on them, so if that changes I will definitely update here.
As a mechanic doing work to others car you are clearly able to do what you think is in the best interest of your clients. You need to provide a warranty for your work, and if things go south, you are on the hook for the fix.
However, I would really like to emphasise to others reading this thread of my firm disagreement with the notion that a cal isn't required after a distance sensor replacement. I think you run the very real risk of shredding the transmission in some isolated circumstances. My advice. If you DIY a distance sensor replacement, conduct the 'calibration without part replacement' afterwards. It poses little risk of failing (see post above), and it provides you with essential malfunction protection.
Having been the individual who stripped a PDK and posted as much information about every part of it as I could, as well as being part of this team that is developing a new distance sensor, I think it's fair to say that our team is more knowledgeable on the PDK than most people who post information online. Do we know it all? Clearly not even close. But we absolutely know a lot more now than we used to.
To compare a PDK to a hydraulic planetary transmission (a standard automatic we are all used to), is like comparing a car's piston engine to a gas turbine that powers an aeroplane. The PDK bears little resemblance to a standard auto box. Yes they both use a valve body, solenoids etc, but apart from that you need to throw in the bin pretty much everything you have learned about an auto transmission when considering what is going on inside. If you don't, I think there is the risk of making assumptions that are flawed. Any calibration routine you may be familiar with from another transmission type will bear little resemblance to what is happening in a PDK.
Specifically on the subject of the distance sensor. This is a sensor that does a job that is not done in an auto box. A sensor like this doesn't exist in any auto box I've ever had experience with. The sensor accurately measures the position of the shift rod location to determine if a gear is correctly engaged. This job isn't required in an auto box, but is a critical part of PDK operation.
So why do I think a cal is important if a distance sensor is replaced?
The response from the OEM sensor gives from what I've seen a distance of about 7.5 - 8 mm for each channel, which is slightly less than the actual distance moved, that being 8.6mm. If an aftermarket sensor is perfectly programmed to give the exact distance moved, then when a gear is selected, the TCU will see a distance that is more than what it's programmed to look for from the OEM sensor cal. Our testing has showed us that the TCU accepts this as OK. It only has an issue with a distance that is less, or a distance that is out of limits (less than 6.0mm or more than 11.0mm with a gear selected). Looking at the comparison of the PIWIS characterisation curve (what the TCU perceives), and the OEM sensor response curve (tests we have performed) it's clear the TCU under-reports the actual distance moved. In the order of about 10%. From the graphs, if the magnet moves about 8.8mm, it will give a duty factor response of 20/80%. This is perceived by PIWIS as a distance of about 8.0mm.
So it makes sense to me that if an aftermarket sensor is programmed to give an accurate response, there is a good chance that the response will be less than the OEM sensor, and so the TCU accepts this as OK.
The thing I worry about not completing a cal post DS replacement is that if a gear is not selected fully, TCU protection from this is not being provided. I expect that in most circumstances this isn't going to be an issue, as the transmission has plenty of time to preselect a gear prior to power ever being applied assuming there are no issues with the hydraulics for gear selection. There are however circumstances where I think you won't have this happen. Manually selecting gears it sometimes is the case that you can select a gear that hasn't been preselected. You might just pull the wrong paddle. I've done this. Also, it's easy with the sport steering paddles to 'double tap', meaning you select two gear changes when you in fact only want one.
In this case a gear not preselected will be rapidly selected and then power applied. In Sport Plus for example where things are programmed to happen as rapidly as possible, I can only imagine that the moment the TCU sees the required distance, it will apply clutch pressure. If the gear isn't selected fully at this time significant damage may be the result.
One of the big issues I see is that the first 90% of shift fork travel happens easily, but it's the last little bit where the synchros are active that takes the time. Think of a manual gearbox and shifting, and how the pressure and time is the maximum just prior to full selection due to the synchros doing their thing. If right at this point the TCU thinks the gear is selected correctly and it applys clutch pressure, a trashed gearbox is going to be the result.
This situation isn't going to happen often, but it's exactly the protection an accurate cal gives you.
The software I'm using is the Porsche PIWIS 2. It has the after sales mode (what they use in the factory) and the development mode (for platform development). I use both and have made numerous videos showing many others how to use these. The 'clone' part is the interface that has replicated by the Chinese.
The difficulty of achieving a good cal is a known issue that is well documented for all PIWIS users. From my experience this is because the 'cal with part replacement' is attempted, which isn't essential for a distance sensor replacement.
Having spoken to aftermarket software providers for Porsches during the project, the calibration routine that is used in most aftermarket applications is simply a cut and paste of the PIWIS code.
Other DCTs used by other platforms in the VW stable, which include the Porsche Macan, use the Audi S tronic. It's is a completely different transmission, and widely accepted as initially an engineering failure, and recently as far inferior to the ZF PDK which is the subject here.
The S tronic uses a mechatronic unit where as the PDK does not. It uses a valve body and a separate TCU that is mounted externally. The shift fork distance sensing system used in the S tronic is different to what is used in a PDK. The S tronic uses multiple magnets and hall effect sensors for each shift rod.
I guess what I'm trying to show here is that the PDK is a different animal to pretty much anything out there. Any knowledge of one system doesn't translate to knowledge of the other.
Appreciate you posting your comments based on your experience, this is how we advance knowledge.
I do disagree with your comments on the purpose of the distance sensor calibration. My simplified explanation is that during the DS cal the routine moves the shift forks into hard stops (i.e. the furthest the shift fork can travel when engaging the gear). The TCU then notes the DS value at this location and uses this info when engaging the gear going forward. So if the old cal is still present, and if the replacement DS is significantly different from the old DS, the shift forks will move to the wrong place. This is particularly an issue if the TCU doesn't move the shift fork far enough with the new DS.
As to the PIWIS clones, it's pretty apparent IMO these are exact copies of the factory hardware and software. These weren't reverse engineered like Durametrics or Autels, but someone got their hands on the original documentation/software and copied it. I won't get into the ethics of that as it's not the point, but I do think I'd trust the PIWIS clone more than any of the aftermarket tools. The PIWIS clone software comes with the factory Porsche flash files for the units (none of these aftermarket tools do). These weren't reverse engineered but copied. There's no other way they could have been obtained.
We do appreciate your comments here and your willingness to share your knowledge as many shops like to keep that to themselves, so please don't take this as criticism. Just poking at various ideas thrown out here so we can all move the ball forward together. Thanks also for the info on splitting the case, it's good stuff.
Hello, and sorry for the delayed response. I need to make a more conscious effort to check and post on the forums more frequently (not my strong suit). I can tell you with me, I was raised under the mindset of there is no such thing as criticism, only information. I’m always out here trying to learn, expand, and improve. This is why I openly share my experiences and knowledge. In regards to the calibration, I’m not personally against it. I also have not personally experienced any failures while performing one. However, as a service professional I can tell you the consensus is split. There are service centers out there that will tell you not to perform the cal, unless absolutely necessary. Less is more. On the other side of that same token, you have shops who say you must do the calibration. Lots of contradictory information. On T-design’s own website, the instructions tell you, you may not need a calibration. But if you do, try the simple calibration first, and if that fails, do the component calibration. They also recommend PIWIS 2, as 3’s are known to cause issues with calibration. This also puts into question the reliability of the clone tools.
So where does that put me as a service provider? Well in a rock and a hard place kind of. I put myself in the shoes of the consumer. It’s frustrating, and also frightening when you are paying someone to fix this problem for you, and you are getting tugged in many different directions, by different sources. As for personal experience myself, I can tell you that I have now completed 6 sensor swaps, 5 have been 100% successful. The last one has proven an oddball, but I’m going to make a separate topic about that one, once I have all the data, and screenshots to share. Of the 5 successful cars I did, 3 I performed calls. 2 I did not. All the vehicles are running beautifully. One of the two, is my own personal vehicle. I can tell you my experience with my personal vehicle has given me the confidence and comfort to not perform the calibration on future cars and gauge the results. It’s very important for us to not fall into the tunnel vision trap. Where someone brings forth data and experiences that contradicts our findings, and so we dismiss it as erroneous. As a service professional proving you wrong or vice versa is of little value to me. What is of value to me is the WHY. It’s well known that some cars don’t require a calibration, and some do. But why? Finding that common denominator is what will greatly elevate the success rate, and reliability of performing these repairs for consumers. I have a theory. I think it’s software related, but I haven’t done enough cars yet to get a good sample size, and gather data from testing and diagnosis.
Hope it's ok to break into this thread. I've been reading a lot of this post to find an answer to a problem I've been having.
I am the owner of a transmission repair shop here in Denmark and have now repaired 6 pdk gearboxes. 4 of these have had the distance sensor replaced. All gearboxes have been to the same customer, which is an authorized Porsche workshop, so they always use the latest software and testers (now PIWIS 4). Last week I delivered 2 pdk to them a 991 year 12' and a 718 year 17' both same error code and both got new DS from T-design. 991' got a full calibration with piwis4 and everything runs perfectly. But 718' cannot complete the calibration, many things have been tried, calibration without component replacement and with replacement, latest software update in the pdk ecu is A229. Piwis says nothing, it just stops the process before the clutch calibration. The only thing I can see is that there is a signal from both rpm sensors which show the same revolutions all the time, normally only one will give a signal at a time during the calibration. Am I missing something or is the software too new for an aftermarket sensor? Hope someone will come up with ideas and input. Thanks
Hope it's ok to break into this thread. I've been reading a lot of this post to find an answer to a problem I've been having.
I am the owner of a transmission repair shop here in Denmark and have now repaired 6 pdk gearboxes. 4 of these have had the distance sensor replaced. All gearboxes have been to the same customer, which is an authorized Porsche workshop, so they always use the latest software and testers (now PIWIS 4). Last week I delivered 2 pdk to them a 991 year 12' and a 718 year 17' both same error code and both https://twoplustwo.substack.com/p/i-...ion?r=87c7bgot new DS from T-design. 991' got a full calibration with piwis4 and everything runs perfectly. But 718' cannot complete the calibration, many things have been tried, calibration without component replacement and with replacement, latest software update in the pdk ecu is A229. Piwis says nothing, it just stops the process before the clutch calibration. The only thing I can see is that there is a signal from both rpm sensors which show the same revolutions all the time, normally only one will give a signal at a time during the calibration. Am I missing something or is the software too new for an aftermarket sensor? Hope someone will come up with ideas and input. Thanks
I'd be very surprised if the PIWIS 4 wasn't compatible with the 718. They are always backwards compatible.
Unfortunately, once you have done an unsuccessful 'cal with part replacement', you need to complete this full procedure. Have a look at the link below post #1323 for an explanation of what is going on when doing the different cal types. https://rennlist.com/forums/997-foru...ission-89.html
Both speed sensors giving a speed is fine. It just means no gear is selected. Is it exactly the same speed all the time, or just similar?
The problem is that once you start the cal with part replacement and it wipes all the data for the valve body, it can take many attempts with an old transmission to get a valid cal of this again. Doing the cal without part replacement will never work after you have attempted a single cal with part replacement. You need to then only attempt cal with part replacement and successfully complete the entire procedure.
My suggestion:
- Connect PIWIS with the engine stopped. Delete all TCU and DME error codes.
- Start engine, check TCU and DME codes and check nothing has appeared.
- Begin the cal with part replacement. Don't have the car fully warmed first. Start from cold and then start the cal as soon as the oil temp gets to 60. This seems to give the best chance of success from my own experience and from others.
If unsuccessful, take note of exactly where it fails and the indications. If it passes the shift distance calibration (third in the series of five steps), then the distance sensor is fine. If it fails on the hyd system teach in (fourth step), this might take multiple attempts to get it to work. Clearing all codes and the steps above are essential prior to starting a new cal.
If it still won't work, post your indications and we'll work though it.
Hello, and sorry for the delayed response. I need to make a more conscious effort to check and post on the forums more frequently (not my strong suit). I can tell you with me, I was raised under the mindset of there is no such thing as criticism, only information. I’m always out here trying to learn, expand, and improve. This is why I openly share my experiences and knowledge. In regards to the calibration, I’m not personally against it. I also have not personally experienced any failures while performing one. However, as a service professional I can tell you the consensus is split. There are service centers out there that will tell you not to perform the cal, unless absolutely necessary. Less is more. On the other side of that same token, you have shops who say you must do the calibration. Lots of contradictory information. On T-design’s own website, the instructions tell you, you may not need a calibration. But if you do, try the simple calibration first, and if that fails, do the component calibration. They also recommend PIWIS 2, as 3’s are known to cause issues with calibration. This also puts into question the reliability of the clone tools.
So where does that put me as a service provider? Well in a rock and a hard place kind of. I put myself in the shoes of the consumer. It’s frustrating, and also frightening when you are paying someone to fix this problem for you, and you are getting tugged in many different directions, by different sources. As for personal experience myself, I can tell you that I have now completed 6 sensor swaps, 5 have been 100% successful. The last one has proven an oddball, but I’m going to make a separate topic about that one, once I have all the data, and screenshots to share. Of the 5 successful cars I did, 3 I performed calls. 2 I did not. All the vehicles are running beautifully. One of the two, is my own personal vehicle. I can tell you my experience with my personal vehicle has given me the confidence and comfort to not perform the calibration on future cars and gauge the results. It’s very important for us to not fall into the tunnel vision trap. Where someone brings forth data and experiences that contradicts our findings, and so we dismiss it as erroneous. As a service professional proving you wrong or vice versa is of little value to me. What is of value to me is the WHY. It’s well known that some cars don’t require a calibration, and some do. But why? Finding that common denominator is what will greatly elevate the success rate, and reliability of performing these repairs for consumers. I have a theory. I think it’s software related, but I haven’t done enough cars yet to get a good sample size, and gather data from testing and diagnosis.
I absolutely understand where you are coming from. Not doing procedures that might make your life more difficult when the car is currently working fine is often going to be a good course of action.
The reason for why I think a cal is often not required for successful operation comes from the testing I've done with a prototype sensor and working though issues where the prototype didn't respond with an accurate distance. The TCU seems to be quite happy with a reported distance that is well in excess of the calibrated distance it has on file. For example, if the distance on file is 7.5mm, and it reported 10.5mm, it's was always happy with that. But if it reported a distance of 6.9mm it would fail. Our thoughts on seeing this were that the logic within the TCU is that as long as the distance is a minimum to say the gear is selected OK then it's happy, and that is all it's looking for. If it's well in excess, as long as it's within the limits of 6.0mm to 11.0mm, then it doesn't seem to care.
As explained in the post above, I do believe however there is a risk by not performing a cal and having accurate numbers for the sensor outputs, even if the transmission seems to work fine without it. Are my concerns valid? No idea. Only time will tell. I'm just trying to put myself in the head of a ZF/Porsche engineer who has programmed a bunch of self protection measures into the design.
I have no interest in being 'right', but only to find out what makes this transmission tick. I hope not to be affected by the tunnel vision you talk about. I have no interest in suggesting people to do things that will make their life hard such as doing a calibration. I can only pass what I think is the best information based on the knowledge I have. If you have information that shows what has been posted previously is incorrect, I for one want to know about it. It's the only way community knowledge is improved. As a shop that is seeing a number of these transmissions, your input is very valuable, so please keep it coming.
Thanks for your help jjrichar. I have tried to calibrate it again and took pictures of the process. it stops when it tries to calibrate the shift rods. I thought the values were completely wrong?
I wonder if many or even all these failures for calibration are with cheap Chinese VCI units such as the $35 VAS6154 used with "alternatively sourced" PIWIS software. These lower quality VCI units can have intermittent problems communicating with the ECU, TCU, and other modules in the car. For simple tasks such as pulling diagnostic codes or doing some simple manual coding these cheap devices just make things take forever but with long running procedures such as PDK calibration, they can result in failures part way through the process. If I were a shop doing PDK calibrations or other complex work with a non-OEM PIWIS, I would invest in the OEM porsche VCI (thousands of $$) or an excellent quality Chinese version such as the Tabscan T6PT3G for around $600. When I switched from the VAS to the T6, every PIWIS problem or failure I had went away and all PIWIS work became so much faster.
Thanks for your help jjrichar. I have tried to calibrate it again and took pictures of the process. it stops when it tries to calibrate the shift rods. I thought the values were completely wrong?
I'm not familiar with the PIWIS 4 indications. Does it show the values of the distance sensor outputs as it does the cal? If so, what were they? Just trying to understand your comment about the values being wrong.
The values in your photo are fine for no gear being selected, which is what I would expect after a failed cal. If it's failing the shift rod cal that simply means there is a problem with the DS output..
I wonder if many or even all these failures for calibration are with cheap Chinese VCI units such as the $35 VAS6154 used with "alternatively sourced" PIWIS software. These lower quality VCI units can have intermittent problems communicating with the ECU, TCU, and other modules in the car. For simple tasks such as pulling diagnostic codes or doing some simple manual coding these cheap devices just make things take forever but with long running procedures such as PDK calibration, they can result in failures part way through the process. If I were a shop doing PDK calibrations or other complex work with a non-OEM PIWIS, I would invest in the OEM porsche VCI (thousands of $$) or an excellent quality Chinese version such as the Tabscan T6PT3G for around $600. When I switched from the VAS to the T6, every PIWIS problem or failure I had went away and all PIWIS work became so much faster.
Jeff
This is something I've considered might be an issue. However there have been consistent cal problems reported for many years by shops such as Atlanta Speedwerks who from what I understand are using OEM tools. Certainly having a tool that isn't going to work like OEM will create issues, but from what I've read of others' experiences this doesn't seem to be the source of most calibration issues. Very interested to hear from more people using OEM tools what their thoughts are.
Can I ask how you setup the Tabscan interface? Which software, and where was it sourced? Thanks.
This is something I've considered might be an issue. However there have been consistent cal problems reported for many years by shops such as Atlanta Speedwerks who from what I understand are using OEM tools. Certainly having a tool that isn't going to work like OEM will create issues, but from what I've read of others' experiences this doesn't seem to be the source of most calibration issues. Very interested to hear from more people using OEM tools what their thoughts are.
Can I ask how you setup the Tabscan interface? Which software, and where was it sourced? Thanks.
Very easy setup with no changes needed to the PIWIS software. You load the Tabscan software package and plug in the T6. It works over USB-C, Ethernet or WiFi. I will PM you with more details.
Very easy setup with no changes needed to the PIWIS software. You load the Tabscan software package and plug in the T6. It works over USB-C, Ethernet or WiFi. I will PM you with more details.
Jeff
Thanks. While I'm currently using a standard PIWIS interface from a Chinese vendor, I've had issues in the past and would like to find a more robust solution if the one I have fails.
07-25-2023, 10:59 AM
