public:cbuspublic:start
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
public:cbuspublic:start [2020/01/22 15:24] – [Introduction] grovenor | public:cbuspublic:start [2020/01/22 15:26] – [The messaging scheme.] grovenor | ||
---|---|---|---|
Line 6: | Line 6: | ||
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 based on the CANBUS. A description of the system can be found on our public webpages. | ||
cbus.php and cbus2.php | cbus.php and cbus2.php | ||
- | ==== Hardware requirements of the BUS ==== | ||
- | **The choice of CAN.**\\ | ||
- | The CAN bus (Controller Area Network) was developed by the Robert Bosch company in the 1980s for use in motor vehicles but has since been applied to many other types of machinery including aircraft and medical scanners to name just two. It became an open international standard as ISO 11519 in 1994 and a higher speed version as ISO 11898 in 2003. It is now used in virtually all modern motor vehicles so there is a wide applications base and ‘off the shelf’ components are readily available. When we looked at CAN, it seemed pretty much the ideal for a LCB. It was intended for relatively infrequent transmission of small amounts of data between devices for control purposes where response times and safety were paramount. Unlike the more familiar ‘Ethernet’, | ||
- | The data rate chosen for CBUS is 125Kbps. This is one of the defined CAN rates which go up to 1 Mbps but there is a trade off against cable length. 125Kbps allows lengths of up to 500 metres, good enough for even most garden layouts. The wire should be a twisted pair but doesn’t need to be screened. Only the ‘standard’ CAN frame is used. | ||
- | ==== The messaging scheme. ==== | ||
- | 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 A 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, | ||
- | 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’s say the PB creates event number 1. Turnout controller A has been taught that event 1 means set turnout 1 to normal, turnout 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, | ||
- | While full PC operation is easily accomplished, | ||
- | As a result of experience with ' | + | |
{{ http:// | {{ http:// |