J1939 Add-on Feedback - not getting default values for message - instead getting 0s

[JonkunHHK]

Hi Dan,

Massive appreciation for your J1939 Addon custom device. I've got a HIL project lately where the ECU employed J1939 as the communication protocol. I'm using VS 2020 and NI XNET 20.5 as part of my HIL environment. Since I have three J1939 frames with more than 8 bytes to receive in VS, I found that native J1939 support in VS 2020 is kinda flawed because it just doesn't populate frame data and output zeros when using NI XNET directly in VS.  After then I downloaded your latest version of J1939 Addon (2020.4.xxxx) and replicated the frame mappings in the custom device.

The custom device worked well for frames with less than 8 bytes as expected. However, when I configured it to receive those three larger frames with an identical .dbc file, it didn't work. Also, I used a Vector CANape to monitor the bus and confirmed the ECU had successfully sent an RTS frame. It seemed like the custom device failed to automatically reply with a CTS frame.

Moreover, I tried to use two J1939 Addon instances, each of which was configured with an individual NI XNET CAN port. I configured CAN1 to simulate the ECU sending those three large frames and CAN2 to receive them(with SA = 0xF4, DA = 0x56 settings).

Eventually, I compared the RTS frame data sent by the ECU and sent by the J1939 Addon. There's something different:

The original RTS frame send by the ECU is : (Hex) 10 | 31 |00 07| FF| 00 02 00        ID:0x1CEC56F4

The simulated RTS frame send by J1939 AddOn is: (Hex) 10 | 31 | 00 07 | FF | 56 02 00       ID:0x1CEC56F4

As such, CAN2 still couldn't reply a CTS frame to CAN1. I'm sure I unchecked the ' Include Dest Address in PGN' block when configuring J1939 AddOn, yet the CANape indicated that the PGNs aren't the same.  One of the J1939 frames I intended to receive has an ID 0x180256F4 with PGN 0200(H).  It looks like the receiving issue arouse from unmatching PGN and somehow VS included DA in the PGN.

Apology for the long essay, I'm kinda confused with where I got into. Do you have any thoughts about the issues described above?

Also, any ideas and help from the community would be welcomed and much appreciated.

regards,

Jonkun

[JonkunHHK]

Hi everyone,

I think I've got a clue of where I went wrong. I configured receiving and transmitting frames all within the monitor node in the J1939 Addon custom device. It looks like this node is only for troubleshooting purposes similar to the bus monitor in NI MAX. I've reconfigured all my frame settings under the Simulate tab in the CD with correct J1939 addressing. Then the CD worked perfectly when using one CAN port to transmit frames and the other to receive. Besides, I could still use the native NI XNET CAN port tabs when configuring with an identical baud rate and .dbc file.

[SunilLengare]

Hello Daniel

I am using j1939-addon-2018_4.2.0+018, with Veristand 2018 SP1 and have added one 14 byte message under Custom Devices> J1939 Add on>Simulate>Device (address 0x05)>Cyclic>J1939_Message, and have assigned some default values in database, but when i tried to observe in Vector CANape trace window ( I have connected PXIe 8510 to Vector VN1630) i dont see default values instead i see 0s? is it like that only? or i m missing something??

[NathanJD]

Did you add those signals to your system definition?  When I first started using this, I was also confused because when you add the signal to the system definition, it sets the default value to 0.  It will only use the database's default if you do not add the signal to the system definition.

At least this is how I remember it.

[SunilLengare]

Actually when we add frame to system definition, all signals any way gets added - i dont need to do anything separately. 

Ok i got it, for each signal its showing default data in system explorer (which i failed to notice earlier) where i can give default data though its not taking it from data base but still it works for me