DESIGNER’S HANDBOOK 4189350049C EN Page 49 of 206
CANopen uses an arbitration process on the 32 bit header of a CAN frame. The smart thing is, that in case of a
data collision, the CAN frame with the lowest header value will continue transmitting, while the one with the highest
header value will redraw and try again later. The NodeID is indirectly part of the CAN frame header, and it is
possible to give a CAN unit higher priority by selecting a lower NodeID. In most indication systems, using CAN bus,
the busload is so low that collisions and thereby priority is not an issue. Anyhow, we recommend that the low
NodeIDs are used for controllers and sensors and higher NodeIDs are used for the indicators themselves.
5.1.3.2 NodeID for automated setup
If you now or later want to include an automated installation-setup function in your CAN-based indicator system, it
is a very good idea to make a standardised structure for the use of NodeIDs in your systems.
There are 127 available NodeIDs, which is NodeID = 1 to 126, and 127 is in most cases reserved by XDi-net.
The NodeID structure or list should reflect the selection of virtual indicator, VI-setup and PP for each XDi node.
5.1.3.3 Example of a custom NodeID list:
In this example, all indicators are running on the same redundant CAN bus with up to two propulsion systems on
the same bus. Data of the same type (for example azimuth angle 1 and 2) are determined by the data type
instance, which is then pre-configured in the two VI-setup profiles. The dimmer function is also distributed via CAN
bus and is divided into 5 dimmer groups, each pre-configured in a PP, one PP for each dimmer group.
To Next Page
Loading...
Need help?
General
