CAN Application Support

CANopen Implementation

This section shows how to send joystick data using CANopen.

When integrated with the SRC Pro, the EPC presents itself on the CANopen network as a CiA 301/401‑1/401‑2 compliant device.

Warning:

The SRC Pro commands made available on CAN network are not safety certified, therefore you must assess the suitability of using this data in safety relevant applications.

At present, while the integration is intended to be compatible with a CANopen compliant network, the full capability set described in the standards is not yet implemented.

The following table provides an overview of the different types of CANopen joystick data.

Table 1. Table 14 CANopen
Description	Direction	Frequency
Joystick Data – Buttons (See Table 6-2, “TPDO1 Buttons,` on page 6-3).	Transmit	~20 Hz (buttons actively pressed.) ~4 Hz (inactive & buttons not pressed)
Joystick Data - Thumbstick Axes (See Table 6-3, “TPDO2 Thumbstick Axes,” on page 6-3).	Transmit	~20 Hz
Joystick Data - Trigger Axes (See Table 6-4, “TPDO3 Trigger Axes,” on page 6-4).	Transmit	~20 Hz

Joystick and Button Data Representation

The device implements a CiA 401 Part 2 compatible representation of a multi-axis joystick. It presents as a Device Type (OD Entry 0x1000) as 0x01 (i.e., “Joystick with digital inputs without digital outputs”). See CiA 401 Part 2 Section 10.2 “Device type”. As per the standard’s representation, the device uses:

TPDO1 (Transmit Process Data Object) protocol to convey the Boolean values of the Safe Remote Control Pro’s buttons.
TPDO2 to convey the analog values of the four axes on the face of the Safe Remote Control Pro.
TPDO3 to convey the analog values of the two triggers at the rear of the Safe Remote Control Pro.

The following table lists the TPDO1 (0x180 + Node ID — default Node ID is 3) buttons. TPDO1 conveys the Boolean values of the Safe Remote Control Pro’s buttons.

Each sub index is an 8-bit unsigned integer (UINT8)

The following table shows the TPDO1 buttons.

Table 2. Table 15 TPDO1 Buttons
Object Dictionary Index (hex)	Sub-Index	Bit	Name	Usage
60.00	01	00, 01, 02	memory x-axis, memory y-axis, memory z-axis	Unused - Fixed 0
60.00	01	03, 04, 05, 06, 07	ms	Unused
60.00	02	00	b1	Down
60.00	02	01	b2	Right
60.00	02	02	b3	Up
60.00	02	03	b4	Left
60.00	02	04	b5	Pause
60.00	02	05, 06, 07	b6, b7, b8	Unused
60.00	03	00	b9	1 Key
60.00	03	01	b10	2 Key
60.00	03	02	b11	3 Key
60.00	03	03	b12	4 Key
60.00	03	04	b13	Menu
60.00	03	05, 06, 07	b14, b15, b16	Unused

The following table lists the TPDO2 (0x280 + Node ID — default Node ID is 3) thumbstick axes. TPDO2 conveys the analog values of the four axes on the face of the Safe Remote Control Pro.

Each value is a full range 16-bit signed integer (int16) that produces a zero-value when the stick is at rest/centered. The axis shows a positive value when pushed up (Y) or right (X) and a negative value when pushed down (Y) or left (X).

Table 3. Table 16 TPDO2 thumbstick Axes
Object Dictionary Index (hex)	Sub-Index	Type	Usage
64.01	01	INT16	Left Stick X
64.01	02	INT16	Left Stick Y
64.01	03	INT16	Right Stick X
64.01	04	INT16	Right Stick Y

The following table lists the TPDO3 (0x380 + Node ID — default Node ID is 3) trigger axes. TPDO3 conveys the analog values of the two triggers at the rear of the Safe Remote Control Pro.

Each value is a full range 16-bit signed integer (int16) that produces a zero-value when the trigger is at rest/centered. The axis shows a positive value when pulled up and a negative value when pushed down.

Table 4. Table 17 TPDO3 Trigger Axes
Object Dictionary Index (hex)	Sub-Index	Type	Usage
64.01	05	INT16	Left Trigger
64.01	06	INT16	Right Trigger

CANopen Limitations

The device implementation currently lacks some CANopen standard functionality that you should be aware of:

Warning:

The data available on CANopen is not safety rated, therefore you should not use this data to perform safety functions.

The default bitrate of the CAN interface is 250000. You cannot adjust the bitrate through the CANopen NMT protocol but must do so by using FORT Manager or the FORT CLI Config Tool.
The default device Node ID is 3. You cannot change the device address through the CANopen NMT functionality, but must do so by using FORT Manager, which lets you set the node ID for each device in a configuration. For more information, see Configuring CAN with FORT Manager.

J1939 Implementation

The EPC’s CAN application supports sending and receiving messages using the J1939 protocol. The EPC uses the Emotas J1939 stack to provide the full functionality of the J1939 protocol.

Warning:

The data available on CAN J1939 is not safety rated, therefore you should not use this data to perform safety functions.

At present, while the integration is intended to be compatible with a J1939 compliant network, the full capability set described in the standards is not yet implemented. You can find a sample DBC (Database Container) file to download on the Customer Support Portal in the Endpoint Controller article.

The following table provides an overview of the different types of J1939 messages.

Table 5. Table 18 CAN J1939
PGN	PGN (Hex)	Description	Direction	Freq
	0xEEFF	Address Claiming	Transmit
64982	0xFDD6	Left Joystick - J1939 Basic Joystick Message 1	Transmit	~16 Hz
64983	0xFDD7	Left Joystick - J1939 Extended Joystick Message 1	Transmit	~16 Hz
64984	0xFDD8	Right Joystick - J1939 Basic Joystick Message 2	Transmit	~16 Hz
64985	0xFDD9	Right Joystick - J1939 Extended Joystick Message 2	Transmit	~16 Hz

Address Claiming

Both the EPC and NSC-Pro support the standard J1939 address claiming procedure (PGN 0xEE00). This allows multiple J1939 devices on the same CAN bus to negotiate unique source addresses without manual configuration.

The FORT Manufacturer Code is 1262 (decimal).

Table 6. Table 19 J1939 Address Claiming Message
PGN	Description	Direction	Freq
0xEE00 (60928)	Address Claiming	Transmit	On startup and on address conflict

Note:

The EPC and NSC-Pro will first attempt to claim the source address configured in their configuration file. If another device on the bus contests that address, the standard J1939 arbitration procedure determines which device wins.

Address claiming is a standard J1939 mechanism. For details of the arbitration procedure, refer to SAE J1939-81 (Network Management).

The source address used at runtime is the address that was successfully claimed. It appears as the low byte of the 29-bit CAN ID on every transmitted message.

Valid J1939 source addresses run from 0x00 to 0xFD (253). Addresses 0xFE and 0xFF are reserved by the J1939 standard and are never used as source addresses by FORT devices.

J1939 Approved Source List

The EPC and NSC-Pro respond only to CAN messages whose J1939 source address appears in a configured approved source list. This provides a basic layer of filtering against unintended commands from other devices sharing the bus.

The approved source list is optionally provided as part of the device configuration file. An empty list means all source addresses are approved.

You can specify source addresses with FORT Manager (see Configuring CAN with FORT Manager).

Valid approved source addresses are 0 to 253 (decimal).

Note:

In J1939:

Source address 254 is reserved as the NULL address (used during address claiming before an address is assigned).
Source address 255 is reserved as the global address (broadcast).

The approved source list affects which incoming messages the device will act on — for example, SRC-Pro Settings Messages (PGN 0xFF01) and Display Text Messages (PGN 0xFF02). It does not affect address claiming behavior or the messages the device transmits.

Left Joystick - J1939 Basic Joystick Message

The following table shows the basic message fields for the left joystick.

Table 7. Table 20 J1939 Left Joystick Basic Messages
Bytes	Bits	J1939 PGN 64982 Data field	Description
1	2 bits	00b: not in neutral position 01b: in neutral position 10b: error indicator 11b: NA	X-Axis neutral position status
	2 bits	00b: Not on negative side of Neutral 01b: On negative side of Neutral 10b: error indicator 11b: NA	X-Axis Lever Left Negative Position Status
	2 bits	00b: Not on Positive side of Neutral 01b: On Positive side of Neutral 10b: error indicator 11b: NA	X-Axis Lever Right Positive Position Status
1/2	10 bits	The position of the joystick in the relative motion of travel from the neutral position. Position value of 0 is Neutral and position value 1000 (100%) is the end of linear zone. Value of 1022 indicates an error has occurred.	X-Axis Position
3	2 bits	00b: not in neutral position 01b: in neutral position 10b: error indicator 11b: NA	Y-Axis neutral position status
	2 bits	00b: Not on negative side of Neutral 01b: On negative side of Neutral 10b: error indicator 11b: NA	Y-Axis Lever Left Negative Position Status
	2 bits	00b: Not on Positive side of Neutral 01b: On Positive side of Neutral 10b: error indicator 11b: NA	Y-Axis Lever Right Positive Position Status
3/4	10 bits	The position of the joystick in the relative motion of travel from the neutral position. Position value of 0 is Neutral and position value 1000 (100%) is the end of linear zone. Value of 1022 indicates an error has occurred.	Y-Axis Position
5	4 bits	Not used.	N/A
5	2 bits		Y-Axis Detent Position Status
5	2 bits		X-Axis Detent Position Status
6	2 bits	00b: Button not pressed 01b: Button pressed 10b: Error Indicator 11b: NA	Keypad button Left North has been pressed. As per J1939 DA it is Joystick button 4 (up arrow)
6	2 bits		Keypad button Left West has been pressed. As per J1939 DA it is Joystick button 3 (left arrow)
6	2 bits		Keypad button Pause has been pressed. As per J1939 DA it is Joystick button 2
6	2 bits		Joystick button Power has been pressed. As per J1939 DA it is Joystick button 1
7	2 bits	00b: Button not pressed 01b: Button pressed 10b: Error Indicator 11b: Not Available	Keypad button Right West has been pressed. As per J1939 DA it is Joystick button 8 (button 4 on device)
7	2 bits		Keypad button Menu has been pressed As per J1939 DA it is Joystick button 7
7	2 bits		Keypad button Left South has been pressed As per J1939 DA it is Joystick button 6 (down arrow)
7	2 bits		Keypad button Left East has been pressed. As per J1939 DA it is Joystick button 5 (right arrow)
8	2 bits	00b: Button not pressed 01b: Button pressed 10b: Error Indicator 11b: Not Available	Reserved As per J1939 DA it is Joystick button 12
8	2 bits		Keypad button Right South has been pressed As per J1939 DA it is Joystick button 11 (button 1 on device)
8	2 bits		Keypad button Right East has been pressed As per J1939 DA it is Joystick button 10 (button 2 on device)
8	2 bits		Keypad button Right North has been pressed As per J1939 DA it is Joystick button 9 (button 3 on device)

Left Joystick - J1939 Extended Joystick Message 1

The following table shows the J1939 extended message 1 for the left joystick.

Table 8. Table 21 J1939 Left Joystick Extended Message
Bytes	Bits	J1939 PGN 64983 Data field	Description
1	2 bits	00b: not in neutral position 01b: in neutral position 10b: error indicator 11b: NA	Z-axis neutral position status
	2 bits	00b: Not on negative side of Neutral 01b: On negative side of Neutral 10b: error indicator 11b: NA	Z-Axis Lever Left Negative Position Status
	2 bits	00b: Not on Positive side of Neutral 01b: On Positive side of Neutral 10b: error indicator 11b: NA	Z-Axis Lever Right Positive Position Status
1/2	10 bits	The position of the joystick in the relative motion of travel from the neutral position. Position value of 0 is Neutral and position value 1000 (100%) is the end of linear zone. Value of 1022 indicates an error has occurred.	Z-Axis Position

Right Joystick - J1939 Basic Joystick Message 2

Same as Left Joystick - J1939 Basic Joystick Message 1.

Right Joystick - J1939 Extended Joystick Message 2

Same as Left Joystick - J1939 Extended Joystick Message 1.

SRC Pro Control Messages

The EPC supports receiving messages that can change settings on a connected SRCP. If an SRCP is not connected though, any received commands are ignored.

Note:

The EPC filters messages to ensure that it does not incorrectly acknowledge IDs (CANopen) or PGNs (J1939) not meant for it.

SRCP control messages are received on CANopen via RPDO1 and RPDO2 as shown in the following tables:

Table 9. Table 22 RPDO1 (0x200 + Node ID) - SRC Pro Settings Message
Object Dictionary Index (hex)	Sub-Index	Type	Usage
20.00	01	Octet String (0x0000a) size - 8 bytes or 64 bits 0x40 bits	SRC Pro Setting Message

Table 10. Table 23 RPDO2 (0x300 + Node ID) - User Display Text String
Object Dictionary Index (hex)	Sub-Index	Type	Usage
20.01	01	Octet String (0x0000a) size - 8 bytes or 64 bits 0x40 bits	Display Text Data

SRC Pro control messages are received on J1939 via proprietary message PGNs.

Table 11. Table 24 CAN J1939 SRC Pro Settings Message
PGN	PGN (Hex)	Description	Direction	Freq
65281	0xFF01 (default)	SRC Pro Settings Command - J1939 Proprietary Message	Receive	N/A
65282	0xFF02 (default)	User Display Text String - J1939 Proprietary Message	Receive	N/A

Note:

You can change the default value by using this procedure in FORT Manager in case you have a crowded CAN bus with potential PGN conflicts on your system.

SRC Pro Settings Message

The EPC supports receiving an SRC Pro Settings message (from the equipment under control) to change settings on a connected Safe Remote Control Pro. This message is only supported for an EPC that is connected to a Safe Remote Control Pro.

CAUTION:

Vibration messages are rate limited to 1 message per 100 ms. Additional vibration messages received beyond the limit will be ignored.

The following table shows the SRC Pro Settings message format:

Table 12. Table 25 SRC Pro Settings Message Format
Byte Offset	Size	Description	Value
0	1	Setting Key	SRC Pro Setting to Change
1	4	Setting Value	Value of the setting (little endian)
5	3	Reserved for Future Use

The following table shows the Safe Remote Control Pro setting keys.

Table 13. Table 26 SRC Pro Setting Keys
Key	Name	Description	Minimum SRC Pro Version
1-9	Reserved
10	Left Motor Vibrate	1 = Vibrates the left motor for 100 ms	3.2.2
11	Right Motor Vibrate	1 = Vibrates the right motor for 100 ms	3.2.2
12	Both Motor Vibrate	1 = Vibrates both motors for 100 ms	3.2.2
99	Display Mode	0 = Default Display Mode 1 = User Text Display Mode (4 Lines)	3.2.2

SRC Pro User Display Text String Message

The EPC supports receiving an SRC Pro user display text message (from the EUC) to set the display text on the connected Safe Remote Control Pro when the Safe Remote Control Pro is in user-text mode. You can use the SRC Pro Settings message to change the display mode of the Safe Remote Control Pro.

This message is only supported when an EPC is connected to a Safe Remote Control Pro.

The User Display Text String message to the EPC allows updating the displayed text on the connected Safe Remote Control Pro when the Safe Remote Control Pro is in user text mode. The user string is built using three segments of six characters each to build an 18-character string.

CAUTION:

This message is rate limited and only 1 message can be received per 100 ms. Additional messages received beyond the limit will be ignored.

Table 14. Table 27 User Display Text Message Format
Byte Offset	Size	Description	Value
0	1	User Text Key	0-3
1	1	Segment	0-2
2	6	User Text String	6 ASCII Characters

The following keys are currently defined by the system for user strings:

Table 15. Table 28 User String Keys
Key	Name	Description
0	Custom Display Text Line 1	In display mode 1, this is the first line of custom text that is displayed.
1	Custom Display Text Line 2	In display mode 1, this is the second line of custom text that is displayed.
2	Custom Display Text Line 3	In display mode 1, this is the third line of custom text that is displayed.
3	Custom Display Text Line 4	In display mode 1, this is the fourth line of custom text that is displayed.

Note:

Custom display text travels over the machine's CAN bus as an ordinary control message. Do not use it for a person's name or other personal data. For more information, see Personal Data in FORT Manager.

Status Messages

Status messages use custom formats that remain the same between CANopen and J1939.

The following table shows the Object Dictionary definition of all CANopen EPC Status messages:

Table 16. Table 29 TPDO4: (0x480 + Node ID) - EPC Status Messages
Object Dictionary Index (hex)	Sub-Index	Data Type	Name
30.00	01	Octet String (0x0000a) size - 8 bytes or 64 bits 0x40 bits	EPC status messages

The following table shows the PGN for J1939 status messages.

Table 17. Table 30 J1939 EPC Status Messages
PGN	Description	Direction
65280 (0xFF00)	EPC status messages - J1939 Proprietary Message	Transmit

All EPC status messages use the same CANopen TPDO or J1939 PGN format and are differentiated by an ID field within the message data itself as shown in the following table:

Table 18. Table 31 Message Identifiers and Frequencies
Name	Identifier	Frequency	Notes
EPC Output Status 1	0	200 ms and on change of safety state
EPC Connected Device Latency	1	1 sec	Not currently implemented. Always returns the value 0xFFFF.
SRC Pro System Status	2	1s normally; 10s if no data received from SRCP for >= 5 seconds	Enabled when SRC Pro is connected; in a 2:1 configuration, this message is enabled.
ISM Connection Status	3	1 sec	Enabled only if ISM is configured.
WES Pro System Status	2	1s normally; 10s if no data received from WESP for >= 5 seconds	Enabled when WES Pro is connected; in a 2:1 configuration, SRC Pro System Status is enabled, not this message.
Radio Connection Status	3	1 sec	Enabled only if LRBLE is configured. In a 2:1 configuration, connection status will be for SRC Pro.

Note:

Table 31 Message Identifiers and Frequencies: Identifier Column

The SRC Pro and WES Pro System Status messages have the same ID, as do the ISM Connection Status and Radio Connection Status messages. The EPC determines which message to send based on the connected device type or radio type. In a 2:1 configuration, the EPC sends the SRC Pro System Status message and the Radio Connection Status is for the SRC Pro.

EPC Output Status 1 Message

The EPC transmits an output message to provide status for various EPC functionality. It uses the TPD04 protocol to transmit the message at a rate (trigger) of every 200 ms and upon status changes. The following table shows the status message format.

Table 19. Table 32 EPC Output Status 1
Byte Offset	Size	Description	Value
0	1	Message ID	Identifier for EPC Output Status 1 Message - 0x00
1	1	Status Sequence ID	8-bit Unsigned Integer that increments a sequence number to associate messages related to the EPC status to a single time
2	1	Output 1 State	Bits 3:0 - SMCU0 State Bits 7:4 - SMCU1 State 0000 - SAFETY_REQUESTED; cause is unspecified 0001 - SAFETY_NOT_REQUESTED 0010 - SAFETY_FAULT 0100 - Timeout; paired remote communication lost¹ 1000 - Safety from input request
3	1	Output 2 State	Same as Output 1 State
4	1	Output 3 State	Same as Output 1 State
5	1	Mode	Bits 3:0 - SMCU0 State Bits 7:4 - SMCU1 State 0000 - No Mode (Error State) 0001 - Supervised 0010 - Autonomous (Unsupervised) 0011 - Not Applicable (EPC to NSC Pairing)
6	1	Reserved	Reserved for future use
7	1	Reserved	Reserved for future use

EPC Connected Device Latency Message

Important:

This message was developed for future use but is not currently implemented for any FORT devices. It always returns the value 0xFFFF.

The rate (trigger) for this message is 1 second.

Table 20. Table 33 EPC Connected Device Latency
Byte Offset	Size	Description	Value
0	1		Identifier for EPC Connected Device Latency Message - 0x01
1	1	Status Sequence ID	Integer Incrementing sequence number to associate messages related to the EPC status to a single time
2	1	Care List Index	Index of the remote device (a separate value from the Device ID)
3	2	SMCU0 Measurement	16-bit latency measurement for this remote device, from Safety MCU 0
5	2	SMCU1 Measurement	16-bit latency measurement for this remote device, from Safety MCU 1
7	1	Reserved	0xFF

SRC Pro System Status Message

The rate (trigger) for this message is normally 1 second unless no data is received from the SRC Pro for 5 seconds or more, in which case it is 10 seconds.

Note:

This message has the same identifier as the WES Pro System Status message. The EPC determines whether to send this message or the WES Pro message, based on which device is connected to the EPC. In a 2:1 configuration, it sends the SRC Pro message.

Table 21. Table 34 SRC Pro System Status
Byte Offset	Size	Description	Value
0	1	Message ID	Identifier for SRCP System Status message - 0x02
1	1	Status Sequence ID	Integer Incrementing sequence number to associate messages related to the SRCP System Status to a single time
2	1	USB Connected	Bit Meanings Bit 7: 1 = USB connected, 0 = USB disconnected Bit 6: 1 = USB charging, 0 = USB not charging Bits 5:0: Reserved
3	1	Battery Percentage	Battery Percentage from 0 (Decimal)% to 100 (Decimal)%
4	1	Mode	Mode Values: 0x04: Local Mode - Device is not yet paired. 0x06: Remote Mode - Device is paired, but not yet sending button/joystick state. 0x09: Operational Mode - Device is paired, and is sending button/joystick state. 0x0A: Menu mode - Device is in its menu. If connected, it continues to output the joystick message but with all values set to 0 to guarantee that no motion will occur. 0x0B: Pause mode - Device is paused. If connected, it continues to output the joystick message but with all values set to 0 to guarantee that no motion will occur.
5	1	Cause of Pause	Value to indicate the reason that the SRC Pro is in Pause mode Pause Cause Values: 0: None 1: Manual pause 2: Free fall 3: Orientation 4: Inactivity
6	1	Reserved	0xFF
7	1	No message	Bit Encoding Bit 7: 1 = No status messages received for >= 5 seconds, information may be out of date. Bits 6:0: Reserved

WES Pro System Status Message

This message is enabled only when a WES Pro is connected to the EPC. The rate (trigger) for this message is normally 1 second unless no data is received from the WES Pro for 5 seconds or more, in which case it is 10 seconds.

Note:

This message has the same identifier as the SRC Pro System Status message. The EPC determines whether to send this message or the SRC Pro message, based on which device is connected to the EPC. In a 2:1 configuration, it sends the SRC Pro message.

Table 22. Table 35 WES Pro System Status
Byte Offset	Size	Description	Value
0	1	Message ID	Identifier for WES Pro System Status message - 0x02
1	1	Reserved	0x0
2	1	USB Connected	Bit Meanings Bit 7: 1 = USB connected, 0 = USB disconnected Bit 6: 1 = USB charging, 0 = USB not charging Bits 5:0: Reserved
3	1	Battery Percentage	Battery Percentage from 0 (Decimal)% to 100 (Decimal)%
4	1	Reserved	0x0
5	1	Reserved
6	1	Reserved	0x7F
7	1	Reserved	0x0

ISM Connection Status Message

The message rate (trigger) is 1 second but is enabled only when ISM is configured.

Note:

This message has the same identifier as the Radio Connection Status message. The EPC determines whether to send this message or the Radio Connection message, based on the radio type.

Table 23. Table 36 ISM Connection Status
Byte Offset	Size	Description	Value
0	1	Message ID	Identifier for ISM Connection Status Message - 0x03
1	1	Status Sequence ID	Integer Incrementing sequence number to associate messages related to the ISM Connection Status to a single time
2	1	RSSI Value	8-bit Signed Integer indicates the RSSI (Received Signal Strength Indicator) value which ranges between -120 (0x88) to +20 (0x14). The value is -128 (0x80) when ISM is configured but not in state.
3	1	Reserved	0xFF
4	1	Reserved	0xFF
5	1	Reserved	0xFF
6	1	Reserved	0xFF
7	1	Reserved	0xFF

Radio Connection Status Message

The message rate (trigger) is 1 second, but only enabled when long range bluetooth (LRBLE) is configured.

Note:

This message has the same identifier as the ISM Connection Status message. The EPC determines whether to send this message or the ISM Connection message, based on the radio type.

In a 2:1 configuration, connection status reports the SRC Pro link. This is the case even when both senders communicate over LRBLE, as in a Two-to-One over Long-Range Bluetooth: the RSSI value describes the SRC Pro's link to the receiver, not the EPC sender's link to the receiver.

Table 24. Table 37 Radio Connection Status
Byte Offset	Size	Description	Value
0	1	Message ID	Identifier for Radio Connection Status Message - 0x03
1	1	Status Sequence ID	Integer Incrementing sequence number to associate messages related to the Radio Connection Status to a single time
2	1	RSSI Value	8-bit Signed Integer indicates the RSSI (Received Signal Strength Indicator) value which ranges between -120 (0x88) to +20 (0x14). The value is -128 (0x80) when LRBLE is configured but not in state.
3	1	Reserved	0xFF
4	1	Reserved	0xFF
5	1	Reserved	0xFF
6	1	Reserved	0xFF
7	1	Reserved	0xFF

Peer Connection Status

Note:

This message is only transmitted by EPC devices in an EPC-EPC 1:1 set-up. NSC-Pro does not support it.

Purpose

PeerConnectionStatus is a compact paged snapshot message that reports the connection state for a window of peer slots in a single 8-byte frame. It answers the question: is each configured peer currently connected or disconnected?

CAN Frame Identifier

Table 25. Table 38 Peer Connection Status Frame Identifier
Field	Value
J1939 PGN	0xFF05 (65285)
Priority	4
Source Address	Configured address (default 0x00)
29-bit CAN ID (with source 0x00)	0x18FF0500
CANopen TPDO	TPDO7 — COB-ID `$NODEID+0x780`, OD object 0x3003
Direction	Transmit

Data source: the epc-peer-manager service tracks peer connectivity by monitoring CoAP heartbeats from remote peers and radio link state from the interface wrapper. The epc-can service subscribes to peer connection change events and encodes this message. Only configured peers (those in the peer list) are reported; unconfigured slots report Unknown_Unassigned.

Message Format

The message uses:

Byte 0 for Peer_Offset (page index).
2 bits per peer slot in bytes 1 to 7.

Peer_Offset is a page index, not a raw peer number. The first reported peer slot in a frame is 28 × Peer_Offset + 1 (1-based).

With 7 data bytes available for peer states, each frame carries 28 peer states.

Table 26. Table 39 Peer Connection Status Format
Byte	Field	Description
0	`Peer_Offset`	Page index (0 = peers 1–28, 1 = peers 29–56, etc.)
1	Peer states [1–4]	2 bits per peer (4 peers per byte)
2	Peer states [5–8]	2 bits per peer
3	Peer states [9–12]	2 bits per peer
4	Peer states [13–16]	2 bits per peer
5	Peer states [17–20]	2 bits per peer
6	Peer states [21–24]	2 bits per peer
7	Peer states [25–28]	2 bits per peer

Each 2-bit peer state encodes:

0=Unknown_Unassigned — slot not configured in the peer list
1=Connected — peer is connected and heartbeating normally
2=Disconnected — peer was configured but is no longer responding
3=Reserved

Bit Layout Within Each Byte

Within each status byte (bytes 1–7):

bits 1:0 = first peer in that group of four
bits 3:2 = second peer
bits 5:4 = third peer
bits 7:6 = fourth peer

Example

If Peer_Offset=1, the frame reports peer slots 29 to 56.

Suppose the first four peers in that window are:

peer 29 = Connected (01)
peer 30 = Disconnected (10)
peer 31 = Unknown/Unassigned (00)
peer 32 = Connected (01)

Then byte 1 = 0b_01_00_10_01 = 0x49.

Page Ranges

Table 27. Table 40 Peer Connection Status Page Ranges
Peer_Offset	Peer slots reported
0	1 to 28
1	29 to 56
2	57 to 84

The maximum configured care list size is 32 peers, so in practice only one page (Peer_Offset=0) is needed in current deployments. The paged format exists to scale gracefully if the peer count increases.

Tradeoffs of the paged snapshot approach:

Scales better to larger peer counts than a single frame per peer.
Keeps a simple connected/disconnected snapshot concept.
Requires multiple frames to build a full system view when more than 28 peers exist.
Should be transmitted at a lower rate as peer count increases, since more messages are needed to refresh the full peer set.

Relationship to Safety Events

PeerConnectionStatus is a snapshot of the current connectivity picture. It does not describe why a peer disconnected or what safety state change occurred.

For richer information about peer safety state transitions, see Safety Event Messages, which documents the Peer_Safety_Event message — J1939 PGN 0xFF03, CANopen TPDO5.

Safety Event Messages

Note:

Safety event messages are only transmitted by EPC devices in an EPC-EPC 1:1 set-up. NSC-Pro does not support them.

Two messages report safety state changes on the EPC. Both are available over J1939 and over CANopen; the table below gives the J1939 PGN for each, and the CAN frame table in each message's own section gives the CANopen TPDO.

Table 28. Table 41 Safety Event Messages
Message	PGN	29-bit CAN ID (source 0x00)	Purpose
`Peer_Safety_Event`	0xFF03 (65283)	0x08FF0300	Peer-related safety state from care list
`Local_Safety_Event`	0xFF04 (65284)	0x08FF0400	Local EPC safety detail from SMCU diagnostics

The split is intentional:

Peer safety reporting stays simple — it only carries information the EPC actually knows from peer tracking and care list status.
Local safety reporting carries richer SMCU diagnostic detail without overloading the peer message.

Data origin: the smcu-mgmt-linux service reads raw safety frames from SMCU 0 and SMCU 1 over serial, compares successive frames to detect changes, and publishes JSON safety events via ZMQ. The epc-can service subscribes to these events (via the CoAP service layer), encodes them into CAN frames, and transmits them on the bus. Events from SMCU 0 and SMCU 1 can be merged into a single frame using Peer_Source_SMCU = 2 (Both) when both SMCUs report the same change simultaneously.

Peer Safety Event

Peer_Safety_Event reports care list state changes for a specific peer slot.

The following table shows the CAN frame for this message:

Table 29. Table 42 Peer Safety Event CAN Frame
Field	Value
J1939 PGN	0xFF03 (65283)
Priority	2
29-bit CAN ID (source 0x00)	0x08FF0300
CANopen TPDO	TPDO5 — COB-ID `$NODEID+0x580`, OD object 0x3001
Direction	Transmit

The following table shows the message layout for this message:

Table 30. Table 43 Peer Safety Event Layout
Byte	Signal	Type	Values / Meaning
0	`Peer_Event_Counter`	uint8	Increments for each peer safety event. Wraps at 255. Use to detect missed transitions.
1	`Peer_Index`	uint8	Care list slot index, 0-31.
2	`Peer_Source_SMCU`	uint8	0 = SMCU0 / 1 = SMCU1 / 2 = Both / 255 = Unknown
3	`Peer_IO_Index`	uint8	IO pair index on the peer.
4	`Peer_Current_State`	uint8	0 = Care_List_Empty / 1 = Care_List_Ok / 2 = Care_List_Timeout / 3 = Care_List_Safety
5	`Peer_Reserved_0`	uint8	Reserved. Transmit zero.
6	`Peer_Reserved_1`	uint8	Reserved. Transmit zero.
7	`Peer_Reserved_2`	uint8	Reserved. Transmit zero.

Care List States

The Peer_Current_State field is derived from the SMCU’s care list bitfield for the given peer slot. The simplified four-value enum used on CAN maps as follows:

Table 31. Table 44 Peer Current State Care List
Value	Name	Meaning
0	Care_List_Empty	This care list slot has no peer configured.
1	Care_List_Ok	The peer is configured, receiving messages within timeout, and not requesting safety.
2	Care_List_Timeout	The peer is configured but has not received all required messages within the timeout window.
3	Care_List_Safety	The peer is configured and receiving messages within timeout, but is requesting a safety state.

Examples

Peer timeout - care list slot 7 times out on SMCU 0:

Table 32. Table 45 Example of Timed-out Peer
Byte	Value (decimal)	Meaning
0	41	41st peer event sent
1	7	Peer index 7
2	0	SMCU 0
3	0	IO 0
4	2	Care_List_Timeout
5-7	0	Reserved

Peer requesting safety - same peer recovers from timeout but is now in safety:

Table 33. Table 46 Example of Peer Requesting Safety
Byte	Value (decimal)	Meaning
0	42	42nd peer event sent
1	7	Peer index 7
2	0	SMCU 0
3	0	IO 0
4	3	Care_List_Safety
5-7	0	Reserved

If a logger receives event counter 41 and then counter 43, it knows event 42 was missed and can flag that for review.

Local Safety Event

Local_Safety_Event reports local EPC safety state changes with SMCU-level detail.

The following table shows the CAN frame for this message:

Table 34. Table 47 Local Safety Event CAN Frame
Field	Value
J1939 PGN	0xFF04 (65284)
Priority	2
29-bit CAN ID (source 0x00)	0x08FF0400
CANopen TPDO	TPDO6 — COB-ID `$NODEID+0x680`, OD object 0x3002
Direction	Transmit

The following table shows the message layout for this message:

Table 35. Table 48 Local Safety Event Layout
Byte	Signal	Type	Values / Meaning
0	`Local_Event_Counter`	uint8	Increments for each local safety event. Wraps at 255.
1	`Local_Event_Type`	uint8	Category of local change (see Event Types below).
2	`Local_Source_SMCU`	uint8	0 = SMCU0 / 1 = SMCU1 / 2 = Both / 255 = Unknown
3	`Local_IO_Direction`	uint8	0 = Input / 1 = Output / 2 = Both / 255 = Not Applicable
4	`Local_IO_Index`	uint8	IO pair index (0-2). 255 when not applicable to this event.
5	`Local_Current_Safety_Summary`	uint8	Normalized safety summary bitfield (see below).
6-7	`Local_Event_Code`	uint16 (little-endian)	Exact SMCU cause value (see below).

Event Types

Table 36. Table 49 Event Types
Value	Name	Meaning
0	IO_State_Changed	The safety state of an IO pair changed.
1	IO_Cause_Changed	The cause of an IO pair’s safety state changed without the state itself changing.
2	IO_State_And_Cause_Changed	Both the state and cause changed simultaneously.
3	Safe_State_1_Changed	The processor-level Safe State 1 cause changed (not tied to a specific IO pair).
4	Safe_State_2_Changed	The firmware/config-level Safe State 2 cause changed.
255	Reserved_Unknown	Reserved.

IO Direction

Local_IO_Direction identifies which side of the IO pair triggered the event:

0=Input - the event is tied to the input side of the IO pair
1=Output - the event is tied to the output side
2=Both - the event applies to both sides of the same IO index
255=NotApplicable - the event is not tied to a specific IO pair (use for Safe State 1/2 events)

IO Index

Local_IO_Index identifies which of the three SMCU IO pairs is involved (0, 1, or 2). Set to 255 when the event type is Safe_State_1_Changed or Safe_State_2_Changed.

Local Current Safety Summary

Local_Current_Safety_Summary is a normalized bitfield providing a quick summary of the current local safety status. It is intended for simple customer-facing logic without requiring decoding of the raw SMCU cause codes.

Table 37. Table 50 Local Current Safety Summary
Bit	Name	Meaning when set
0	Not_Requested_or_Output_Permitted	Safety is not currently requested, or output is permitted.
1	Fault_Present	A hardware fault is contributing to the safety state.
2	Timeout_Present	A care list timeout is contributing to the safety state.
3	Safety_Request_Present	An input safety request is contributing to the safety state.

Bits 4-7 are reserved and always zero.

Local Event Code

Local_Event_Code is a 16-bit little-endian value whose interpretation depends on Local_Event_Type:

For IO events (types 0, 1, 2): it is the SMCU’s outputSafeCause bitmask for the reported IO pair. Each bit indicates a specific cause:

Table 38. Table 51 Local Event Code
Bit	Name	Meaning
0	INPUT_REQUEST	The input side requested a safety state.
1	INPUT_FAULTY	The input side is detected as faulty.
2	CARE_TIMEOUT	A care list peer has not responded within the timeout window.
3	CARE_LATENCY	A care list peer’s response latency exceeded the configured limit.
4	OUT_ON_FB_OFF	Output is commanded on but the feedback signal reads off.
5	OUT_OFF_FB_ON	Output is commanded off but the feedback signal reads on.
6	OSSD_FAILURE	Output circuit (OSSD) hardware failure.
7	PAIR_SMCU	The paired SMCU requested a safety state.
8	CUSTOMER_SUPPLY_VOLTAGE	Customer supply voltage dropped below 8 V.
9-15	Reserved	Reserved, always zero.

For Safe State 1 events (type 3): it is lastSafeState1Cause, a processor-level error code from the SMCU firmware.

For Safe State 2 events (type 4): it is safeState2Cause, a configuration or firmware error code from the SMCU.

Examples

IO safety request with timeout - input request, care timeout, and care latency on local output pair 2 from SMCU 0:

Table 39. Table 52 Example of IO Safety Request with Timeout
Byte	Value	Meaning
0	17	17th local event
1	2	IO_State_And_Cause_Changed
2	0	SMCU 0
3	1	Output direction
4	1	IO index 1 (output pair 2)
5	0x0C	Timeout_Present + Safety_Request_Present
6-7	0x000D	INPUT_REQUEST (bit 0) + CARE_TIMEOUT (bit 2) + CARE_LATENCY (bit 3)

Safe State 1 event - not tied to a specific IO pair:

Table 40. Table 53 Example of Safe State 1 Event
Byte	Value	Meaning
0	18	18th local event
1	3	Safe_State_1_Changed
2	0	SMCU 0
3	255	Not applicable
4	255	Not applicable
5	0x00	No IO summary for this event type
6-7	0x50A5	Exact Safe State 1 cause from SMCU firmware

Timing and Merge Behavior

epc-can uses a short merge window when deciding whether to combine events from SMCU 0 and SMCU 1 into a single frame with Peer_Source_SMCU = 2 (Both):

Peer Safety Event: 600 ms merge window per IO slot per peer index. If SMCU 0 and SMCU 1 both report the same care list change for the same IO index within that window, one combined frame is emitted instead of two separate frames. Each IO index is tracked independently, so events on different IO slots do not interfere with each other.
Local Safety Event: 200 ms merge window. The shorter window reflects that local state changes tend to be tightly synchronized between the two SMCUs.

If only one SMCU reports a change, or the two SMCUs report at different times outside the merge window, two separate frames are emitted — one with Peer_Source_SMCU=0 and one with Peer_Source_SMCU = 1.

Why the Split Is Useful

Separating peer and local safety into two messages gives integrators flexibility:

Customers can filter peer and local traffic independently on their CAN tool.
The peer message stays simple and easy to decode without SMCU internals knowledge.
The local message can carry richer diagnostic detail for FORT support and analysis.
Future growth of peer tracking and local diagnostics can happen independently.

Configuring CAN with FORT Manager

This section shows you how to use FORT Manager to enable CAN and set optional CAN parameters.

By default, CAN is disabled for communication between devices.

To Enable CAN and set Optional Parameters

Open FORT Manager and click Configurations.
Add your devices to the configuration (or select an existing configuration of interest).
Click Settings > General and in CAN Mode select CANopen or J1939.

All CAN parameters come with default values, however, you can change any of the following:
- CAN Bitrate: Select a value from the dropdown menu to set an optimal bitrate for your CAN bus.
- SRCP User Display Text String PGN and SRCP Settings PGN : (J1939 only) If you have a crowded CAN bus on your system and are worried about conflicting PGN values for these SRCP messages, you can change either or both of these values here. Select a value from the dropdown list; values are in the Proprietary B range, 0xFF00 - 0xFFFF.
  
  If you change the default PGN value for either of these messages, you must edit the sample DBC file to match the PGN to the new value.
- Source Addresses: (J1939 only) Specify a comma-separated list of J1939 source addresses that are permitted to send messages to the EPC. To prevent unauthorized communication with the EPC, any addresses not on this list are ignored.
Click Save.

You can also change the numerical identifier for your EPC devices on the CAN network (which by default is set to 3 for all devices).

The node ID or address uniquely identifies the EPC on the CAN system. Potentially, each piece of your equipment could have multiple CAN elements, each of which requires a unique ID. Therefore, you must be certain that whatever value you set in FORT Manager doesn’t conflict with a different CAN element on any of your equipment. Setting a single value for all EPCs means that you must only check one value against any CAN components on the equipment. But you can assign different IDs to each device if you wish. The node ID applies to senders and receivers alike, on both CANopen and J1939.

Note:
You cannot change the NODE ID through the CANopen NMT protocol but must do so here.
In Settings, click the Devices tab and select a device from the Devices field.
In CAN Node ID type or select a number for the node ID (For CANOpen, 1 - 127, for J1939, 1 - 253). Repeat for the sender as well as the receivers.
Repeat for each device to which to assign a new node ID, then click Done.