From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Automotive and Embedded Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

J1939 Transport Protocol NI-CAN

Are there any examples available for how to deal with multipacket J1939 CAN messages as per SAE J1939-21 5.10.3? I need to be able to read and the DM1 message in extended J1939.
0 Kudos
Message 1 of 8
(17,532 Views)

Hi,

I found an example for a multipacket transmission on the web and you can find it attached to this post. on page 17 and 18 it is described how to send the multiple packet messages. You could use the frame api or the channel api which brings allready J1939 ID support in MAX to create the frame content.

DirkW

0 Kudos
Message 2 of 8
(17,516 Views)
DirkW

I have seen this example posted many times to explain the multi-packet message. 

Am I reading this incorrect or are there a typos in this document?

on page 17 in the PGN Hex box there is 00ECFF and in the  PGN box is 60416 but that number converted to hex is EC00
also on page 17 60160 is incorrectly converted to EBFF instead of EB00

on page 18 the PGN part of the ID number is ECFF which computes to 60671 which i think should be EC00
and 00EBFF i think should be 00EB00

According to  J1939-21 document 60416 or 00EC00 is the TP.CM message instead of the examples 00ECFF
and 60160 is the TP.DT instead of the examples 00EBFF

am I correct or am I missing something ?





Message Edited by James R on 02-22-2008 01:31 PM
- James

Using LV 2012 on Windows 7 64 bit
0 Kudos
Message 3 of 8
(16,932 Views)

Good catch.

My guess is that this 00ECFF is the PGN and has the source address added already. Besides that it is shown LSB first. So if the source address is FF and the PGN is 0xEC00 that translates to 0x00ECFF.

The same is true for the other PGNs: 0xEB00 converts to 0x00EBFF with source address FF and LSB first.

DirkW

0 Kudos
Message 4 of 8
(16,901 Views)

Hi,

Would it be possible to share the code you have developed for multiframe message(BAM and TP.DT)

If not,please give a brief on the same

0 Kudos
Message 5 of 8
(16,441 Views)

If you are trying to read active DTC codes, and you have more than one DTC on the node you are communicating with, it will want to send you a BAM, prior to the spew of packets holding the array of DTCs.

 

I do not know if BAM messaging or TP is worked into the example J1939 driver provided as an example by NI.... if not, you could easily get the SAE spec and add code to their example.

  

DMC recently developed a set of J1939 protocol drivers for LabVIEW which are based on the NI-CAN channel API.  The drivers are written in LabVIEW just like the example, but provide functions at a layer above the base CAN channel API layer.  This allows the simultaneous capture of data from both J1939 packets which are simple broadcast CAN frames, or more complex transport using BAM, including extended data frames.

 

Their development was not easy, but definately do-able with some extra programming time.

0 Kudos
Message 6 of 8
(13,110 Views)

Correct link for J1939 protocol drivers for LabVIEW which are based on the NI-CAN channel API. Smiley Happy

0 Kudos
Message 7 of 8
(13,106 Views)

In SAE J1939-21 Sec. 5.10.4 Figure 16 on p. 35

is says:

PDU specified field: Destination Address (Global (DA = 255) for TP.CM.BAM data transfers) (Global not allowed for RTS/CTS data transfers)

Since 0xEC < 0xF0 (240) the PDU specified field is a destination address instead of a Group Extension.

The Destination address of 0xFF (255) means Global.

 

I would guess the original j1939 message has a PDU Format >= 0xF0 (240)

otherwise the 0xFF would be the Destination address you provided.

0 Kudos
Message 8 of 8
(10,447 Views)