How do I read the larger than 8 byte messages from a NMEA 2000 databus using XNET?

[VPEA]

I am currently reading data from a Garmin GPS19x NMEA 2000 with CAN connection using a NI 9862 in a NI 9178 cDAQ chassis.  I have the dbc file and have generated a session with some message groups of interest.  However, only the message groups with no more than 8 bytes (DLC) are visible in the session setup wizard.   Additional messages of interest have the DLC set to numbers greater than 8, one of interest is set to 51.  Reading through some information on NI.com, LabView does not support CAN message groups of greater than 8 bytes.  The information further says the messages must be broken into smaller groups. 

Does anyone know how to break the messages into smaller groups or Does anyone have code they are willing to share where this constraint is solved?

Thank you,

[Taki1999]

http://en.wikipedia.org/wiki/NMEA_2000

"

The Fast Packet protocol defined in NMEA 2000 provides a means to stream up to 223 bytes of data, with the advantage that each frame retains the parameter group identity and priority. The first frame transmitted uses 2 bytes to identify sequential Fast Packet parameter groups and sequential frames within a single parameter group transmission. The first byte contains a sequence counter to distinguish consecutive transmission of the same parameter groups and a frame counter set to frame zero. The second byte in the first frame identifies the total size of the parameter group to follow. Successive frames use just single data byte for the sequence counter and the frame counter. Because many of the NMEA 2000 parameter groups exceed 8 bytes but do not require the 1,785-byte capacity of multi-packet, the default method of transmitting multi-frame parameter groups in NMEA 2000 is using the Fast Packet protocol.

Regardless of which protocol is used, multi-frame parameter groups are sent on a frame-by-frame basis and may be interspersed with other higher priority parameter groups using either protocol, or even single- frame parameter groups. Each device is responsible for reassembling the parameter group once all the frames for the parameter group are transmitted."

[VPEA]

Thank you for the response and interesting information. 

How do I program LabView to break up the frames when it does not recognize any frames over 8 bytes?

[Taki1999]

You'll have to program in the parsing.

Read the first 2 bytes of the first incoming frame. The 1st byte is your sequence counter/identifier and the second byte should be the number of packets to follow.

On each subsequent byte, check for the sequence identifier in the first byte and add the remaining bytes to your parameter.

I haven't worked with this protocol before so it's unclear to me how "successive frames use just single data byte for the sequence counter and the frame counter" works.

[maks_s · Accepted solution]

First byte in each subsequent frame is a frame counter, so only 7 bytes in each subsequent frame used for data transferring.

A am exactly in process of understanding the proper Fast-Packet working.

Here is an example of some high level protocol data, which placed into NMEA2000 message (PGN130820) and that NMEA message transferred in 4 CAN frames with using fast-Packet.

E0 17 A3 99 04 80 05 02 

E1 00 01 00 00 00 07 00
E2 00 00 D0 84 00 00 5E
E3 12 00 00 FF FF FF FF

What we have here?

E0.. E3 - packet identifiers, where E is a Sequence Identifier (note1: it is the same in all sequence frames) and 0..3 are the identifiers of frames within Fast Packet sequence.

17 represent the amount of data to send.

Note2: the Sequence Identifier occupied only 3 bytes (mask: data[0] & 0xE0), and sequence item number occupied 5 bytes (mask data[0] & 0x1F).

So finally we have our 223 bytes as max data length to send through Fast Packet: 1F*7bytes=217 bytes + 6 bytes (first frame) = 223.

Trailing bytes filled with FF - I don't know yet, if this is the fast-packet requirement or just 3rd party CAN library feature.

Hope it helps.