Hello,

Is there documentation on how to use the DM App? If so please link...

I am having a difficult time as I have to bring trouble codes in from modbus. A lot of them. I see where to put the DTC's in, but in my case each variable is 2 bytes, with each byte being a DTC for a specific parameter. And the DTC is only active if the byte = 2 or 4.

Any help would be appreciated.

Thanks!
Phil

Can nobody help with this? Point me to ANY DOCUMENTATION?

Dear Dr Phil,
The SPN values of a DM1 message takes 19 bits or 2 bytes and another 3 bits. The SPN values range from 1 to 524,288. You do not define a DTC without specifying the Failure Mode Indicator (FMI) which is 5 bits from (0 to 31). Somehow you need to get this information into the Modbus registers. I'm assuming you are using a Non-CAN device which is why you are using the Modbus to send the information to the display. So how do you know the display got the DM1 message? I would suggest a holding register flag as shown below.
Holding Register 40000 = DM1 Flag. Set to 0xFFFF when a DM1 is generated, set to 0x0000 when Display reads DM1
Holding Register 40001 = SPN Least Significant 16-bit word
Holding Register 40002 = SPN Most Significant 16-bit word
Holding Register 40003 = FMI

Use the Display as a Modbus Master to reads the holding registers. If there is a DM1 get the SPN and FMI and send a DM1 message using the Non-CAN device source address. (It is okay for the Display to send itself a message.) Clear the 40000 holding register. Wait for the next message. Your Non-CAN device needs to be able to see these changes and make updates.

You can add the Non-CAN device DM1 messages to the Display's Configuration list of DM1s so that your DM1 messages will have Text Messages which are useful. Not clear about "And the DTC is only active if the byte = 2 or 4."
Will this approach work? With more information, I could improve this answer.
Thanks,
Phil Cebuhar

Hi Pcebuhar,

Thanks. I think I understand most of what you explained. I did not know that the display could send itself a messsage. That is quite unusual.

You suggested holding registers. Do you just mean set up some variables? I haven't heard about holding registers in Murphy displays.

Is there any documentation for using the built in Murphy applications? I see all these Actions but have no idea what they actually do. It would be nice to have a reference.

Thanks,
Phil

Hello Phil,
OK, I am understanding more now. Let me explain better where I am, and maybe you can help me get to the goal.

First, I started with someone else's code, which is always difficult. It allegedly worked at one time, but the version I have 'sort of' works. I will break down how the info is brought in from modbus and fed to DTCs.

Data is brought in using generic register names on the modbus with polling. Each register is 2 bytes and covers 2 different DTCs, each being 1 byte. A DTC value of 2 or 6 indicates an active fault and is all that I am concerned with. All of the DTCs were listed in Database/DTC Setup with their descriptions. The FMI value was used to differentiate the two bytes (1 = LSB, 2 = MSB) for each register. The register# was used as the SPN. This allowed separation of the two DTCs per register. A script was written that goes through each register, masks one byte or the other, and evaluates if there is a fault. At this point it only looks to see if the byte value is non-zero (which can indicate unconfirmed and previous faults as well). If the byte value is non-zero it writes the SPN/FMI as described above:
smWrite(VariableIDs.Dm1_InternalLampStatus,1);
smWrite(VariableIDs.Dm1_InternalSPN,ProtectionSPNFMI[Pointer][0]);
smWrite(VariableIDs.Dm1_InternalFMI,ProtectionSPNFMI[Pointer][1]);
sendEvent(EventIDs.TR_Set_Alarm);
sendEvent(EventIDs.DM1_Acknowledge_Current);

The TR_Set_Alarm is a transition that shows the DM1 pop up. I am guessing whoever wrote it had issues getting it fully into the murphy DM, so used a separate state mache to achieve.

It mostly works - the pop up works, it is populated with the error, and can be scrolled to next/previous error (this is a recent accomplishment by me, and I am not quite sure how I got it to work...). What it doesn't (seem) to do is keep the active faults to be viewed later.

So I am guessing the above script and/or state machine needs to be modified to fully utilize the murphy code. Maybe you can help me fix this, or maybe I need to start over with the method you suggested.

Oh, and I don't have any hardware to test on - my customer is doing testing on site, so a lot is being lost in communication, time, etc.

Any help would be greatly appreciated. If you think it best to start over with your method I will. I can read the registers in and break up the 2 bytes into separate vars, evaluate their value using state machines or script, and send CAN message with DTC info.

Thanks,
Phil