public:cbuspublic:start
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
public:cbuspublic:start [2020/01/22 15:29] – [CBUS in Brief] grovenor | public:cbuspublic:start [2022/06/25 16:39] (current) – removed grovenor | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ===== CBUS - A universal layout control system ===== | ||
- | [[public: | ||
- | [[public: | ||
- | [[: | ||
- | ==== Introduction ==== | ||
- | CBUS is a Layout Control System running on the [[wp> | ||
- | cbus.php and cbus2.php | ||
- | |||
- | |||
- | |||
- | {{ http:// | ||
- | |||
- | ===== 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 ' | ||
- | * Short-event: | ||
- | * 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. | ||
- | ===== Message Formats ===== | ||
- | | ||
- | 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# | ||
- | Where the concatenation [node-id.event# | ||
- | Short Event format is: { opcode, node-id(2), device#(2) }, | ||
- | Where node-id and device# are independent. The device# is considered a ' | ||
- | 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 ' | ||
- | and device# 10000 the `Start-of-Day' | ||
- | | ||
- | 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: ===== | ||
- | |||
- | * **[[cbus_flim: | ||
- | * **[[http:// | ||
- | * **[[http:// | ||
- | * **SSI** (Solid State Interlocker) from [[http:// | ||
- | |||
- | ===== 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: | ||
- | * NB: New modules //must// be introduced to the bus one at a time. | ||
- | * The CAN-ID may be re-assigned: | ||
- | * 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 ' | ||
- | | ||
public/cbuspublic/start.1579706993.txt.gz · Last modified: 2020/01/22 15:29 by grovenor