Layout
Control Bus (CBUS) Resources Page
Contents
Mike
Bolton and Gil Fuchs, from November
2007
©
Updated 16 January 2010.
|
 |
Copyright
for items on this page
is retained by the authors identified.
The
use or misuse for the sale, design, supply, process, installation,
delivery, test, repair, servicing, and alteration of the designs,
instructions, computer code, photographs, circuits, and any other
information that appear on this web site is entirely at the risk of the
user or visitor to the web site. The information is made available in
good faith without warranty of any kind strictly on the basis that no
liability will attach to the Model Electronic Railway Group (MERG), its
officers and members.
These pages are a resource area for projects members are working on or
have completed and wished to make publicly available. Some of
these
projects have resulted in MERG kits but nothing on these pages should
be taken as definitive information about the kits, members should check
the kit pages for up to date information on the kits.
CBUS – A universal
layout control system.
CBUS is the product of
over 4 years
development by MERG members Gil Fuchs and Mike Bolton. CBUS has gone
through many stages of evolution and refinement including some major
changes in direction but we are now at version 4 and feel it is
sufficiently developed to formally introduce the scheme, not just for
MERG members but the world at large.
Our intention was to
develop a system
for comprehensive layout control based on a general purpose Layout
Control Bus (LCB). The fundamental tenet was that of
‘simplicity’ without sacrificing
‘universality’
– a difficult juggling trick. It had to be affordable and
easy to
install and set up by non-technical users. It also had to cover the
range from small, simple home layouts to the largest and most complex
club layout imaginable. Whether we have achieved this will only be
resolved from subsequent experience.
So what are the
functions of a layout control system. You can divide these into two
basic categories.
1.
Control of devices (outputs)
2.
Detection of ‘states’ (inputs)
Examples of (1) are
changing turnouts
(points), signals, power to block sections, turntables, level crossing
gates, layout lighting, setting routes, controlling the speed and
direction of locomotives (by DCC or analogue DC) and any other
electrical or electro-mechanical devices that may be on a layout.
Examples of (2) are
control panel
switches, block occupancy detectors, bar code or RFID readers, turnout
direction sensors, turntable position and
‘RailCom’™
track detectors.
At the basic level, we
wanted our
system to both look and operate like a conventional ‘hard
wired’ system having a control panel with switches to operate
turnouts and simple route setting. It also had to allow use as a
‘CAB bus’ for DCC systems so handsets (CABs) could
be
connected to a DCC command station using the same wiring. At the other
extreme, it had to allow full computer control, using multiple
computers if necessary, and a fully automated layout with many
thousands of inputs and outputs. Although it is early days, we feel we
have achieved these aims, in principle at least.
So far, I have referred
to it as a ‘system’. The CBUS system can be
regarded in two parts.
1.
The hardware
2.
The messages
The two are not
completely
independent as the style and frequency of the messages is determined by
the hardware capability. However, I will describe them separately.
Hardware
requirements (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’, it
was not
intended for shipping large amounts of data between computers. Another
advantage of CAN was that it was already in use for a LCB by Zimo, so
there was proof it worked in a model railway environment.
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, 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. I will use 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, 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).
Scope of CBUS for layout control.
A CBUS message
consists of a
‘command’ byte and an ‘event
number’. The
command byte is used to set the number of bytes in the message and
define the type of event. For layout control we only use at present an
‘ON’ event and an ‘OFF’ event
but for CAB bus
implementation, a number of other ‘commands’ are
also used.
As nodes need to know how to respond to an event, there needs to be a
mechanism for teaching them. Each programmable node is given
a
node number (NN) of 16 bits or two bytes. If nodes are to be unique,
the maximum number of nodes is 65536 or 64K. Each producer node is
allowed a further 16 bit range for its events giving a possible 4.29
billion events! The actual event number in a message is comprised of
the node number and the node event so the final event is a 32 bit
number. This allows events to be traced to a particular node as well as
preventing accidental duplication of events from different nodes.
Providing a consumer is
a
‘receive only’ device, there is no limit to the
number of
these. In our SLiM model, such consumers are taught using on-board
switches so a node number is not required.
However, there are other
limits for
the number of nodes set by the CAN bus requirements. Each node requires
a CAN transceiver IC which drives the bus with the CAN information.
Currently available transceivers set a limit to the number of nodes on
a bus ‘segment’ to 110.
One of the features of
CBUS is the
complete separation of the message from the
‘transport’.
Where more than 110 nodes are wanted, we can use repeaters that link
different CAN segments. All that is sent between segments is the
message (command and event) so each segment may have duplicate CAN
frame arbitration headers. Given enough repeaters (CAN-CANs), the node
limit is set at 65536 by the CBUS protocol.
Figure 1 shows a
simplified
arrangement for a layout control scheme and figure 2 shows a CAB bus
arrangement. The actual bus wiring is common to both.
CBUS implementation – the SLiM
model.
The thinking behind the
SLiM
(Small Layout Model) was for a collection of modules for layout control
that needed no programming and no programming device. A layout could be
configured using just switches on the modules. This has been
implemented so far for the following modules:
1.
An 8 input switch / logic level detector (CANACE8C), this node can generate an event corresponding to its input states in
response to a ‘request’ event (which
will be useful for interlocking and reading logic levels or switch
positions).
|
2.
An 8 output relay / lamp / logic driver with adjustable voltage (CANACC8).
 |
3.
A solenoid turnout driver with 4 output pairs and a CDU (CANACC4).
 |
4.
A motorised turnout driver with 4 output pairs and adjustable voltage (CANACC5).
|
5.
A control panel encoder for either 128 toggle switches or 64 pairs of
pushbuttons (CANACE3).
|
6.
A CAN to RS-232 interface. Allows full operation of CBUS from
a PC (CAN_RS). Test software for use with the RS module also available. Alternative version available for USB connection (CAN USB).
 |
|
7. A LED driver for 64 LEDs (CANLED)
 |
|
The novel aspect of the
SLiM CBUS system is the way the nodes are ‘taught’
how to respond to an event.
The producers are
provided with DIL
switches which set their Node Number. The panel encoder has a two way
switch, allowing 4 control panels on a layout. The switch input node
has a 4 way switch allowing 16 such nodes, each with 8 inputs. Note,
these are only hardware design constraints and not intrinsic to CBUS.
The only requirement for these producer nodes is that no two may have
the same number. The actual number is irrelevant. These producer nodes
create events numbered according to their inputs as the lower two
bytes. The upper two bytes of the 32 bit event are the node number.
The SLiM consumers do
not have a node
number. They have a DIL switch to select an output, a
‘learn’ switch, an ‘unlearn’
switch and a
‘polarity ‘switch. To link an output with an input
event,
the following sequence is followed. The nodes are connected to the bus
and powered up. One (or more) consumer nodes are put into
‘learn’ mode with their switches and the output to
be
associated with an event is selected on each with the DIL switches. For
the presently working turnout drivers, there are 4 outputs, for the
relay / LED driver there are 8 outputs. The input on a producer is
activated (say a control panel pushbutton) and it sends an event. The
consumers remember this event and activate their outputs. You can check
if the action is what you wanted. The action can be repeated as many
times as you like. If satisfied, you take the consumers out of learn
mode. All subsequent events with that event number will cause the same
output actions.
Currently, each event
can be either
ON or OFF while still having the same event number. This allows an
input ON/OFF switch to be regarded as a single event producer. The
purpose of the ‘polarity’ switch on the consumer
nodes is
to allow an output to work in reverse relative to the event. If this
switch is set while learning, the output action is reversed.
Apart from its use in
setting routes,
where some outputs need to be set and some cleared with the same event,
it also allows different outputs on the same consumer to act in
opposite directions. Thus two outputs can be
‘toggled’ with
one event. Also, if using the 8 output driver, you can set multiple
aspect signals to have a different aspect for each event –
256
possible combinations.
The present designs
allow each
consumer node to remember 16 different events but this number can
easily be increased. You can add outputs on a node to an event and also
change the polarities. You can completely remove an event from a
consumer by setting both the learn and unlearn switches and then
sending the event.
The possible
permutations and
combinations, even with this very simple scheme, are endless, ranging
from a single control panel switch operating a single turnout to
pushbuttons on different control panels setting the same complex route.
If the turnouts are equipped with sensors (microswitches etc), these
can be fed to a producer such as the 8 input node to create events to
confirm turnout operation. In turn these events may switch lights on a
control panel via a LED driver module. A block occupancy detector with
a logic level or ‘open collector’ output can create
events
via an input producer module. Here it would create an ON event when the
block became occupied and an OFF event when cleared.
The SLiM scheme does not
need any
programming device. The user doesn’t need to know any node or
event numbers. The only requirement is that no two producer nodes
should have the same node number. The SLiM scheme presently limits the
number of producer nodes to 255. There can be any number of consumer
nodes in principle but the CAN bus transceivers will only allow 110
nodes total on a single segment. Inter-segment bridges (CAN-CANs) are
in development.
In addition to layout
control, the
same bus can be used for connecting handsets (or CABs) to DCC command
stations or even to DC power systems. A complete DCC CAB / Command
Station system is in development. For DC systems, the relay driver
modules are especially useful for block switching.
While the above
describes our SLiM
(Small Layout Model) of CBUS, the principle is being expanded to the
‘Full’ model (FLiM) where all nodes / modules will
be fully
programmable over the same CBUS. This is intended for computer control
of layouts and will allow a
maximum of 65535
individual nodes. As
the message structure and format will be the same for both SLiM and
FLiM, there will be an easy upgrade path from SLiM to FLiM and both
types of module will work together.
Full technical
information will be
posted as soon as possible, together with schematics and complete
constructional details, including PCB layouts for the various modules
following successful ‘beta’ testing.
CBUS Modules and downloads
The files below give all the info. on the currently working / tested set
of layout control modules. The text description and schematic of
each module are linked as .pdf files for easy reading. The zip file
contains these plus the board layout and the firmware so you can get
the complete package for any board you want to build in one go.
The installable package for the test software is listed under the CAN_RS module below.
The PIC code for the CANACC5 is the same as for the CANACC8, hence no separate asm or hex files for the CANACC5. The only difference in these modules is the output stage.
The schematics show a Microchip MCP2551 CAN transceiver, an 82C250 can be used as a direct replacement if you have them available.
Note:
The PCB layouts, schematics and software updated on May 4th 2008, check you have the latest versions before building. These updates now correspond with the first batch of boards supplied by the MERG kitmaster in April 2008. The software has been further updated in January 2010, latest versions are in the downloads below.
| Module |
Description |
.zip Download of text, schematic,
board layout and firmware. |
| CAN_RS |
CBUS to RS232 interface to allow connection to PCs etc.
Test software for to install on PC, zip package, works with CAN_RS and CAN_USB, updated 16/01/10.
Test software instructions.
|
CAN_RS.zip
updated 16/01/10
|
| CAN_USB |
CBUS to USB interface to allow connection to PCs etc.
Test software for to install on PC, zip package, works with CAN_RS and CAN_USB, updated 16/01/10.
Test software instructions
|
CAN_USB.zip
updated 16/01/10
|
| CANACC4 |
CBUS driver for 4 solenoid point motors, includes CDU.
|
CANACC4.zip
updated 16/01/10
|
| CANACC5 |
CBUS driver for 8 on/off higher current outputs (eg 4 Tortoise, Lemaco or Fulgurex etc. point motors) |
CANACC5.zip
updated 16/01/10
|
| CANACC8 |
CBUS driver for 8 on/off low current outputs (eg. relays or LEDs
|
CANACC8.zip
updated 16/01/10
|
| CANACE3 |
CBUS module for panel switch inputs, up to 128 switches.
|
CANACE3.zip
updated 16/01/10
|
| CANACE8C |
CBUS module for 8 general purpose inputs, eg Track occupancy or point position detectors.
|
CANACE8C.zip
updated 16/01/10
|
| CANLED |
CBUS module for driving 64 LEDs, eg Panel indications or signal aspects. |
CANLED.zip
updated 16/01/10
|
Mike
Bolton and Gil Fuchs, from November
2007
©
Contact
Information
Anyone wishing
to have this information in advance of a final version or have any
additional queries may email me at
Copyright to all information on these pages is held by the Authors
identified.
