LCOS provides a uniform, systematic way of identifying and addressing layout objects. This page will explain how object identification and addressing works.<\/p>\n\n\n\n
One consequence of a de-centralized, nodal structure is that each node has to be able to distinguish between and track the state of objects it controls and objects other nodes control.<\/p>\n\n\n\n
The objects controlled by a Client Node are local <\/em><\/strong>objects for that Node. A standard Client Node can monitor up to 8 local blocks and control up to 8 local turnouts.<\/p>\n\n\n\n A Client Node may also need to know about objects controlled by a different Node. These objects are remote <\/em><\/strong>with respect to the first Client Node, and their state may affect signals or other objects it controls. A standard Client Node can monitor up to 8 remote blocks and 8 remote turnouts.<\/p>\n\n\n\n The important concept is that layout objects can be either local <\/em><\/strong>or remote <\/em><\/strong>depending on context: objects are local <\/em><\/strong>in the context of the Node that physically controls them, and remote <\/em><\/strong>in all other contexts. This difference is reflected throughout the configuration system.<\/p>\n\n\n\n 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 <\/em><\/strong>remote block or turnout<\/strong><\/em> and react in an appropriate way, such as by changing a signal aspect.<\/p>\n\n\n\n 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. <\/p>\n\n\n\n It does that in part by ID segmentation. Local <\/em><\/strong>blocks and turnouts are assigned sequential ID’s from 0 to 7. Remote <\/em><\/strong>objects have sequential local <\/strong>IDs from 8 to 15. Accordingly, blocks 0 through 7 and turnouts 0 through 7 are local <\/em><\/strong>objects. Blocks 8 through 15 and turnouts 8 through 15 are remote <\/em><\/strong>objects a Node is monitoring.<\/p>\n\n\n\n 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<\/strong>.<\/p>\n\n\n\n Every addressable layout object has a UID <\/strong>or Uniform Identifier<\/strong>. The UID <\/strong>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.<\/p>\n\n\n\n Accordingly, the absolute address<\/em> of any layout object is its Node ID plus its UID<\/strong>.<\/p>\n","protected":false},"excerpt":{"rendered":" LCOS provides a uniform, systematic way of identifying and addressing layout objects. This page will explain how object identification and addressing works. One consequence of a de-centralized, nodal structure is that each node has to be able to distinguish between and track the state of objects it controls and objects other nodes control. Contextual Identification… Read More »Object ID & Address<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"neve_meta_sidebar":"","neve_meta_container":"","neve_meta_enable_content_width":"","neve_meta_content_width":0,"neve_meta_title_alignment":"","neve_meta_author_avatar":"","neve_post_elements_order":"","neve_meta_disable_header":"","neve_meta_disable_footer":"","neve_meta_disable_title":"","footnotes":""},"doc_category":[174],"doc_tag":[],"class_list":["post-2652","docs","type-docs","status-publish","hentry","doc_category-object-id"],"year_month":"2026-04","word_count":464,"total_views":0,"reactions":{"happy":0,"normal":0,"sad":0},"author_info":{"name":"Site Administrator","author_nicename":"lew-admin","author_url":"https:\/\/beaglebay.com\/duinogear\/author\/lew-admin\/"},"doc_category_info":[{"term_name":"Object Identification","term_url":"https:\/\/beaglebay.com\/duinogear\/docs-category\/object-id\/"}],"doc_tag_info":[],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/beaglebay.com\/duinogear\/wp-json\/wp\/v2\/docs\/2652","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/beaglebay.com\/duinogear\/wp-json\/wp\/v2\/docs"}],"about":[{"href":"https:\/\/beaglebay.com\/duinogear\/wp-json\/wp\/v2\/types\/docs"}],"author":[{"embeddable":true,"href":"https:\/\/beaglebay.com\/duinogear\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/beaglebay.com\/duinogear\/wp-json\/wp\/v2\/comments?post=2652"}],"version-history":[{"count":1,"href":"https:\/\/beaglebay.com\/duinogear\/wp-json\/wp\/v2\/docs\/2652\/revisions"}],"predecessor-version":[{"id":2653,"href":"https:\/\/beaglebay.com\/duinogear\/wp-json\/wp\/v2\/docs\/2652\/revisions\/2653"}],"wp:attachment":[{"href":"https:\/\/beaglebay.com\/duinogear\/wp-json\/wp\/v2\/media?parent=2652"}],"wp:term":[{"taxonomy":"doc_category","embeddable":true,"href":"https:\/\/beaglebay.com\/duinogear\/wp-json\/wp\/v2\/doc_category?post=2652"},{"taxonomy":"doc_tag","embeddable":true,"href":"https:\/\/beaglebay.com\/duinogear\/wp-json\/wp\/v2\/doc_tag?post=2652"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Object Identification<\/h3>\n\n\n\n
UID – the Uniform Identifier<\/h3>\n\n\n\n