MDGN Red Stop Lamp Channel Not Clearing

I think I'm going to have to get around this by adding an IDC for the red stop lamp that is only true if the DM1 channel indicates an active fault condition AND the Red stop lamp MDGN channel is true. It seems like the MD4 might have to have power cycled in order to turn that red stop lamp MDGN back to false.

The DM1 message should be sent at 1 second interval, even when there is no active DTC. 

My recommendation is to look for PGN 65226 on the bus after the errors have been cleared. When there is zero (or one) active error, the DM1 is sent as a single frame so it should be easy to spot as PGN 65226

I ran a CAN trace (IQANanalyze) on the engine CAN network under these conditions (DM1=0, no active DTCs, Red stop lamp=True) and did not see any messages with PGN 65226.

The only time I saw 65226 being broadcast was when there was one active DTC (SPN 970 Auxiliary engine shutdown).

So the engine controller is powered on, but you cannot see the DM1 on the bus? That seems strange. 

The engine controller should be sending DM1 also when there is no active fault.

With zero or one active fault, you should see the PGN 65226 on the bus for DM1. With two or more faults, you will see the DM1 sent as part of BAM PGN 60416 and DT PGN 60160 on the bus.

One problem that I sometimes see is that a JFIN with one of these PGN:s have been added to the application. That  override reception of either single or multi-packeted DM1 messages. 

Have you confirmed that you can see both a signle and multiple DTC:s on the IQAN DM1IN channel?

I am not sure if I understood you correct, that you are powering off the engine controller to clear the fault?

This would of course mean no DM1 is sent on the bus for the period when the engine controller is off. 

But if you have set a timeout in IQANdesign on the J1939 module for the engine, then you should be seeing a No contact with the engine module after powering it down. 

And when the engine controller starts again, it should be sending DM1 on the bus at a 1 s interval, also if it has not active faults to reports. 

Hi everyone.

My comment here is that while current J1939 standards may state is should be sent at 1s continuously, this may not be the situation implentated on older ECM products that were developed/released in the preceeding years when the standard was in earlier revisions.  ie if you look at older J1939 standads, the wording was different.  Also, each OEM interprets the standards and implements in their own way.

For example, I have products that only issue DM01 "No Fault" PGN on RQST only.  When there is a fault, then the DM01 sends at 1s (without RQST being required).  So the all clear DM01 (after a fault has cleared) may or may not be sent continuoulsy.  Needles to say, I have had to implement a RQST message for DM01 regardless, to get the "all clear" fault lamp status to be accurate. Suggest to check your ECM and see if it responds to RQST for DM01 to see if this makes a difference.

Julian

Thank you Julian, that was new to me to hear some engine controllers differ here and send the DM1 for no fault only in response to a request PGN. 

Yes, engine controller is on and transmitting data, just not the DM1 message, according to IQANanalyze. Interesting that it should be. There is the BAM PGN 60416 broadcast at 5 second intervals when there is no active faults.

Yes, with one active fault I see 65226. I haven't tried causing multiple faults, but I know the issue you're talking about. I had an issue with a different program that someone tried reading 65226 as a JFIN and that prevented the default DM1 channel from being able to read single DTCs.

Yes, power off engine controller to clear the DTC, so no DM1 is active, nor is the red stop MDGN channel true while the engine controller is off. I actually tried disabling the Engine J1939 module while the power is cycled in the IQAN program. That seemed to help with clearing the ECU more quickly.

I've tried to attached the IQANanalyze log file taken after the engine controller power was cycled to clear a single active DTC (SPN 970). This log file is with the engine controller on, no active DTCs, yet the red stop MDGN channel is still true.

no active faults, red stop still active.izbx

Thank you. 

The recorded BAM is for a different PG, so this trace confirms that the engine controller you have on the machine does not send DM1 as it should. 

It would be interesting to see a longer trace that includes the last DM1 sent by the engine controller. 

I am not sure, but I have the feeling that seeing that last DM1 before the engine controller stops sending DM1 could explain why the lamp is still lit up in the IQAN application.

No faults, Aux eng shutdown fault, ECU po....izbx

I ran another trace. Initially there were no active faults, then an auxiliary engine shutdown fault occurred (SPN970, FMI31), then power to the engine controller was cycled off for 10 seconds, then the engine controller power was restored and with no active faults, yet the red stop MDGN channel remained true.

Thank you for looking into this.

Thank you Justin. 

I checked and it is now clear to me why it behaves as it does. The DM1IN reception behaves similar to a JFIN without a timeout, maintaining the last values. 

If the J1939 module is in No contact, this clears the other channels (DM1IN and SPN channels), but not the MDGN. 

The easiest would be if the engine controller could somehow be configured to send DM1 continuously. 

But I'll look into it a bit more on the IQAN side also. 

Checked some more, and it looks like it should not be too much effort to make an IQANdesign update that handle the missing DM1 by clearing old MDGN lamps after No contact /Disable. 

Thank you for looking into this. I think the added IDC that requires an active DM1 message AND the MDGN channel to be true for the red stop lamp to be shown to the operator will work well enough in our application.

In IQANdesign 6.08 the MDGN lamps are cleared also by No contact, so they get cleared also in this case where the engine controller stops sending DM1.