I have sett up a new extended CAN message in the library (0xFF7F) for use to command J1939 devices. The message transmits fine and I can manipulate the data however, the receive modules do not recognize the message because the SRR bit in the message header is not being set. I believe that the CAN Specification states that the SRR and the IDE bits must be set (recessive) in extended can messages.

Powervision V 2.7.10319
PV450
Windows 7
See attached configuration and monitor the message header for 0x0CFF7FF2 to observe the SRR bit.

Thanks,
John

Hi John,

We have not had issues with other devices not receiving messages from our displays because of the CAN bits, SRR and IDE. This is something new to us and we need some more information about the modules/ECMs/devices that should be receiving the messages from the display and the messages the devices expect. If it is proprietary and you don't want to post specifics here, you are welcome to send it to my email or use a private message.

The bits you are referencing are not controlled in the configuration space and controlled in the embedded part, so we will need to involve some of the developers with this issue. Any additional information you might have, logs, etc., will be most helpful to troubleshoot the problem you are having. If the logs are in a csv format, we can look at them with our tool.

How are the devices responding to what is being sent? What are you using to sniff the network? Do you have a sequence of events that you need to follow?

We have found that in most cases, the ECMs/devices do not listen to messages from the displays because they expect the message from a particular address or the display needs to use a message with the PDU Specific Field with the destination address of the receiver.

We will continue to gather information also about this until we receive your information. We are anxious to find the root of the problem.

Thanks!

Thanks for looking into this for me. I discovered this issue a few months ago when building a demo for one of our Fan Control products (EMC-6) that receives inputs over the J1939 Bus (engine, transmission etc.). I was in a hurry to meet a deadline so I had our software engineer remove the filter for the SRR bit so that I could continue developing. Consequently, I am just now getting around to corresponding with you about it. I will attach the current configuration version of the demo for you to look at through your private email as this belongs to a customer. Setting the SRR bit is important because it ensures that standard CAN messages will have priority over extended CAN messages on systems that are running dual configurations.
Now that I am digging into this again, I believe I misled you when I told you that I created the PGN in the library. Actually, because I needed to control the transmitted source addresses to fool my controller into thinking that the display was an engine, transmission and a hydraulic system, I configured the messages as free form messages. In the configuration they are named, EEC1_Tx, ET1_Tx, IC1_Tx, TF_Tx, VF_Tx, FE_L and Hyd_State. When I first ran the display configuration, I could see the transmitted messages on my PCAN software but the Fan Controller did not detect them. To troubleshoot this, we had to use a debugger connected to our EMC-6 and step through the receive buffers to identify what was happening. Doing this, we discovered that the SRR bit was dominant (reset to 0) coming out of the display.
The following is an excerpt from Microchips Reference Manual for the microprocessor that we are using in this case.
21.2.2 Extended Data Frame
The extended data frame begins with an SOF bit followed by a 31-bit Arbitration field as
illustrated in Figure 21-5. The Arbitration field in an extended data frame contains 29-bit identifier
in two fields separated by a Substitute Remote Request bit (SRR) and an IDE bit. The SRR bit
determines if the message is a remote frame (SRR = 1 for extended data frames). The IDE bit
indicates the data frame type. For the extended data frame, IDE = 1.
The extended data frame Control field consists of seven bits. The first bit is the RTR. For the
extended data frame, RTR = 0. The next two bits, RB1, and RB0, are reserved bits that are in
the dominant state (logic level ‘0’). The last four bits in the Control field are the DLC, which
specifies the number of data bytes present in the message.
The remaining fields in an extended data frame are identical to a standard data frame.

In this example, we can see that for extended frame messages (J1939), both the SRR and IDE bits should be recessive, (set to 1). I will attach this datasheet so you don’t have to look for it.

Unfortunately, I don’t have any logs that I can send you because my logger does not record these bits in the message header. I use a PCAN to USB Dongle to connect my PC to the bus and PCAN Explorer to monitor the bus on my PC. Our Controller Products connect directly to the bus and we communicate to them using custom GUIs developed for each product. Because our GUIs are designed to be configured by casual users, we do not display or record that level of detail for message headers either.

Thank you again and please let me know if there is any other information that I can provide you with that may help.

This dominant SRR bit issue also affected us when interfacing with a Motec PDM. It was puzzling as to why seemingly identical messages were being ignored. Searching the Murphy forums uncovered this relevant thread, but no apparent resolution. For those who may not have realised, this issue has now been addressed in PowerVision 2.7 Patch 4 Release, presumably as a result of the initial post.