Open search

CAN Newsletter magazine

Node-ID assignment using LSS

Since several years the technical interest group developing the CiA 305 specification at CiA discusses which CANopen layer setting services (LSS) should be adapted to CANopen FD. This article summarizes the current work status.

Splitting the 128-bit LSS ID into an array of 32 values of four bit (Source: Embedded Systems Academy)

The complete article is published in the June issue of the CAN Newsletter magazine 2020. This is just an excerpt.

An updated version of the CiA 305 specification should be published in 2020. The LSS allow low-level configurations of the used CAN (FD) bit-rate(s) and assignment of the node-IDs and network-IDs of the connected CANopen (FD) devices. Enhancing the existing services to configure switching of the bit-rate is relatively simple. Parameters can be added to support the multiple bit-rate combinations of CANopen FD. When it comes to the node-ID and network- ID assignment, a basic requirement for participating devices is the availability of the object 1018h (identity object) with all four 32-bit sub-indexes: vendor-ID, product code, revision number, and serial number. Together these make a unique 128-bit value (further called 128-bit LSS ID) by which devices can be identified. If the LSS master knows the entire identity object, then node-ID assignment is simple. In a nutshell, the LSS master asks: “Is there anybody here with this 128-bit LSS ID?”.

In classic CANopen, this question is fragmented into four CAN frames, in CANopen FD the request goes into a single frame. The LSS device with a matching 128-bit LSS ID replies that it is available. From now on, this device is the only one accepting LSS master configuration commands (all others ignore the commands, as they have not been selected).

Over the last years, there have been several solutions published to the more challenging question: how should the LSS master proceed, if the identity objects of the connected devices are not known. The last standardized approach to this challenge was the LSS Fastscan method using a binary or bit-by-bit search. The LSS master would ask such questions as “Is there anybody here whose highest bit in the 128-bit LSS ID is set?” or “Is this particular bit of your 128-bit LSS ID set or not?”. All LSS devices that want to answer “yes” to such a question reply with a single “ping” message. The “ping” message is a CAN frame with a fixed CAN-ID and the length of zero. If multiple devices transmit the frame at the same time, then there are no errors on the network, as these frames “overlay” and can be transmitted in parallel by multiple devices at the exact same time. On the bottom line, such a method requires the LSS master to typically send 128 requests narrowing the requests down to finally have an exact 128-bit LSS ID selected. Even with a challenging timeout of 30 ms for each request, this takes about 4 s per device to execute.

In one of the CiA (CAN in Automation) application profiles, CiA 447 (CANopen application profile for special- purpose car add-on devices), an additional manufacturer- specific feedback method can be used to significantly shorten the detection time. Here, LSS devices use feedback messages to the LSS master, to inform it about bits in their 128-bit LSS ID. However, this method uses CAN frames with 29-bit CAN-IDs and is limited to 16 devices.

LSS slave handling a request with the nib = 19 (Source: Embedded Systems Academy)

Re-thinking LSS for CANopen FD

As CAN FD is not backward compatible to Classical CAN, LSS for CANopen FD would also not need to be backward compatible, allowing the experts to re-think if other solutions would make sense. One limiting factor is, that any “ping” (“yes” answer to a request) message that multiple devices could send at the same time would still need to be transmitted in Classical CAN format with data length of zero. In CAN FD, even the messages with zero data length may have a difference in at least one bit (error state). Therefore, the messages cannot reliably overlay when they are transmitted at the same time.

For the CiA group, the open demands for a future CANopen FD LSS method are:

  • The LSS device side must be simple to implement
  • The method must be reliable
  • If feedback messages are used, it must be ensured that these also work for a larger number of participants
  • Results should be predictable and repeatable
  • The method should be flexible, allowing shortcuts when parts of the 128-bit LSS ID are known

Regarding the predictability (if the same combination of devices is used, the node-ID assignment will be always the same for each node) it must be pointed out, that this was not supported by previous LSS methods either. Any delay in power-up time or internal processing of LSS devices can delay their answers and, thus, participation in LSS assignments. However, once a device has a node-ID permanently assigned (stored in the non-volatile memory) or is known to an LSS master (i.e. stored in a node list on the LSS master side) it can have the same node-ID on every power-up.

To keep a method flexible for faster identification of a partially known 128-bit LSS ID, the LSS device side should be simple. There is already a fast node-ID assignment method when the entire 128-bit LSS ID is known. Optimizations are still required for the few cases where only parts of the 128-bit LSS ID are known.

If you would like to read the complete article you can download it free-of-charge or you download the entire magazine.


Publish date