PowerVision 2.7.10475
PV780
Windows 8.1 Pro

I started with the MSTD PV780 build. I created a simple activity program that monitors a digital input into the PV780 every second. When the input is active, the program sets the Dm1.Internal variables and then fires the action DM1SetInternalFault((Empty)).

According to the PowerVision literature, the description for the Dm1.InternalLampStatus variable says this:

The Lamp Status of the user-defined internal DTC.
0=none
1=yellow
2=red

If I set the Dm1.InternalLampStatus to 1, and activate the input, a red fault is shown on the screen. If I set the variable to 2, the green background fault is shown. If I set it to 0, nothing is shown.

How can I make a yellow fault show? Is there a bug with the Dm1.InternalLampStatus variable, or an issue with the proccess that uses the Dm1.CurrentBackground variable?

I have attached the copy of the MSTD configuration. The only modifications I made were adding a digital input 1 variable and creating the activity program and timer (in group TEST).

Thank you

Hello jbilleter,

It looks as though the documentation is incorrect. The Dm1.InternalLampStatus seems to be using the J1939-73 DM1 Lamp Status byte definition so that x10 and x01 will set the Dm1.LampStatus to 1 (the red/stop overlay) while x40 and x04 will set the Dm1.LampStatus to 2 (the yellow/warning overlay).

It is mixing the standard with the non-standard. I think all of the lamp status variables from the diagnostic message application should be according to the standard and the configuration should have to decide what bits are set. That's my opinion. I think most users like the ease of getting the 0, 1, 2.

Anyway, we will need to update the document with accurate information.

Thanks! Hope this hasn't been to inconvenient.

Great! Thanks for the reply and clarification stalley. I should have thought of that too I changed it to a value of 4 and received the amber status.

I have another quick question. I found another post where you mentioned this below:

"There is a limitation in PowerVision Configuration Studio 2.7, displays can not transmit the standard DM1s. To be able to forward fault codes, you will need to use some other PGN other than the PGN 65226. This will be available in the 2.8 version of the tool."

Does this only refer to the "transmit" feature built into the CAN port, or does this also apply to FFCAN messages? I reason I ask is because before I took the DM1SetInternalFault((Empty)) approach, I used FFCAN messages and transmitted the PGN 65226 out of the same CAN port, hoping that the diagnostic message would be displayed on the PV780. I could see the transmitted PGN 65226 message on CANCapture, but the display never showed the message. I can duplicate the exact same message and send from CANCapture and get the fault to show on the screen.

What are your thoughts on this? I have attached a copy of the MSTD PV780 configuration that has been modified with the FFCAN message and the activity program that checks for the active input and sends the message.

What is odd to me is that CANCapture can pick up the transmitted PGN and data and show it as a fault on my PC, but the display doesn't seem to even see it.

Hi jbilleter,

The InternalAlarm mechanism is provided to help to make it easier to get faults into the diagnostic message application fault list so we don't have to do extra config work to display alarms and warnings from digital/analog inputs. The MPC20 (Advanced) configuration uses them extensively.

You can use the free form CAN to transmit whatever you need. The DM1s are rather tedious because of the multipacket part of it. You are correct, with 2.8 we will be able to use the transmit device to transmit the DM1s. It will make it a lot easier to transmit fault codes in a standard PGN.

The CAN mechanism that keeps any message transmitted from a device bouncing back to the device keeps your DM1 messages from being received on the display. It is the CAN specification.

Thank you for your reply. So I could transmit out of the second CAN port and wire it to the first CAN port to get it to show up, or just use the internals for now....at least until 2.8 release. Any projected timeline for the next release?

Sounds as though 2.8 will go to internal testing next week, so maybe sometime in May or early June.

Besides being able to transmit DM1s from the transmit device, we will be able to record CAN traffic. There are improvements to performance on the displays and in PowerVision Configuration Studio.