User Tools

Site Tools


public:cbuspublic:start

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
public:cbuspublic:start [2020/01/22 15:30]
grovenor [Identifiers]
public:cbuspublic:start [2020/01/22 19:17] (current)
grovenor [CBUS Documentation]
Line 1: Line 1:
 ===== CBUS - A universal layout control system ===== ===== CBUS - A universal layout control system =====
-[[public:​cbuspublic:​docindex|Documentation]]\\  +
-[[public:​cbuspublic:​schema|Schema files]]\\ ​+
 [[:​public:​start|Index to other public Wiki pages]]\\ ​ [[:​public:​start|Index to other public Wiki pages]]\\ ​
 ==== Introduction ==== ==== Introduction ====
-CBUS is a Layout Control System running on the [[wp>​CAN_bus|CAN]] (Controller Area Network). A description of the system can be found on our public webpages. +CBUS is a Layout Control System running on the [[wp>​CAN_bus|CAN]] (Controller Area Network). A brief description of the system ​and available kits can be found on our public webpages. 
-cbus.php and cbus2.php+  * **[[https://​www.merg.org.uk/​merg_resources/​cbus.php|CBUS]]** ​and  
 +  * **[[https://​www.merg.org.uk/​merg_resources/​cbus2.php|CBUS2]]**  
 + 
 +A complete description of CBUS including the full specification and implementation notes is contained in the '​Developer'​s Guide',​ see link below.  
 +   
 + 
 + 
 +===== CBUS Documentation ===== 
 +This is the public view of CBUS and does not include MERG Technical Bulletins (TBs) or links to any other MERG Copyright material which is available only to members. 
 + 
 +[[developerguide|CBUS Developers'​ Guide]]\\  
 +This Guide is intended for those with technical knowledge wishing to develop additional hardware, software and firmware for use with CBUS. It also provides all the technical background and information to enable a better understanding of how CBUS works, along with the rationale for our choices and methods.  
 + 
 +[[jmriacccmd|Commanding Accessory Decoders using CANCMD & JMRI]] 
 +This description shows how to use CBUS events to operate DCC accessory modules via the CANCMD.
  
  
  
-{{  http://​mergcbus.sourceforge.net/​cbus.png?​100|}} 
  
  
-===== Message Formats ===== 
-   ​General format is 8 bytes: { opcode, optional data }  
-      Where the opcode informs the receiving node what to do, using the data as necessary.  ​ 
-      There are many opcodes, including: 
-         - On-Events and Off-Events 
-         - Train control, including programming 
-         - Node configuration 
-   Long Event format is:  { opcode, [node-id(2).event#​(2)] },  
-      Where the concatenation [node-id.event#​] is considered to be one 32-bit event. 
-   Short Event format is: { opcode, node-id(2), device#(2) },  
-      Where node-id and device# are independent. The device# is considered a '​short-event'​ or device#​. ​ 
-      More than one node can send this event, e.g. throttles, and it will have the same effect.  ​ 
-      By convention, device#s 1-9999 denote '​action'​ events; 10001-19999 the matching denote sensor events; 
-      and device# 10000 the `Start-of-Day'​ (SoD) event.  ​ 
-        ​ 
-      The reason for this partition is that CABs can send short events up to 9999 and it would not be 
-      advisable for these to clash with sensor events by mistake. 
     ​     ​
 ===== Tools: ===== ===== Tools: =====
Line 37: Line 32:
   * **SSI** (Solid State Interlocker) from [[http://​www.gppsoftware.com/​|GPPSOFT]]:​ A complete layout control system following British signalling and control practice.   * **SSI** (Solid State Interlocker) from [[http://​www.gppsoftware.com/​|GPPSOFT]]:​ A complete layout control system following British signalling and control practice.
  
-===== Implementation Notes ===== 
- 
-  * CBUS operates over CAN at 125kbps. 
-  * CAN is bidirectional and has built-in error correction and message re-send. 
-  * CBUS CAN frames have an 11-bit header and an 8-byte data-part.  ​ 
-    * The data-part carries the CBUS message.  ​ 
-    * The header must be unique, and this is ensured by including the 1 byte CAN-ID assigned to the sending node.  
-  * The CAN-ID is retained by the node, moving it to a new layout may cause a CAN-ID conflict. ​     ​ 
-  * In SLiM mode, the node-id is set by switches, and the CAN-ID is set equal to the low-byte of the node-id.  ​ 
-  * In FLiM mode, if the node does not have a CAN-ID, one is automatically obtained by self-enumeration:​ the node asks all other active nodes for their CAN-ID, and then assigns itself one that is not in use.  
-    * NB: New modules //must// be introduced to the bus one at a time.    ​ 
-  * The CAN-ID may be re-assigned:​ manually by a double push of the node's pushbutton; or by using the FCU.  ​ 
-  * CBUS uses 29-bit header CAN messages for bootloading.  ​ 
-  * A complete description of CBUS including the full specification and implementation notes is contained in     the '​Developer'​s Guide' which can be downloaded from  {{ :​public:​cbuspublic:​developer_6b.pdf |}} See also the '​documentation'​ link at the top of this page. 
-  ​ 
  
public/cbuspublic/start.1579707028.txt.gz · Last modified: 2020/01/22 15:30 by grovenor