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:24]
grovenor [Hardware requirements of the BUS]
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 ​based on the CANBUS. 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]]** ​
  
-==== The messaging scheme. ==== +complete description ​of CBUS including ​the full specification ​and implementation notes is contained ​in the '​Developer'​Guide'see link below.  
-After much debate, we settled on the ‘producer-consumer’ model at least for layout control. For those used to the idea of sending specific messages from to B – a ‘source-destination’ scheme, this is a very different concept although widely used for industrial control systems. Imagine changing a switch on a control panel. This creates an ‘event’. A frame is sent on to the bus which contains no source address, no destination address, no information,​ just an ‘event’ number. The node sending an event is called a ‘producer’. All nodes capable ​of processing an event are ‘consumers’. Every consumer on the layout receives the event. What the consumer does with the event will depend on information already in the consumer. In effect, a consumer has to be taught what to do with any event it has to act on and to ignore events that are not relevant. +  
-This is an extremely powerful and very flexible arrangement. Producers can send many events. Many consumers can act on an event and in different ways. Consumers can also act in the same way for different events. CBUS is a ‘one to many’ scheme which means that a specific event number will be restricted to one producer only. +
-The above description may seem rather abstract. Here is a recognisable example. You want a push button (PB) on a control panel to set a route and the corresponding signals. You have a producer node on the control panel. You have a number of consumer nodes that drive turnouts and signals. Let’say the PB creates event number 1. Turnout controller A has been taught that event 1 means set turnout 1 to normalturnout 2 to reverse. Turnout controller B has been taught that event 1 means set turnout 3 to reverse, turnout 4 to reverse and turnout 5 to normal. Signal drivers C and D have been taught that event 1 means set the various signals or aspects for that route. Pressing the one PB sets the route and all the signals in one go. Obviously, a different PB could send event 2. The various consumers would know to act on event 2 in a different way to event 1 so set a different route+
-With this P-C model, you have effectively transferred some of the decision making from the producer to the consumer. It still allows for computer control or assistance, such as interlocking,​ if the PC or other interlocking system is placed between the original producer and the final consumer. Now, the switch event is recognised by the PC (as a consumer) and when a decision has been made, the PC sends another event (as a producer) to the final layout consumers. Items like block occupancy detectors are producers of events so a PC can know if a block is occupied. +
-While full PC operation is easily accomplished,​ it is equally easy to configure quite complex layouts without any ‘programming’ at all. The latter will be described in our small layout implementation model (SLiM).+
  
-As a result of experience with '​real'​ layouts, we have since introduced an alternative to the P/C scheme, called '​device addressing'​ or 'short events'​. While the message format remains the same, layout '​devices'​ are given numbers by the user. The range is a two byte number or 1 to 65535. This allows a number to be associated with an actual layout device such as a turnout or switch rather than an abstract 4 byte value set by the node (as in the P / C scheme). An advantage of this method is where a CAB sends messages to turnouts by turnout number and any CAB can activate the same turnout, route, signal etc. Also layout sensors have numbers so the control panels, PCs etc. can know where the message came from. In the jargon. this gives a 'many to many' capability which fits well with computerised schemes like JMRI and, conceptually,​ is easier to understand. It does need a way of teaching the '​device number'​ though and for this we have a comprehensive configuration utility (the FCU) which runs in a Windows environment and connects to the layout via our CANUSB4 interface or wirelessly via our CANPiWi module. 
  
-{{  http://​mergcbus.sourceforge.net/​cbus.png?​100|}} +===== CBUS Documentation ​===== 
-===== CBUS in Brief ===== +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. 
-This is a short overview, mostly useful ​to someone generally informed in the area, and wishing ​to understand specific details about CBUS.+ 
 +[[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 worksalong 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. 
  
-CBUS is a local area bus designed for model railways and it is used for the control of layout accessories and DCC trains. The message is entirely self contained and independent of any transport used. It is currently specified to run over [[wp>​CAN_bus|CAN]] (Controller Area Network). This three wire bus system is widely used, notably in many cars and trucks. 
  
-A CBUS installation consists of a number of '​nodes'​ which send messages to each other. ​ It uses the '​Producer-Consumer Model' and '​events'​. ​ Some change on the layout will trigger a '​Producer'​ node to send an event-message to a '​Consumer'​ node, which then causes some action to take place. ​ For example, a occupancy detector causes the node to which it is connected to send an event-message. ​ This message is received by another node which controls a signal, and causes the signal to display Red.  ​ 
  
-In situations where the Producer / Consumer model is inappropriate,​ CBUS has an alternative '​device addressed'​ mode. Here each device on a layout is given a unique number in the range 1 to 65535. Both producer devices and consumer devices can have the same number, e.g. a switch controls a turnout, both would share the same number. This scheme gives a lot of flexibility and is suited to PC control, and where there are multiple '​producers',​ like CABs, which control layout devices such as turnouts or routes. 
-===== Identifiers ===== 
  
-  - **Nodes** are the basic unit of CBUS, and each is usually implemented on one PCB. Node-ids are 16-bit, and are assigned by the user. 
-  - **Event** messages are sent by '​Producer'​ nodes and received by '​Consumer'​ nodes to cause some action. ​ Event-numbers are assigned by the user, and are one of two kinds: 
-    * Short-event:​ 16-bit device# 
-    * Long-event: 32-bit, made up of the concatenation of a node-id and a 16-bit event#​. ​ 
-    * They are distinguished by the opcode of the message. ​ Each is further qualified as an '​On'​ or '​Off'​ event by that opcode. 
-===== 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 57: 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.1579706696.txt.gz · Last modified: 2020/01/22 15:24 by grovenor