Making the case for CAN
This article was originally written in the period 1995-2000
Brian Webb, Managing Director of Infranor, explains how CAN was adapted to servo drives.
Fieldbus control potentially offers reduced wiring, improved reliability and better accuracy. Fieldbuses can be likened to a network between PCs, but complicated by the industrial environment and the large range of devices which have to be addressed.
At present, there are many competing bus systems, each with their own features. Many of these are proprietary and are heavily promoted by one manufacturer or group, with the intention of holding the customer captive to one associated range of equipment.
Some OEMs have already stated that they will be using one or other system, often without realising the restrictions or cost penalties of their course of action. In reality, it is probably far too early to put all the eggs in one basket.
One big disadvantage of most fieldbus systems is that all the components have to be intelligent. This at a stroke increases the cost of all sensors and I/O devices. But the big plus of fieldbus is the ability to hang another device on the end of the line, just by linking with one piece of wire to the nearest device when another sensor or input is needed.
A main consideration for Infranor, when deciding which bus system to use for its drives, was to make it as open as possible. We opted for a CAN-based protocol. However, this does not preclude communication with other bus systems. Several manufacturers have produced interface communications products to allow messages to be passed from one to the other.
An advantage of CAN (Controller Area Network) is that it is not a prisoner of a single large manufacturer. Neither is it a master/slave bus system – any node can be configured by software. The final thing that gives it the edge is that is has the lowest cost of physical connection and has low electronic component costs, with several manufacturers of silicon integrated circuits already in volume production.
CANbus has been around for some time, but the available protocols (DeviceNet, CDC) tend to be geared for communication with sensors and I/O devices, rather than drives.
CAN was developed by Bosch for the automotive industry. The first ISO standards were issued in 1988. In 1992, the CiA (CAN in Automation) group was founded to synchronise and standardise the different opinions and views in the CAN network system.
Adapting the system to digital servo control was always going to be difficult because of the quantity of data traffic between the controller and the drive. There is no final standard agreed in the CiA group, but some manufacturers have produced their own, based upon the latest information. It appears that there could be a separate standard for servo control, running alongside the other proprietary protocols. The NC/Motion controller would then have two CAN channels, one for servo and the other to connect to PLC, sensors and I/O. keypads, etc.
A CAN-based servo solution is now available from Infranor and has already been adopted by four NC/motion controller manufacturers in Europe. To get the data transmission speed necessary and to keep the bus traffic down, it is essential that the position loop is closed inside the drive every 500µs, thereby reducing the bus traffic and achieving a 2ms update time on the bus, for up to eight drives at a time.
This means that linear and circular interpolation over the bus is now possible. Although this was the main design aim, in practice the main interest has been in the communications aspects, with machine builders wanting to give and receive information from the drive – typically speed, torque (current) and status information. By having this information at the man-machine interface (MMI), it is possible to monitor the process to detect errors before failures occur. For example, by monitoring the torque of a drive, a blockage or break may be avoided if a sudden rise is detected. Stopping the machine before a serious failure happens can save a fortune in downtime. Future developments should allow more of the motion profile to be generated within the drive for simple repetitive movements.
Another by-product should be greater accuracy, as the drive is now being sent a numerical signal that is less susceptible to electrical noise.
In the future, we may some more useful software features – for example, when a drive is added it could send a signal to the controller announcing and identifying itself, including parameters, such as current rating and present settings. The controller would then give the user the option of invoking the set-up program to tune up the drive.
If a drive is replaced, all the user need do is power down the machine, replace the drive and then power up the machine again. All the drive settings are held on the host controller and are re-transmitted to each drive on start-up, thus removing the need for an end user to get involved in using special equipment or software.
Tel: 01403 223500
Fax: 01403 241268
Contact: Brian Webb (Managing Director)