I have had ongoing issues getting the transmit device to work on any CAN port, and have not yet been successfull. I need to figure out if I am doing something incorrectly, or if there is a bug. Initially on Port A, I would see a CAN message be transmitted, but with a Dlc of 0 and no data. I worked around this by making all of the messages FreeForm and not using the transmit device at all.

I am now again tryint to use the transmit device, but on Port D. I have tried letting the configurator create a transmit variable for me, of which I use a calculation event fired by state machine and 50ms timer to populate the variable from port A J1939 data (same SPN). I have also tried directly assigning the port A J1939 variable to the transmit device. In both cases, the result is the same. No message at all is transmitted. At display startup, the display is transmitting only 2 messages, both are for node address claim; after that, there is nothing.

Does the transmit device need to have all SPNs linked to it for a PGN in order to work?

Hello mbowdich,

I have a few questions to duplicate the situation here and diagnose the problem.

What unit are you using? PV750?
What version of the software? 2.2?
Did you define all 8 bytes of the PGN when you tried using the transmit device?
What is the size of the parameters? Do they use partial bytes?
When you use port D do you supply it's own power to port D?

If you have other relevant information that will be helpful too.

Thank you,

ksaenz

PV750
Application 2.2.10022
OS 2.2.10015
Bootloader 2.2.10010
PV Configuration Studio 2.2.1052

I am trying to transmit PGN 61444 EEC1. All 8 bytes are defined in the database. I have tried transmitting only SPN 190 engine speed, as well as all of the SPNs. No difference.

I am transmitting information coming in on the same PGN from port A. I have tried direct mapping and using a state machine to copy the data from the incoming variable to a transmit variable. No difference.

Yes, power is applied to the port. If power was not applied to the port, then I would not have seen the AC messages. I can also transmit a FFCAN message with no problem.

Check with Luke Strong, as there are a couple of other issues he is checking and he has a copy of the configuration.

Hi mbowdich,

When you add a parameter to the Transmit device, make sure of two things.
1. Database page - Ensure that the rate for the PGN that you are transmitting is not zero.
2. If you are selecting auto create for the added parameter, the new variable must be written to. If you are mapping an existing variable, it should be ok.

Attached is a 750 config that may explain it better.

I added two parameters to Port 1 Transmit Device.
Actual Engine Torque (PGN 61444) and Accelerator Pedal Position 1 (PGN 61443).
Both of these have the Torque that is read on the Engine Device mapped to them.
They will rebroadcast the Torque with a Source Address of 242.
Note: PGN 61443 will only transmit when the values are within its specified ranges.

Port 2 transmits the auto created variable J1939 Transmit Actual Engine Torque.
This value is controlled with the pushbuttons on the device.
Good Luck!

John Morgan
Test Engineer
FW Murphy

Unfortunately, I am traveling currently and do not have access to a display to play with this configuration for about a week. I have looked at it in the configuration tool, and have some comments / questions.

Did you actually monitor the bus with a CAN analyzer to verify the messages? If this indeed did work, it should not. J1939 specificly prohibits re-transmission of recieved data using the same SPN on the same segment. (J1939-71 5.1.2)

My goal is to repeat data from port A to Port D directly. I have configured this a couple of differnt ways, both writing to variables and by direct mapping and it has not succeeded. I just recieved a call from Jeff in service today who had spoken to Kristian who has been working with my configuration. The word I recieved back today is that tests showed that if an SPN is assigned to receive, then it is disabled from transmitting, even on another port. If an SPN is selected that is not configured as a reciever, then it transmits properly.

The information supplied by John Morgan is correct. The rate is set to 0 by default for 61444, this disables the transmit. If the rate is set to other than 0 the transmit function will work.

I took a look at the copy of the config that Luke Strong had, the rate was set to 0, when the value is changed, the messages transmit on port D.

Keep in mind that the values must be valid for it to work.

Interesting, because I changed it from 0 after John's post and it still did not work. Some of the SPNs were invalid, sothis is likely the case, but invalid values should still transmit, just as 1s for each bit (FF for byte). This was reported as a bug some time ago (Boyce has been looking into it since the beginning of December along with the Modbus crashing when data is invalid). Repeating the same data back out the same port it came in on should be prohibited.

The setting of the speed and priority in the dtabase needs to be added to the documentation, as it conflicts with this right now. Right now, the documentation says to set requested PGNs to a speed of 0, it does not mention anything about variable transmission rate PGNs (EEC1 is set to 0 by default in the Murphy standard config), and it also states that priority does nothing. Is this true, or does the priority value get transmitted correctly? If it does nothing as the documentation states, what priority do the PGNs transmit with?

I have had a chance to look at this, and it still does not entirely work. It appears that the transmitter has a problem with SPNs that are not whole bytes. This is the same problem I had last year.

Right now, I have several 2 bit SPNs in the transmit device. They share the same PGN. Right now, on the bus, the PGN is transmitted with a DLc of 0. The PGN is being broadcast, but with no data.

See attached configuration sample.

Hi mbowdich,

I made a couple of changes to the config that you sent. In the Environment Setup, under the Transmit Device, I deselected the Auto Create buttons and mapped the selected variables to the ones you added (TEST and TEST 2). Then, in the J1939 database, I changed the TEST SPN to Byte Length = 1, Bit Length = 0. Now both SPNs transmit correctly. Attached is the modified config.

Thanks,
John Morgan
Software Test Engineer,
FW Murphy

1) With the change from the auto-created variable, are you saying that the auto-create does not work correctly?
2) Your solution of changing the test SPN to 1 byte causes other issues. First, it is not a 1 byte long SPN. Second, it now prevents me from recieving this PGN correctly in the system from other devices, as the database will now always place all 8 bits into the J1939.device.Test variable when recieving.


For example, if I add the mappings for both SPNs to the Transmission device and then send data from node 3, the variable J1939.Transmission.Test never to 1. With the current definition of this test PGN, the only valid data for byte 1 is from 240 (bin 1111 0000) to 255 (1111 1111). Since a value of 241 (bin 1111 0001) is greater than the value data range for SPN Test (0-1), the variable is always invalid.

This simple example was intended to show a controlled situation which it fails to function. It becomes an even larger issue when working with J1939 standard PGNs and SPNs, as those have defined attributes. The conclusion is that it still does not work correctly and the only solution I have right now is to continue to process transmits with FreeFormCAN.

Hi mbowdich,

A bug has been entered into the system regarding the DLC=0 when SPNs are less than 1 byte. It should be resolved in the next release.

John Morgan
Software Test Engineer,
FW Murphy