The full OpenLCB protocol is complicated, because it has to enable complete discovery and routing into the future along with supporting multiple data transfer protocols.
But simple nodes, e.g. a board on a CAN segment, only have to handle a subset of the full protocol. This note discusses that.
For the purposes of this note, we consider a "simple board" to:
Provide only one node
Have a single CAN interface, and no other OpenLCB interfaces
To produce and consume events, but do nothing else with the OpenLCB
(What level of configuration? Datagrams might be needed for off-board configuration)
The simple board must take part in the CIM, RIM protocol to get a alias allocated.
Once that process is done, the simple board must send an "Initialization Complete" message.
It must follow that with "Producer Identified" and "Consumer Identified" messages for each of the events that it produces and consumes, respectively.
The simple board must listen for "Verify Node ID Number" and "Verify Node ID Number" with its NID present. When found, the board needs to reply.
To produce an event, the simple board must send "Producer/Consumer Event Report" messages.
To comsume an event, the simple board must listen for "Producer/Consumer Event Report" messages that match events its monitoring.
If the node produces or consumes events, it must listen for "Identify Producers" and "Identify Consumers" messages, respectively, with Event IDs that match its own internal Event IDs, and "Identify Events" messages that match its Node ID (NID).
If found, it must reply with it's own "Producer Identified" and "Consumer Identified" messages.
The simple board must listen for the following CAN frames, and respond to them. All others can be ignored, e.g. via CAN filters.
The CIM, RIM frames from node alias allocation
Verify Node ID Number, Verify Node ID Number
If the simple board produces events, it must listen for "Identify Producers" and "Identify Events".
If the simple board consumes events, it must listen for "Producer/Consumer Event Report", "Identify Consumers" and "Identify Events".
For a CAN node, at a minimum a board must receive and process two CIM, RIM segment specific messages, plus one (two if Addressed/Unaddressed is separately counted) common OpenLCB message. Configuration process not included here
If the board can also produce and consume events, it has to receive and process four more message types.
Alternately, here are the messages a simple CAN board can ignore, perhaps via filtering:
Verified Node ID Number Number
The various error messages: Optional Interaction Rejected, Terminate Due to Error
Consumer Identified, Consumer Identified, Producer Identified, Producer Identified
Initialization Complete (But note that a node might want to monitor this to detect duplicate NIDs)
Site hosted by
This is SVN $Revision: 781 $