Skip to content

Basic Layout Objects, Part 1

There are two kinds of basic layout objects in LCOS: blocks and turnouts.

This part explains the core concepts involved in layout objects in LCOS and how to set up blocks on a Client Node.

Part 2 is about turnouts on Client Nodes, and Part 3 is about setting up the same objects on the MASTER .

Contextual Identification: Local vs. Remote

The objects controlled by a Client Node are local objects for that Node. A Client Node can monitor up to 8 local blocks and control up to 8 local turnouts.

A Client Node may also need to know about objects controlled by a different Node. These objects are remote with respect to the first Client Node, and their state may affect signals or other objects it controls. A Client Node can monitor up to 8 remote blocks and 8 remote turnouts.

The important concept is that layout objects can be either local or remote depending on context: objects are local in the context of the Node that physically controls them, and remote in all other contexts. The contextual difference determines how Nodes monitor and communicate with layout objects.

Nodes keep each other informed of the state of objects they control through the messaging system. State changes on a local block or turnout will cause the controlling Node to broadcast a state change message. Nodes listening for messages concerning those layout objects will note the change to the remote block or turnout and react in an appropriate way, such as by changing a signal aspect.

Object Identification

Each node maintains lists of its local objects and remote objects that affect it. The system of identifying objects is structured to treat all objects of the same type in a uniform way.

It does that in part by ID segmentation. Local blocks and turnouts are assigned sequential ID’s from 0 to 7. Remote objects have sequential local IDs from 8 to 15. Accordingly, blocks 0 through 7 and turnouts 0 through 7 are local objects. Blocks 8 through 15 and turnouts 8 through 15 are remote objects a Node is monitoring.

Numbering is always sequential from 0 (if local) or 8 (if remote) through the number of objects. So, in a layout with 2 Client Nodes, Node 01 might have blocks 0 through 4 plus block 8 in its block list, while Node 02 has block 0 plus blocks 8 to 12 in its list; both sets of blocks are referring to the same objects in different contexts.

UID – the Uniform Identifier

Every addressable layout object has a UID or Uniform Identifier. The UID system collapses all possible local layout objects a Node could manage into a single list of up to 256 objects, where the UID always refers to the same object. In other words, UID 0 always refers to block 0, UID 1 refers to block 1, UID 8 refers to turnout 0, UID 9 refers to turnout 1 and so on.

Accordingly, the absolute address of any layout object is its Node ID plus its UID.

About Blocks

Blocks are used for current-sensing occupancy detection. To activate the Block Occupancy Detection feature on a node you must install the necessary hardware. For more information see Block Occupancy Hardware Installation. If you are not going to use the BOD feature, you do not need to configure blocks.

The Block Tool

In the Main Window click blocks buttonto invoke the Block Tool.

The Block Tool in default state with no blocks defined.

Local Blocks

If BOD hardware is installed, just click hardware scan button to automatically detect your hardware [blocks you don’t wish to monitor can be unchecked]. Otherwise, you can check the blocks you wish to activate and install the hardware later; however, until the hardware is installed the blocks will produce false readings that can affect other objects.

Remote Blocks

If you want a signal or other object to respond to occupancy of a block on a different node, you need to specify which remote blocks the node should monitor. For each remote block you want this Node to monitor, enter the Node ID and select the block UID from the Block list, then click add remote block button to add it to the list.

When you’ve added all relevant blocks, the tool window on Node 05 might look like this:

Note that the remote blocks come from multiple Nodes.

Rail Power Relay

When a Client node with BOD enabled boots, it runs a calibration routine on each active sensor. During calibration, rail power must be completely off or calibration will not complete correctly. That least complicated solution is to leave track power off until the layout has completely booted

Or, you can feed your block sensors (DNCT2B) through a relay and let LCOS turn local track power off whenever it needs to calibrate the sensors. You can also link a kill switch to the same relay for emergency off (we recommend a master power relay and kill switch tied to the MASTER node).

A block power relay set should be wired this way:

This circuit uses the COM terminals for output. Incoming Rail power is attached to the NC terminals of the relays. The output should be connected to the Rail inputs of all sensor boards (DNCT2A) controlled by the node.

So long as the relay is not energized, current will flow from the NC (Normally Closed) terminals through the common outputs to the track. When the relay is energized, the NC contacts are disengaged and current flow stops.

In the Configurator, the Rail Power Relay option is in the local block section of the Block Tool window. You must configure the relay object before it will be available as an option here.

Control Object Links

Control Object links are an advanced LCOS feature, used to create action sequences or change layout lighting when a block is occupied. One use of this capability is to create a crossing that is activated whenever a block is occupied. Please see Control Objects for more information.

Any active block can be linked to one Control Object, making the block a virtual switch that can activate other objects. You must create Control Objects before they can be linked to blocks here.

In the Block Tool, click to open the Control Objects Links window.

The Control Objects window disables entries for inactive blocks.

To link a block to a Control Object, simply select the Control Object from the list next to the block ID. To be available here, the Control Object must be bound to the virtual input port.

Click Save & Close to save your settings.

When the occupancy state of a block changes, the block fires a control object event. If the new block state is “occupied” an “On Event” is fired; an “Off Event” is fired when the block becomes “unoccupied.” The behavior of those events is defined by the Control Object.

Save the Configuration

Click save block map button to save the block data to the Client Node EEPROM.

To complete the change, the node must rebooted. On the Main Window, click reboot button to reboot and load the new configuration.

<< Block Occupancy HardwareBasic Layout Objects 2 >>

Index