Modular clubs and their inter-club meets present the most complex use case for OpenLCB. This note describes some of the things they'll want to do, and how OpenLCB can bring it about.
Large layouts...
Made of individual modules, and various levels of subassemblies: multi-module yards, club layouts, etc.
Throttle controls across entire layout...
Reduce required coordination... Organizations like FREMO are using CAD tools, etc, to design layouts for large meets. Connecting to those, in a flexible manner, is important.
Within a module
Between Modules
Central idea: OpenLCB is a base for implementing solutions. How to do that need not be specified, particularly at first.
Spanning CAN between modules to reduce cost; provides way to create smaller module groups for e.g. club running, etc. Universal address space means you can just wire as needed, limited only by length and traffic.
Assignment of Node, Event IDs ensure uniqueness, no overlaps or collisions.
Use of FREMO membership ID space, or perhaps establish subspaces by club, by region, etc, to do actual assignment.
Events within modules can just be configured in the usual way, without worrying about ID collisions.
To connect modules, a modular group could define standard “Interface Events” to e.g. tell one module's signals that a train is approaching, or is occupying the next block ahead; to allow control from other locations. Easy to document these interface events at the same time as mechanical dimensions, etc, for overall planning. For example, 0x1001 in the low-part of the EventID could mean “Track one occupied east end”, 0x1002 could be “Track two occupied east”, with others for the west end of the module, conveying signals status for look-ahead, etc.
Must have a way to match up the events produced by one module with the events consumed in the next. There are a couple of ways that this could be done:
Redefine module configuration: As the modules are set up, their Consumers can be configured with the events produced by the adjacent module. Alternately, the Producers of interface events can be reconfigured to produce the events expected by the adjacent Consumers. This is robust and requires minimal communications in operation, but does require changing configurations.
Reconfigure via special support: Nodes for module interfaces could have a special configuration facility that makes it easy to specify just the NodeID of the adjacent module, automatically working out all the necessary Event IDs. Or this could be a special tool that knows how to do this: Plug it in, ident the two nodes, and off it goes.
Conversion via separate node: E.g. The “Track one occupied east” event gets remapped to the specific event required as input in the adjacent node. Could be small node that does this for just one interface, or large central PC; can be distributed as required by other constraints.
Use of e.g. Ethernet for backbone connecting all individual segments (as many as needed) to PCs. This removes distance limitations, etc.
Routing protocols have to make it possible to pull all traffic onto backbone. Not really a bandwidth issue, Ethernet speed gets higher and higher all the time, more of a management issue.
Consider a modular meet at which N clubs bring together their sections of layout. Further, consider that each section is configured with a common CAN OpenLCB segment. They would like to connect the segments into a single OpenLCB CAN segment, configure the interface eventIDs, and operate. Central PC tools can do the configuration, but how about doing local (button-based) configuration? Blue/Gold and similar global message methods can only be used one-at-a-time on the connected layout.
One way to fix this is to put a 4PDT switch in the middle of each CAN segment. This could be in the middle of each module, or only one per segment. Set one way, the CAN network is continuous. Set the other way, it's divided into two segments, each with a terminating resistor.
Now, connect two segments, each split in the middle by setting the switch. Those can be configured using e.g. blue/gold, then the switch set back to normal operation.
This is SVN $Revision: 721 $