All nodes must be able to take part in all standard interactions.
Newly functional nodes, once their start-up is complete and they are fully operational, must send an "Initialization Complete" message.
There is no guarantee that any other node is listening for this. No reply is possible.
Nodes must not emit any other OpenLCB message before the “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.
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.
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.
There are multiple mandatory error-handling scenarios defined.
Node A receives an addressed message from Node B that carries Node A's NID.
The MTI indicates the start of an optional interaction.
If Node A does not want to take part in the optional interaction, it may send an Optional Interaction Rejected message addressed to Node B with the original MTI in the message content. There is no requirement that OIR be sent; the node may silently ignore the incoming message.
The message content also contains an optional reason code and an optional data value. The use of these fields is to be defined.
Node A receives an unaddressed message from Node B.
The MTI indicates the start of an optional interaction.
If Node A does not want to take part in the optional interaction, it silently drops the message without reply.
Node A is taking part in an addressed interaction with Node B. Either node may be able to send the next message.
Some error condition prevents Node A from continuing the interaction.
To terminate the interaction, Node A sends a Terminate Due to Error message to Node B. It then resets it's state so as to no longer be taking part in the addressed interaction.
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 $