Step 3: Plan Node Placement and Addressing
Once you have divided your layout into functional zones and determined the resources you’ll need, its time to consider the interrelated issues of node placement and node addressing. For an explanation of LCMN addressing, see A Guide to the Layout Control Operating System.
Small Layouts
Continuing with the basic 4 x 8 HO Layout, let’s assume we’ve decided on Tortoise switch machines. With that decision, we can determine what components are needed and where they should be placed. In this plan we can use a single LCOS Client node controlling a chain of 6 or more DNOU8 boards, with 2 channel relays to control the switch machines.
What makes this plan work is the reach of a chain of DNOU8 boards. In this case, we need 27 ports for the signals and 8 ports (2 each) for the relays that run the turnouts. If we stack DNOU8’s in pairs, we will end up with 3 groups of 16 ports. Most of the wiring is contained in small areas — power plus a 3 wire connecting cable (running from the Client LCN to one of the stacks, then from there to each additional stack forming a chain) are the only wiring outside of these areas. With 35 ports in use, 13 remain for other uses such as layout lighting or a special animation.
Addressing is simple: you will arbitrarily select an address between 01 and 05 for your Client. Your Master (Node 00) will be mounted on your control panel and can be located anywhere adjacent to or within a dozen feet line-of-sight (no obstructions) from the Client. That gives lots of latitude in locating controls. With wireless communication, your control panel can be an independent object with just a power connection.
Larger Layouts
Lets look at a mid-sized layout.
In this layout, the combination of physical size and track complexity calls for five Client nodes.
As before, turnouts tend to drive decisions. In this case, many modelers would choose servo motors over Tortoise motors for turnouts on this layout for two good reasons: 1) the big cost difference when dealing with 29 turnouts: Tortoises cost $20+ each; SG90 servos about $1.50 each. Even with the cost of extra LCNA Client Nodes, you come out hundreds of dollars ahead with no functional compromise. Plus: 2) in a yard ladder, SG90servos are way more compact and easier to fit in, especially in smaller scales.
With that in mind, the layout naturally divides into 5 functional zones. The Eastern Mainline zone is rather large. However, that zone is tasked primarily with block occupancy detection, plus some signals (not shown), both of which can be deployed flexibly as we’ve seen before.
Accordingly, node addressing remains uncomplicated. Assign each node an address between 01 and 05 as shown.
Even Bigger Railroad Empires
You can probably see that with the example above, we’ve reached the limit of level 1 addresses (01 – 05). But don’t worry, because level two has 25 more addresses, enough for a layout substantially bigger than the example. And levels 3 and 4 are still available too.
In a larger layout, one consideration should be foremost in assigning addresses: the distances between nodes and from each client to the Master.
Lets look at an example of a large, complex basement-sized layout in the form of a block diagram:
This layout requires at least 10 LCNs, which means we have to use both level one and level 2 addresses. A node address describes the route from the MASTER to a Node. So, for example, node 021 means “from master go to node 01, then to its child 02. In a layout of this size, node-to node distances can be an issue, so it is important to pay attention to distances and message pathways.
In the example, I’ve assigned the 5 closest nodes level 1 addresses. More distant nodes are level 2 addresses, children of the closest level 1 node. The resulting messaging pathways are shown as green arrows.
I’ve intentionally chosen a non-optimal node structure to help illustrate how dependencies work. The astute reader will notice that I could have legitimately chosen a slightly different structure — changing 021’s address to 012, and changing 031 to 015., making them the children of 02 and 05 respectively. What is the advantage? Right now if node 01 goes down, it takes 3 other nodes offline. Spreading the dependencies out improves fault tolerance.
At node 03, there really isn’t a better structure without adding another node.
Where to Go from Here
If you have not already done so, see A Guide to the Layout Control Operating System. For and overview of LCOS, Lew’s Duino Gear LCOS products and how they fit together, see LCOS – The Layout Control Operating System.
As you can see, whether your layout is big or small, a little planning will help ensure a successful LCOS installation. Balancing all considerations is fairly easy on a small layout, but gets progressively more complex as layout size and complexity increase.
People usually build their layouts incrementally, starting with some benchwork and a section of track, then building from there over time. LCOS is designed to start small then grow and change with the rest of your layout. Every aspect of a node can be reconfigured, from its address to its logic tables, at any time you need to. As new nodes come online, parent-child relationships and resulting message pathways can be changed to match new conditions.
In other words: start small and fearlessly build from there!