UM-0086-A2
CANgate User’s Manual
Page 30
Example
J1939 PGN 65254 may be used to request the current time setting from an ECU. This PGN contains separate fields for
hours, minutes and seconds. It is important that this PGN be queried using a single request, otherwise the time may roll over
to the next minute/hour between requests, leading to an incorrect reading.
The following group of slot definitions will, when polled (using
RP 1 3
), return the current time in hh:mm:ss format.
BEGIN
1 RQSTJ 1 65254 3 3 FORMAT "%02d:" ' hours
2 RQSTJ 1 65254 2 2 FORMAT "%02d:" ' minutes
3 RQSTJ 1 65254 1 1 FORMAT .25 "%0.f\n" ' seconds
END
Sending the following slot #0 definitions in quick succession would have the same effect:
RQSTJ 1 65254 3 3 FORMAT "%02d:"; RP
RQSTJ 1 65254 2 2 FORMAT "%02d:"; RP
RQSTJ 1 65254 1 1 FORMAT .25 "%0.f\n"; RP
Multi-Packet J1939 Messages
An ECU on a J1939 network may periodically broadcast
multi-packet
messages for one or more PGNs. These messages
are used when the PGN contains more than 8 bytes of data. A message consists of a header CAN frame (containing the
PGN number and message length), followed by one or more CAN frames, each containing up to 7 bytes of data.
It is possible for two or more broadcast messages to overlap, in which case some or all of their constituent CAN frames will
be interleaved. CANgate can track a certain number of simultaneous multi-packet messages. Be aware of the following
limitations:
Only
one RECVJ slot can reference a data field of size greater than 8 bytes.
Multiple RECVJ slots can reference data fields up to 8 bytes in size within a multi-packet message.
If there are RECVJ slots which reference data fields (up to 8 bytes) from three or more different multi-packet PGNs
then this will work provided that the ECU does not transmit more than two of these PGNs at the same time.
There are no restrictions for RQST/RQSTJ slots, because only one request can be active at any one time.
Terminal Control
The following example is intended to be used with an ANSI/VT100 terminal or emulator. Two data values are extracted from
received CAN messages with ID 0x212, and one from ID 0x444 messages. These values are displayed at particular
row/column positions on the terminal (using the ANSI
ESC
[
row
;
col
H
sequence), and are then updated once per second.
CONNECT 2 250
BEGIN
1 RECV 2 0x212 1 3 1000 FORMAT "\027[1;10HEngine Speed: %6f rpm"
2 RECV 2 0x212 4 5 1000 FORMAT "\027[2;10H Temp: %6.1f degC"
3 RECV 2 0x444 1 3 1000 FORMAT "\027[3;10H Gear: %3d"
END
This should display the data on the terminal as follows:
Engine speed: 2310 rpm
Temp: 39.2 degC
Gear: 4
KWP2000/OBD-II/ISO-14230 Requests
Keyword Protocol 2000
(KWP2000) is a widely used poll-response protocol that allows diagnostic equipment to query and
control ECUs on an automotive network.
As discussed in
, the basic structure of KWP2000 is defined in ISO 14230-3. This standard
defines various request messages, each of which consists of a single byte
service identifier
, or
mode byte
, usually
followed by a number of parameters. Reply messages also begin with a mode byte which is derived from the mode byte of
the request.
KWP2000 modes 0x00-0x0F are reserved for standardised
legislated OBD
(on board diagnostics)
functions, and are
defined in SAE J1979 / ISO-15031. Modes 0x10-0x3F are functionally defined by ISO-14230-3, but the details of parameters
and response data format tend to be manufacturer specific.
Each ECU parameter that can be requested or set is identified by a
PID
(parameter identifier) code. For the legislated OBD
functions, the PID codes are standardised; for the ISO-14230-3 functions the PID definitions are manufacturer specific.
Example
In this example, the engine speed is requested. From ISO-15031 (or the Appendix,
, we know
that the Engine RPM is PID 0x0C, and the returned value has a resolution of 0.25 rpm and an offset of 0. KWP2000 mode
0x01 indicates a request for the current value of a PID. The complete request message therefore contains two bytes: the
