This page holds the answers to some frequently asked questions and misconceptions about OpenLCB.
We are specifically designing a bus for both the present and future. We therefore believe in 'thinking big but developing small', which means we plan for the more general case, but implement with simpler hardware. The large IDs are designed to let us simplify the experience for both novice and expert users by making IDs something they do not need to worry about – they do not need to assign them, or worry that they will conflict with someone else's assignment. They are designed to let you operate really large layouts without concern that you will run out of IDs. And finally, a large event ID lets us to fold other information into it, such as time-stamps or other buses' IDs, allowing us to bridge to them more easily. For example, a fast-clock-node would produce events with the fast-time embedded. Even simple nodes can use these to automate and activate actions, without any additional code.
Firstly, simple nodes need only a few events, so the space taken, even at 8-bytes per event, is not onerous. We have shown nodes that function fine on boards that cost about $30 each retail, including USB and several layout interfaces. It surprised us to see that even though S9.5 claims that our proposal makes simple nodes too expensive, they have not demonstrated any simple nodes, but rather complicated nodes. In addition, we feel that the whole argument is rather moot – microprocessors are advancing along Moore's Law, and already some, costing about $4 each per 100, contain 32k of flash and 8k of RAM – so resources are hardly limited. In many ways, having large event numbers simplifies, and therefore reduces, the firmware required in nodes, see the fast-clock example above.
No, it is not easy, it's hard to do right and even harder to do it automatically. A bunch of hand waving about 'just bridging to other systems' is not engineering. As everyone knows, the devil is in the details, and we have taken the time to think though problems, and to solve them. We have chosen solutions that scale gracefully, and that can take advantage of commodity equipment such as Ethernet routers.
Stating something does not make it true. Whether a proposal fulfills a mandate or criterion is up to the committee, not the proposal. We believe in giving enough details that the committee can make an informed decision, not one of faith. We have made every effort to document and detail each of the S9.6 features. We are proposing a network that spans multiple segments on multiple transports. In our opinion, CBUS and S9.5 basically duplicate the capabilities of Loconet, albeit on a different transport and at a slightly faster bit-rate. Similarly, they only propose, at best, partial solutions to the problems facing modular groups and museum layouts.
CAN is sufficient for many layouts, but by no means all. CAN segments have quite strict limits on both node counts and cable length due to bus loading, bus latency, bus contention and ID wastage. Each segment is restricted to less than 100 nodes based on theoretical hardware drive secondary to network capacitance. Connecting CAN segments together requires at least active repeaters which have only limited ability to resolve bus contention and collisions due to added latency to the network. Un-resolved bus collisions on CAN segments are non-recoverable errors, and active repeaters cannot prevent them. S9.6/OpenLCB uses automatic filtering gateways and fully-unique NodeIDs to completely prevent collisions, but even with that there will be layouts that cannot be served only by CAN. By using a fast 'backbone' bus segment with filtering gateways, S9.6/OpenLCB can support multiple CAN segments, while at the same time reducing their required bandwidth. In addition, this allows multiple software running on PCs to be easily connected to the backbone, and to interact and control the resulting network.
For reliable operation, the CAN bus arbitration mechanism requires that the message headers be unique; overlapping messages cannot be reliably delivered unless they differ in the header. OpenLCB includes the originating unique node ID in a 29-bit CAN header to achieve this. In addition, CAN traffic is limited by the capability of nodes to generate that traffic, and therefore our group feels that the S9.6/OpenLCB packet-size will not make a significant impact on the real throughput of the CAN bus.
No, the full capability of OpenLCB is available without them. However, you certainly can add those if you want, and for larger networks they will be very helpful.
Yes, two nodes can produce the same event ID. The packets will not be identical, as the originating node field in the message will be different, and therefore you can tell where it came from when debugging, but event-consumers will treat the two messages identically.
Those six bytes are the node ID of the node that defines the event, not the node that is currently producing it. The first node to use an event ID (to produce or consume it) defines what it means. Other nodes can use it without trouble, but the defining node is responsible for making sure that every other event it defines doesn't use the same event ID. This ensures that event IDs are always unique, and therefore no reconfiguration is necessary to avoid collisions. We should note that using the node ID is only one of the ways to define an event ID.
OpenLCB programs a node two ways:
(a) By using a node-based UI,for example the Blue-Gold algorithm, which lets any node teach its events to one or more other nodes in one teaching session. This lets two or more nodes be taught events on the work-bench before they join the layout, after which they would learn the interactions with the other layout modules. The user does not need to know the node or event numbers, but just selects the appropriate consumers and producers, and the node passes the associated event to the other nodes. See the draft video at http://www.youtube.com/openlcb#p/a/u/2/D95Y2Z-4gRQ for a look at Blue/Gold node teaching.
(b) By using a configuration tool to set events in nodes. In either case, users do not need to know the node or event numbers used.
The source node-id is *always* carried in the message. In CAN messages, this is the node-id alias, and is carried in the header. The event-ID is a number unique to the event. On method of generating unique IDs is to include a node-id, but this does not need be the source-node's ID. In fact the event-ID is independent of the source-ID.
We mean that you can teach two or more nodes away from the layout to interact together. For example, a yard throat might be controlled by four nodes. These can be taught to set the yard's turnouts and to interact. When they are connected to the layout, there is no chance of a conflict of node or event IDs. The nodes will need to be taught how to interact with the other layout nodes (these are called edge-events). The yard can be removed and the internal workings revised. On return to the layout, all the previous edge events will continue to work undisturbed.
Multiple personal computers (PCs) can be used for:
(a)
Configuration or modification of the layout nodes by programming
events and node-variables, uploading firmware, similarly to JMRI;
(b) Monitoring and debugging. The PC can 'drill' down to bus-segments, modules and node levels;
(c) Operations. A PC can have multiple programs interacting with the layout through a single network interface. This programs can act as virtual nodes, monitors, logic extenders, 'glass panels' etc.
Of course not, 99% of nodes will already have node-ids assigned by their manufacturer. Hobbyists can build their own nodes, if they like. In this case they can use node-ids already assigned to them through their club memberships, use ids reserved for local experimental use, or ask for a set of node-ids, likely through a website.
On power-up each node generates a trial alias based on its node-id. It then sends a series of messages guaranteed to detect if another node-id has chosen the same alias. If this is the case, it will repeat the protocol with a new trial alias. See:
http://old.openlcb.org/trunk/documents/can/CanIDAllocation.html
The Configuration Tool can report all the producers and consumers of an event. In addition, every OpenLCB message contains the node that sent it, so it is easy to trace its origin.
Quite often we can 'fold' legacy messages inside out events. For example, DCC accessory messages can be turned into OpenLCB events. This means you can teach an OpenLCB node to respond to any DCC accessory bus message – no additional firmware is required in that node! Another example is embedding the fast clock time inside events. This means *any* OpenLCB node can can act at a specific time, again using the basic event-handling code. This was demonstrated at the 2010 NMRA convention in Milwaukee. See a draft video at: http://www.youtube.com/openlcb#p/a/u/0/aeLkI4jaFmA
Site hosted by
This is SVN $Revision: 4143 $