Catching the right bus

Nick McNamara of Arcom Control Systems offers help to system design engineers faced with a wide choice of computer bus types

When designing a machine control system, there are a number of key decisions to be made about the fundamental architecture of the control system. In the past, developers of machine/processor controllers built systems based around PLCs. However, the largest growth area over the last five years has been the use of open-bus PC-style embedded computers. Distributed I/O and control via field bus networking technologies have also come to the fore, including Profibus, WorldFiP, DeviceNet, or Interbus-S. The choice of fieldbus is a balance between reduced or simplified machine wiring, component modularity, improved maintenance and diagnostics.

By far the greatest growth area continues to be systems using DOS (or ROM-DOS). The use of DOS has been a natural incremental step for many systems which previously used a selection of target code based micro-controllers which must retain a strong element of determinism in the code.

Although real time extensions for Windows and the selection of real time operating systems provide these features, there is a significant initial investment in product knowledge and on-going license cost.

Many people use PCs in their application due to their low cost. Another attraction is the large amount of readily available development tools for software design, such as MS Basic and Visual C++. Microsoft claims that there are already 50 million programmers world wide who work using the Win 32 API programming model, a code development standard supported by many vendors.

As standards in desktop PCs have moved forward, so have embedded systems. In such systems, a passive backplane is used for data communication between CPU and peripheral boards (or cards) on a bus. The backplane also carries any voltage supplies and necessary ground connections. Since the electrical connectivity of the PCbus standard is fixed, the differences between PC-buses include the format of the board, size of the data bandwidth (8, 16 or 32bit) and physical connection to the bus.

Standards such as the 16-bit ISAbus and the 32-bit PCI bus have been developed and are widely used. However, the edge connector is not always suited to harsh environments such as high temperature or vibration.Recently, a Eurocard version of the PCI bus, the Compact PCI, was announced to address this issue ( Design Engineering, October 1998, p.15).

Another range of embedded CPU and I/O boards have been designed around the 16-bit ISAbus standard called PC/104. Originally developed by Ampro in the US, the bus is now governed by an independent group – The PC/104 Consortium.

Whereas a typical, but not specified, size of ISAbus is 300mm by 120mm, PC/104 uses a much smaller, compact format of 96mm by 90mm. This size of `module’ makes for a more compact implementation of ISAbus satisfying the need to reduce space and power for embedded applications without minimising the flexibility of using PC based micro-controllers in applications.

Unique to PC/104 is its bus interconnection scheme. PC/104 uses a stacking two-part connector scheme which eliminates the need for an independent passive backplane, reducing space requirements and card fixing arrangements. The power supply is typically supplied by the base motherboard. In most cases this is a Single Board Computer. As more extension modules are added (or stacked), data, power and ground signals are passed through the inter-stacking connectors.

Sons of canbus

Using PC/104 modules, it is relatively easy to add a CANbus interface with a basic set of functions to allow the transmission and reception of CANbus packets. Since its introduction by the automotive industry, CANbus has proliferated a number of standard protocols such as DeviceNet, CanOpen and SDS. All of these exploit the inherent features of CANbus which offer simple wiring, high transmission reliability and deterministic response times.

DeviceNet is commonly operated in a master/slave architecture; a master control PC is able to effectively communicate with a number of intelligent embedded PC slave units. The slave units are then able to independently control time-critical elements of the machine control, whilst reporting status and maintenance conditions back to the master controller.

DeviceNet software toolkits allow application developers to utilise the features of DeviceNet without having to deal with the finer details of the protocol. Toolkits are available as `C’ library functions to implement the `master’ and `slave’ ends of the DeviceNet link separately. This not only allows PC/104-based embedded PCs to be linked together, but also allows developers to exploit the range of other third party factory floor and machine sensor devices available.

The use of CANbus by DeviceNet inherently supports the mode of producer/consumer where a producer of control messages issues a `multi-cost’ message to all consumer nodes; so a message to, for example, `start process’ can be simultaneously received by several intelligent nodes which can then begin their independent activities.

DeviceNet supports both high priority real time messages and, separately, a lower priority configuration message. It also offers all the necessary types of I/O data interchange such as master/slave, peer-to-peer, polling, cyclic (time based) and change of state (such as limited switch triggers).

Many useful sites for developers are on the Web. These include the PC/104 Consortium at http://www.pc104.com, Arcom at www.arcom.co.uk, The Open DeviceNet Vendor Association at http://www.odva.org, and the CAN In Automation Group at http://www.can-cia.de.