LCOS is an object-oriented, event driven operating system. Throughout this manual you will see things referred to as “objects” that “fire” or “listen for” “events.”
Some users will recognize these terms, others may find them confusing at first, so a brief explanation is in order.
In computer programming, the terms “objects”, “object-oriented” and “events” have specific meanings. For novices and non-programmers: “OOP” (object oriented programming) provides a way to encapsulate functions and relevant information so that a program can manage multiple instances of the same type of thing in a consistent fashion. In other words, once you create the code for handling one widget, the same code can be used over and over again for as many widgets as needed. The only thing that is unique to each widget, is its individual information (data, called “properties”). That allows a small piece of computer code to handle a large number of similar objects.
“Events” are, in general terms, a system for signaling between independent processes or machines. In computer systems, events occur at multiple levels. For example, a key press generates a hardware event that an operating system can capture and direct to whatever application currently has “focus.” Events help an operating system and applications function cooperatively on a computing device.
What is an LCOS Object?
LCOS objects are abstractions of the physical objects on your layout. The essential elements of your layout — turnouts, signals, track blocks, scenic elements, etc. — are represented and managed by LCOS objects. Like the prototype, each layout object functions independently according to specific rules or conditions.
Each object has properties, such as specific hardware information needed to make the object function. Most commonly, the information needed is simply what kind of device is involved and which port(s) the device is attached to.
Some basic objects may need more information. For example, an object that employs a servo will need servo position data in order to function as intended. A standard relay — a basic object in LCOS using a standard double SPDT relay — needs two ports to run and needs to know which port to use for each relay state.
Throughout the configuration process, you will create LCOS objects to represent and interact with your layout objects. Each object has “properties” you can edit, including rules for how an object should behave.
Turnouts are an example of complex, composite object. A turnout has a motor type; each motor type has connection properties that allow the turnout to use the motor. Additionally, turnouts can be linked to both frog power and reversing relays, managing track polarity as needed; Control Objects can be activated based on turnout alignment. Once configured, turnouts “know”:
- how to change alignment of the points;
- how to manage a power feed to the frog;
- how to set a reversing relay for the chosen route;
- how to trigger associated Control Objects;
- how to listen for commands; and
- how to inform other layout objects of state changes.
Blocks (with BOD Hardware) can detect and report track occupancy; they can also trigger Control Objects according to occupancy.
Signal objects listen for messages from specific blocks and turnouts, changing the aspect displayed by the layout signal device according to rules you select.
LCOS supports two unique abstractions for advanced layout functions:
- Control Objects: these are objects that control other objects. They can be associated with a hardware input device, such as a button, switch contact or sensor. LCOS supports virtual inputs to provide a control bridge between different objects.
- Scene Objects: these composite objects allow LCOS to manage groups of mixed objects. With scene objects, lighting, relays and other things can be controlled as a group, allowing mulitple layout objects to be manipulated simultaneously. Scene objects also support effects such as randomization and flashing.
What is an Event?
The messages exchanged by layout objects are called Events. Some Events are command messages requesting one or more objects to perform a particular action or exchange information. Other events are information events that other objects may be listening for. The most frequent events are layout time events fired by the Fast Clock Server and status change events fired by layout objects.
Lets put it in terms of layout function. When a train enters of leaves a block of track, the block object senses an occupancy change. Each change causes the block object to generate — “fire” — a multicast message to all other nodes: “My Id is X and I am now [occupied or unoccupied].” A signal object, configured to listen for messages from that particular block, may respond by changing aspects.
Events can be multicast — broadcast to all nodes — or directed to a specific node or layout object. In some cases, both happen.
Lets look at an example of how this works. Lets say you configure a button — using a Control Object — to toggle a turnout. Toggle means flipping the turnout between closed and thrown [main or divergent routes] every time the button is pressed.
When you press the button, the button object sends a turnout command event to the targeted turnout object. The turnout object in turn starts moving and multicasts an “in motion” event follow by an “alignment state” event when the move is complete. A Signal Object listening for those messages can change aspects.
All of that happens in the background. What you see, when you press the button, is a turnout move and signal aspects change. If you have configured control panel indicators, they too will change in response to messages from the turnout.
The Fast Clock Server multicasts a time message at regular intervals, allowing scenes to change as the “fast” day progresses. When enabled and fully used, the Fast Clock effectively becomes an “engine” driving layout action and responses.
See About Layout Time for more information about time events.