Standard Interactions

All nodes must be able to take part in all standard interactions.

A) Node Initialization

Newly functional nodes, once their start-up is complete and they are fully operational, must send an "Initialization Complete" message.

Sending the IC message is required to insure that higher-level tools are notified that they may start to work with the node.

After the IC message is sent, and before any corresponding Producer/Consumer Event Report messages are sent, the node must identify all events produced or consumed on the board via zero or more Identify Consumers, Identify Consumed Range, Identify Producers and Identify Produced Range messages. These are not required to be in any particular order.

B) Duplicate Node ID Detection

OpenLCB nodes must have unique node IDs. To detect this across the entire connected OpenLCB, all OpenLCB nodes must indicate an error if they detect an incoming message with a Source Node ID equal to their own. If possible, they should indicate it at the board itself using a light or similar. If possible, they should emit a PCER message with the “Duplicate Source ID detected” global event, which will carry the duplicate event ID in the Source Node ID field.

After sending the “Duplicate Source ID detected” global event, the node should not transmit any further messages until reset because this message will be received at the other duplicate-ID node(s), resulting in additional “Duplicate Source ID detected” global events and causing a possible message loop.

To further improve the reliability of this detection, OpenLCB nodes should, but need not, emit a Verified Node ID message every 30 to 90 seconds. As an implementation detail, it's recommended that CAN-attached nodes use their NIDa to pick that interval so that messages don't bunch up.

C) Node ID Discovery

Upon receipt of a Verify Node ID Number message addressed to it, or an unaddressed Verify Node ID Number message, a node will reply with an unaddressed Verified Node ID Number.

This can be used as check that a specific node is still reachable. When wire protocols compress the originating and/or destination NID, this can be used to obtain the full NID.

D) Error Handling

There are multiple mandatory error-handling scenarios defined.

Reject Addressed Optional Interaction

The message content also contains an optional reason code and an optional data value. The use of these fields is to be defined.

Reject Unaddressed Optional Interaction

If Node A does not want to take part in the optional interaction, it silently drops the message without reply.

Reject Addressed Standard Interaction Due to Error

The message content contains the most recent MTI received in this interaction, a mandatory reason code and an optional data value. The use of these fields is to be defined.

Site hosted by

This is SVN $Revision: 2385 $