Technical Ducato P0401 P0402 P0236 P0238 and limp mode its 2017 Euro 6, EGR changed, What do I check next

[jansla]

I would be making sure they do check it at a bare minimum. If it is blocked, then that is likely the issue and will need replacing. You would then also need to consider the future and think about replacing the DPF at the same time perhaps?

of course I will ask for it!
Sometimes I wonder if the workshop cares about the customer being happy or just about ripping the customer off as much as possible, but as I mentioned I have no choice.

Yesterday I went on my usual test route and after about 3km (time stamp 540sec File1) the same error codes again. After deleting them (File2 is after deleting) I drove for another 40km and nothing more happened. I modified your set of parameters a bit and added odo because it makes it easier for me to locate when something happened, but most of them are the same parameters, in case you are interested to take a look, see attached files.
I wonder, assuming that the turbine is ok and the whole problem is in the clogged cooler, then in an instant the error codes and limp mode and after the reset it drives like new with full power. If the LPEGR is clogged, then it is clogged, why does everything work after a while? But on the other hand, if the waste gate axle is worn and loose, it can sometimes be set correctly and sometimes crooked, and then the boost pressure is too low, just thinking...

 

[deejays]

@deejays
yes, your analysis and explanation are coherent and I have to admit that they are convincing. I hope something turns out, they have set a date for starting the turbo replacement for Wednesday, May 28th. I know that this is probably another unnecessary part replaced, but another Fiat Professional is nearly a two-hour drive each way, so I am practically doomed to the local garage. I hope they check the LPEGR and its cooler when they get there...

Australia has a reported 22 FIAT PRO dealers, but that is being overly positive for a number of reasons, and this number was significantly smaller until recently. And look at the relative size of the country! How many in Sweden I wonder?

 

[deejays]

of course I will ask for it!
Sometimes I wonder if the workshop cares about the customer being happy or just about ripping the customer off as much as possible, but as I mentioned I have no choice.

Yesterday I went on my usual test route and after about 3km (time stamp 540sec File1) the same error codes again. After deleting them (File2 is after deleting) I drove for another 40km and nothing more happened. I modified your set of parameters a bit and added odo because it makes it easier for me to locate when something happened, but most of them are the same parameters, in case you are interested to take a look, see attached files.
I wonder, assuming that the turbine is ok and the whole problem is in the clogged cooler, then in an instant the error codes and limp mode and after the reset it drives like new with full power. If the LPEGR is clogged, then it is clogged, why does everything work after a while? But on the other hand, if the waste gate axle is worn and loose, it can sometimes be set correctly and sometimes crooked, and then the boost pressure is too low, just thinking...

A valid point you make. If it enters limp mode due to the issue, you then clear the fault and it then develops full power for considerable time after, then that does rule the cooler out of the equation, and points to an intermittent fault, specially if it has been like this for the past couple of years. You would expect the cooler to be fully blocked and permanent fault by now. Run the new parameter list I have suggested. A time stamp would be better than recording odometer as that wastes one valuable slot. Is it likely to be electrical?

 

[jansla]

what a difference !! (17x!) of course there are some here in the south of Sweden, but in my case I would have to take a day off (not that easy in my job) to leave car for preliminary assessment, another day to fetch it, then two days more to leave and fetch after the repair and all that repeated how many times...

 

[deejays]

what a difference !! (17x!) of course there are some here in the south of Sweden, but in my case I would have to take a day off (not that easy in my job) to leave car for preliminary assessment, another day to fetch it, then two days more to leave and fetch after the repair and all that repeated how many times... View attachment 467111

Relatively you are spoilt for choice my friend! Now you know why I am so keen to understand the beast.

 

[jansla]

A valid point you make. If it enters limp mode due to the issue, you then clear the fault and it then develops full power for considerable time after, then that does rule the cooler out of the equation, and points to an intermittent fault, specially if it has been like this for the past couple of years. You would expect the cooler to be fully blocked and permanent fault by now. Run the new parameter list I have suggested. A time stamp would be better than recording odometer as that wastes one valuable slot. Is it likely to be electrical?

electrical is always a possibility, unable to identify so far. I accepted to change turbo firstly because garage suggested and of course it would be interesting to to know if this change influences discrepancy between desired and actual boost pressure, we'll see...

 

[deejays]

electrical is always a possibility, unable to identify so far. I accepted to change turbo firstly because garage suggested and of course it would be interesting to to know if this change influences discrepancy between desired and actual boost pressure, we'll see...

I think we have found your issue in file 1. Tell me, at time stamp of 540 seconds, when the error occurred, did you keep driving for a while in limp mode. Give me a bit of detail - I am just starting to look at the file.

 

[deejays]

electrical is always a possibility, unable to identify so far. I accepted to change turbo firstly because garage suggested and of course it would be interesting to to know if this change influences discrepancy between desired and actual boost pressure, we'll see...

You have a turbo actuator command failure, I will spend a bit of time and put a report together for you. You will note that I have included that parameter in the revised parameter list and also referred to it in a prior private message to you.

 

[deejays]

@jansla I believe you have two issues. The immediate one that is intermittently throwing fault codes and limp mode for you is the total failure of the turbo actuator command resulting in zero turbo boost drive, so it is probably electrical in nature - not likely to be the turbo boost solenoid unless it is shorting the signal out (it is the failure of the electrical signal to the turbo boost solenoid). The constant under boost is not explained by that though. It may be related to this area, so once this fault is found it may clear the continuous under boost, but it could also be due to cooler blocking.

 

[jansla]

I think we have found your issue in file 1. Tell me, at time stamp of 540 seconds, when the error occurred, did you keep driving for a while in limp mode. Give me a bit of detail - I am just starting to look at the file.

when error occurs check engine message lights on, sudden lost of power an I continue driving to find a place to stop, engine runs smoothly but has no power difficult to keep 80km/h, then I reset codes and start again and continue as normal. resetting fault codes while driving can be done but engine stays in limp mode untils it restarts.

 

[jansla]

You have a turbo actuator command failure, I will spend a bit of time and put a report together for you. You will note that I have included that parameter in the revised parameter list and also referred to it in a prior private message to you.

may it be that turbo is eliminated by limp mode?

 

[deejays]

@jansla , You reported the fault occurred at time stamp 540 seconds, and that is demonstrated in the graph below due to a total failure of the Turbo Actuator Command signal to the Turbo Solenoid.

As a result, the turbo boost drops to zero (atmospheric pressure) and the rest of the data flows from there. So, either the solenoid is shorting the signal to ground (but it would I think report that as a fault) or there is a break in the wiring of the cabling or connectors from the ECU to the solenoid, or an issue with the ECU. The one thing that points to cabling is the sudden and total loss of signal and then coming good again – an intermittent fault.

This does not however explain the consistent under boost underlying this issue (or does it?) – it may be related though, so finding and fixing the total loss cause may fix the entire problems.

One thing that also stands out as a real problem is that no matter what boost level is requested by the ECU, the reported Turbo Actuator Command is always near the maximum and never below 91% duty cycle.

That would be explained (as I referenced in an earlier post) that because the actual boost is always less than the requested boost, the ECU will drive the actuator signal harder to try and achieve the requested boost, but it never does. Why? Well, it could be that the turbo control solenoid is faulty, or the turbo actuator is faulty, or there is a loss of vacuum somewhere, or the turbo itself is faulty, or the mechanical linkages.

But! It could also be that the duty cycle is originally correct, but the actual amplitude of that drive signal is not high enough in voltage due to a high circuit or cable impedance because of a faulty cable or connector. This would tie in with the sudden loss of signal as well. So, my money is on the one cause of a faulty cable or connector in the ECU to Turbo Control Solenoid circuit path (even though I am not a gambling man!).

So, if you find that one fault (just two wires) then the fault may well be fixed, and no new turbo of cooler required (for the moment at least!).

 

[deejays]

@jansla As pointed out in the earlier Pico link, it could be an issue with a 12v supply cable to the ECU or it could be the cable from the ECU to the solenoid. If you cannot find any where that the interconnecting wiring loom has been abraded, then (possibly due to moisture) highly likely to be a bad connector pin at the ECU or solenoid itself. Seems like you may be handy with test equipment - got a multimeter? Time to go shake some cables!

 

[deejays]

may it be that turbo is eliminated by limp mode?

No, I doubt that, it is a direct result of the loss of Turbo Actuator Command.

 

[deejays]

I think we are right on the money @jansla !

Below is a snapshot of your CSV file No2 just after file No1, and you cleared the fault and the vehicle drove OK.

You can see that for most of the time; the duty cycle of the Turbo Actuator Command is showing very high at 96% and the Actual Boost Pressure is low and not coincident with Desired Boost Pressure. This is most likely because the amplitude of the Turbo Actuator Command is as I suggested very much lower than it should be, probably due to cable or connector impedance. Except for two brief moments when the cable or connector (probably connector) makes proper connection and the amplitude of the signal is restored to full value, and the turbo and ECU responds correctly and the duty cycle drops to where it should have been all along, and the Actual Boost Pressure matches the Desired Boost Pressure. The speed of the response would indicate an electrical fault and not mechanical within the turbo itself. Check the cabling and all connectors between the ECU and the Turbo Control Solenoid. There is at least one interfacing connector (D004 – Front Engine Coupling). There are also other connections, including fuse distribution, voltage and earth supply, but I think this will do for starters.

I urge you to run the revised template for your engine as posted on P87 as it not only includes the Turbo Actuator Command, but also the Power Supply to the ECU (Battery Voltage).

 

[Fredastaire]

@deejays @jansla the above conversation raises a few thoughts.
1/. Do a thorough check of the vacuum pipes and reservoir for cracks/ splits.
2/. Add a supplementary earth wire between engine and inner wing.
3/. Is the turbo solenoid genuine or pattern part? Originals have a long vent pipe going up behind the scuttle to a filter. Pattern ones don't have this venting.

 

[jansla]

@deejays @jansla the above conversation raises a few thoughts.
1/. Do a thorough check of the vacuum pipes and reservoir for cracks/ splits.
2/. Add a supplementary earth wire between engine and inner wing.
3/. Is the turbo solenoid genuine or pattern part? Originals have a long vent pipe going up behind the scuttle to a filter. Pattern ones don't have this venting.

1. done
2. voltage drop measured with min/max function of digital multimeter under the load of starter cranking the engine is 0.324V indicating no issues from this side
3. genuine from factory, changed to genuine - no difference

 

[jansla]

I think we are right on the money @jansla !

Below is a snapshot of your CSV file No2 just after file No1, and you cleared the fault and the vehicle drove OK.

You can see that for most of the time; the duty cycle of the Turbo Actuator Command is showing very high at 96% and the Actual Boost Pressure is low and not coincident with Desired Boost Pressure. This is most likely because the amplitude of the Turbo Actuator Command is as I suggested very much lower than it should be, probably due to cable or connector impedance. Except for two brief moments when the cable or connector (probably connector) makes proper connection and the amplitude of the signal is restored to full value, and the turbo and ECU responds correctly and the duty cycle drops to where it should have been all along, and the Actual Boost Pressure matches the Desired Boost Pressure. The speed of the response would indicate an electrical fault and not mechanical within the turbo itself. Check the cabling and all connectors between the ECU and the Turbo Control Solenoid. There is at least one interfacing connector (D004 – Front Engine Coupling). There are also other connections, including fuse distribution, voltage and earth supply, but I think this will do for starters.

I urge you to run the revised template for your engine as posted on P87 as it not only includes the Turbo Actuator Command, but also the Power Supply to the ECU (Battery Voltage).

View attachment 467147

very valuable! You noticed a decrease in the actuator command in the FESExp_2505171346 file... but no error occurred during that time, and in the FESExp_2505171322 file... before the error occurred, the actuator command remained at a fairly constant level of 96.97. Similarly today. See attached files. I drove the same route and recorded the parameters according to your recommendation. The error occurred. When I do not have "ODO" data or what the check engine light status was, it is a bit difficult for me to determine the exact moment of the error, but approximately it was a time stamp of 519sec. And here again, the actuator was stable before the error occurred, although the difference in desired and actual boost pressure was in the range of 370-560mbar during the entire 9 seconds before the error occurred. The question is whether this is really the problem here?

There is one more aspect in all this that we should not forget about. We read signals from CANbus where individual frames are sent at speeds of up to 1Mbps. Our MES registers about 26 parameter frames per second. I suppose that this results from the fact that it has to send a request for a specific frame and wait for a response if I understand the principle of the CAN bus correctly. Different frames have different priority levels and sometimes a few ms pass before the expected frame arrives. It is possible that our registration system does not see all the messages circulating in the CAN network.

Probably if we limited ourselves to just a few parameters we could register much faster. Example: let's take the file FESExp_2505171322... when an error occurred at time stamp 540.4sec the boost pressure value was 1947mbar registered by MES. However, the freeze frame recorded by the ECU was 1031 mbar. See attached screenshot of freeze frame. This indicates that this is not exactly the same moment as the ECU records and the MES records. Today, as before, the error occurred about 4 km after the start. This has happened several times in a row. Repeatability! Temperature dependence! It is possible that it depends on the incorrect electrical connection. Maybe we are close?

Today I did not managed to check more, and in addition it was raining like cats and dogs, a north wind of 65 km/h, but I will check the connections with the solenoid again in the next few days, but only after work. I did it last summer. All the ECU pins were sterile.

I would also like to try connecting an oscilloscope (pico) to the solenoid valve and drive the same route again to see what exactly was happening there when the error occurred. My Pico probably won't record too much, I just have to set some kind of threshold, the question is what but I'll try something.

 

[deejays]

@jansla Before I even download and look at your latest files, I want to share with you my further thoughts. I want to say what I was going to say before I look at the new data so that my thinking and what I say is not influenced by the new data. As I have said before, this is a complicated beast with multiple sensors and actuators with multiple and interrelated feed back loops. That is why it is extremely difficult to diagnose an issue, with many pitfalls awaiting. It is no wonder, that even the fully trained factory technicians have trouble, and the result is what amounts to the parts canon being fired. We have even less information at our disposal and are trying to second guess and reverse engineer to help resolve an issue. With feedback loops, it gets down to the basic “chicken and egg” conundrum. Which came first? And, as you have rightly said, the data transfer is slow, and even slower the more parameters you record in MES. You can overcome that as you say, by homing in on the likely suspects and reducing the parameter list, and we probably have enough information now to make that decision to do so. The other alternative is to set priorities for refresh time for individual parameters within MES.

Getting back to that chicken and egg. I have duplicated the same segment of graph from the previous day. You will recognise it immediately. But I have now overlayed the LPEGR valve position (and HPEGR – but it is fully closed and irrelevant here).

I have a question for you. Which came first? Was it the LPEGR closing down from the near fully open position thus allowing fresh air in and not strangling the engine, so that the turbo had some air to boost, and so the duty cycle dropped to prevent over boost (and actually provide the correct boost), or was it the turbo boost solenoid circuit coming good momentarily and the boost corrected briefly and the LPEGR valve closed down to where it probably should be in response? Bang! There is the issue…. And to make it harder – is the report timing issue we are aware of.

My gut feel is that it is a blocking cooler, but as already said, it could be anything in the turbo control section as well. But you have already had a lot of those components replaced by FIAT PRO, and you have also carried out smoke testing for leaks. So, the mechanics pointing at the turbo may(?) be correct, but we need to always check the simple and less expensive components first – which you are doing by looking at the electrical control wiring and components.

You were probably correct when you questioned if it was the “limp mode” shutting down the turbo boost the other day when the fault code triggered. But it was worth suggesting that it may have been the fault itself and driving you to take another look at the interface cabling etc.

A significant amount of data is pointing towards a blocking cooler. The only point against that (maybe) is as you have stated – it is intermittent and normally occurs during the end of the warmup cycle.

But could it be triggered by a restrictive cooler, only when there is a huge demand for boost such as heavy acceleration and or load such as climbing a hill? In other words, for “normal” driving with medium boost and air demands, the restriction is not enough to trigger a fault because the difference between actual and desired boost is not over the trigger threshold; but when large demand is placed on the engine the boost difference becomes large enough to exceed the fault level trigger and place the vehicle into limp mode?

Following are three graphs, all the same except for the data overlay for clarification.

 

[deejays]

very valuable! You noticed a decrease in the actuator command in the FESExp_2505171346 file... but no error occurred during that time, and in the FESExp_2505171322 file... before the error occurred, the actuator command remained at a fairly constant level of 96.97. Similarly today. See attached files. I drove the same route and recorded the parameters according to your recommendation. The error occurred. When I do not have "ODO" data or what the check engine light status was, it is a bit difficult for me to determine the exact moment of the error, but approximately it was a time stamp of 519sec. And here again, the actuator was stable before the error occurred, although the difference in desired and actual boost pressure was in the range of 370-560mbar during the entire 9 seconds before the error occurred. The question is whether this is really the problem here?

There is one more aspect in all this that we should not forget about. We read signals from CANbus where individual frames are sent at speeds of up to 1Mbps. Our MES registers about 26 parameter frames per second. I suppose that this results from the fact that it has to send a request for a specific frame and wait for a response if I understand the principle of the CAN bus correctly. Different frames have different priority levels and sometimes a few ms pass before the expected frame arrives. It is possible that our registration system does not see all the messages circulating in the CAN network.

Probably if we limited ourselves to just a few parameters we could register much faster. Example: let's take the file FESExp_2505171322... when an error occurred at time stamp 540.4sec the boost pressure value was 1947mbar registered by MES. However, the freeze frame recorded by the ECU was 1031 mbar. See attached screenshot of freeze frame. This indicates that this is not exactly the same moment as the ECU records and the MES records. Today, as before, the error occurred about 4 km after the start. This has happened several times in a row. Repeatability! Temperature dependence! It is possible that it depends on the incorrect electrical connection. Maybe we are close?

Today I did not managed to check more, and in addition it was raining like cats and dogs, a north wind of 65 km/h, but I will check the connections with the solenoid again in the next few days, but only after work. I did it last summer. All the ECU pins were sterile.

I would also like to try connecting an oscilloscope (pico) to the solenoid valve and drive the same route again to see what exactly was happening there when the error occurred. My Pico probably won't record too much, I just have to set some kind of threshold, the question is what but I'll try something. View attachment 467200

@jansla , I think you have uploaded older files that you have previously uploaded and not the new template ones as intended.