USB-8473 + NICAN not able to request data through J1939

[Cranky]

I'm trying to get some basic ECU data logging via CAN, but I can't get any response to requests. I'm using a USB-8473, NI-CAN (v2.7.3f2) Frame API and LabVIEW 2011 SP1.

I think the problem is in my formatting of the 8-byte data packet, mostly because I can listen to the bus and get some kind of data. I've looked at 5 or 6 sources for information on J1939 (ISO-TP) and I think I understand how to format the data, but I can't get a response when I send a request.

For example, request engine rpm by putting the following in to an u8-bit array and connecting that to the Data terminal of the ncWriteNet:

    0x02 0x01 0x0C

The DataLength should be passed 3--since there are three bytes of interest in the data array--the ArbitrationId is 0x07DF and the response should come back with ArbitrationId 0x07E8. No response on 0x07E8. I've even tried padding the data array with 0x00, 0x55 and 0xFF.

I'm really stumped. Any help you could provide would be appreciated.

[Cranky]

Minor update: I was able to get some of the PIDs to work and return sensible results (0x0C), but others were not successful (0x4111, 0x0641). The trick was to just force the data length to 8, which most likely just pads out the data. I have the default data value set to 0x55, and that seems to work. Some of the replies should be single bytes (0x4111) but the first response byte is 0x10. Perhaps I need a different mode?

[JB]

NI made an example for J1939 communication. This could be a good starting point for your application.

One important point is to set the 30th bit of the ID to 1 (OR with 0x20000000) because it is used by NI's can interfaces to identify extended or standard arbitration ID.

See this discussion or this KB for more details.

[Cranky]

JB - As far as I know, the ArbID's are all standard. The sample application seems very robust, and would make a good code base for a commercial product. In my case, I'm looking at this as a quick and dirty alternative to installing dedicated sensors and gauges while I install some new hardware--specifically, air/fuel ratio and intake temperature--and reading any DTCs that are thrown.

[JB]

As you can see here, the J1939 protocol uses extended IDs. The format of the 29-bit ID is described in details in the documentation of NI's example ("J1939 Message Construction" on page 2).

[jh99]

I get 0x10 also.

It is a Control Byte for the 0xEC00 message.  (Note: the 00 is replace with DA Destanation address you gave it since EC < FO (240) this isn't a broadcast message so the 2nd byte is DA and not Group Extension)

It happens when I send a message that isn't a BAM (BAM's send 0x20 for the Control Byte)

Then I get a 2nd message that starts with 0x20 (32) for the Control Byte. Then the EC00 will have 00 as FF

which means Global.

Anyway.

http://www.simmasoftware.com/j1939-presentation.pdf

is a good place and helped me.

p. 35 is the RTS message that has 0x10 (16) in the 1st Data byte

Also Section 7 Figure 6 in

http://www.ni.com/example/31215/en/

at the top

shows 0x10 (16) comming in as a RTS message.

TP.CM_RTS: Control Byte(16), Bytes to Send (27),

Total Packets(4), 255, PGN(65259)

Control Byte(16)       - Byte(s) 1    10

Bytes to send (27)    - Byte(s) 2-3 1B 00 (LSD --- MSD)

Total Packets(4)       - Byte(s) 4     04

255                           - Byte(s) 5     FF (Max number of packets for RTS/CTS Message in J1939-21 p. 32, 33

     Maximum Number of Packets: 2 to 255 (1byte), zero through 1 are not allowed

     Maximum number of packets that can be sent in response to one CTS, 0xFF indicates that no limit exists

     for the originator.  255 * 7 => 1785 which is the max length for J1939.  The 1st byte in the data for multiple

     packets is used for a Sequence number so even though it is in the Data[0] element the elements [1] - [7]

     are the only real data areas.

PGN(65259)            - Byte(3) 6-8  EB FE 00   LSD...MSD => MSD...LSD 0x00FEEB (65259)

I think you have to send a CTS

see p. 36 in the 1st document

or

see Section 7 Figure 6 in the 2nd document above.

(the 2nd arrow pointing from Right to Left with TP.CM_CTS: ... in it)

I'm trying to get this CTS working in a "c" program but am not having any luck.

I think I need to assign DA (destination address) to my CAN0 and CAN1 that I am using.

and configure the ncWrite with

a EC00 (where 00 is my AA Destination Address)

ie 1CECAABB

1C is 111 priority 7, 0 EDP, 0 DP

EC is the EC00 TP Connection Management

AA is the Destination Address in my case

BB is the Source Address in my case

but I don't know where to get a good example.

All the examples that use ncWrite in

C:\Users\Public\Documents\National Instruments\NI-CAN\Examples\MS Visual C\Frame API examples

use a object

and and id=5.

I think the id has something to do with CAN0::STD5

which would be CAN0::XTD5

I think the STD is for 11 bit CAN

and XTD is for 29 bit CAN

I don't know if the id 5 has anything to do with the DA, SA addresses though.

Also, the object that is used

NCTYPE_CAN_FRAME

has

.IsRemote

.ArbitrationID = 5 | 0x20000000

and I would think I would need to put 1cECAABB in this.

so the message that is going out would

have a priority, EDP, DP, PGN format, DA, SA

but I didn't see that anywhere in any of the examples.

I think they need an example for RTS/CTS for PGN formats < 0xF0 (240)

I get the RTS message

then I get a Connection Abort Message (Control ID FF)

and I think that is because I don't send a CTS message within 200 MS.

If you find anything about this please let me know also.

Thanks