These examples discussion various aspects of bringing up an OpenLCB, including adding segments and individual nodes to a running OpenLCB.
For an OpenLCB that's separated into multiple segments, e.g. several modules on CAN networks connected via an Ethernet backbone, it is likely that the segments will initialize at different times.
When a node becomes operational, it sends out an "Initialization Complete" message which other nodes can use to e.g. update status tables, trigger notifications, etc. It follows this with notification of the Event IDs it wants to receive/consume and the ones it is capable of sending/producing.
When a node comes up, it can check on the existance of other nodes several ways:
To check for the existance of a specific node, send a "Verify Node Serial Number (Addressed)" message to the specific node.
To get a list of all currently reachable nodes, send a "Verify Node Serial Number (Unadressed)" message.
To check for the existance of at least one node that produces a specific Event ID, e.g. one consumed by a node, the "Producer Identification" standard interaction can be used. There is no requirement that every Event ID configured into an given consumer exist, so a lack of response to this interaction is not an error, but it can provide useful information.
To check for the existance of at least one node that consumes a specific Event ID, e.g. one produced by a node, the "Consumer Identification" standard interaction can be used. There is no requirement that every Event ID configured into an given producer exist, so a lack of response to this interaction is not an error, but it can provide useful information.
Is there a need for a mechanism by which a newly-operational node can e.g. call for download of configuration information, large files (e.g. sounds) or similar? Might be nice to not have to store them locally, particularly with large bandwidth OpenLCBs. Global events can be used to call for specific resources, because they carry the source node ID of the emitting node.
Producer/Consumer systems react to state changes, which are transferred as Events. When a node first becomes operational, however, it may not have any knowledge of the existing state. It can't figure out how to act until the next external change results in an Event, which is distributed as a PCER message.
Nodes that power up independently will operate, but higher level mechanisms are needed for to initialize their inputs and outputs as part of the entire layout. Those mechanisms can be triggered by e.g. "Initialization Complete" messages from the newly-functional node.
Several mechanisms are available for implementation:
A store-load mechanism can capture and store the state of nodes, and restore those latter. This puts the layout back to the earlier state, but doesn't handle any state changes that have happened since the state was captured. There's (currently) no mechanism to trigger the store operation.
The store operation can capture the current state of consumers on the layout via the "Identify Consumers" common message. Nodes that fully implement this reply with the current state of their consumers. Restoration of this via PCER messages will restore the output state. Note that it's not required that nodes know the state of the devices attached to their outputs. Depending on what that device is, they simply might not have any way to know.
The newly-functional node can use the Producer Identification interaction to get "valid" bits from (all) the Producers of the Event IDs that can effect the newly-functional node. This is not fool-proof, however, as not all nodes can produce those, and there might be history (e.g. which Producer fired most recently) that can't be recovered.
Sample scenario:
A) For each event ID being consumed, send a global “Identify Producers” message.
B) When (if) a “Producer Identified” message comes back, check the “uncertain” bit. If the message is not uncertain, and the “valid” bit is set, consumers should act as if a PCER message with this event ID has been received.
C) If more then one “Producer Identified” message without the “uncertain” bit is returned, it's possible that the “valid” bits will not agree. There are several ways to deal with this (1) consider it an error to be reported, (2) just act on the 1st one or (3) just act on the last one. The system is inconsistent, so it's not clear that any of these are right or wrong.
Site hosted by
This is SVN $Revision: 721 $