The term bus is extremely general in the electrical engineer’s parlance. It is a synonym for wires or conductors. The wires that carry power around your factory, office, or house are a power bus. The wires that carry your telephone conversation are a communication bus. Most of the peripheral devices connected to a PC communicate with the processor through an internal, digital, parallel data bus. That bus has about 50 different conductors. A data bus provides a universal means of two-way communication among machines.
The bus now confronting everyone in industry is the digital, high speed, two-way, serial data bus, which, in principle, needs only two wires. The serial bus comes in a variety of “flavors,” or protocols — each with its advocates and critics, and each vying for dominance. That lack of a single dominant industrial bus standard makes the task of designing machinery that interfaces with any given protocol all the more difficult. The personal computer industry has taken the lead in bus technology by making computer speeds ever greater. The most common is the USB serial connection where the USB 3.0 is capable of transferring data at 625 Mb/sec.
Bus benefits
Why do we want buses and bus technology? Bus technology forces users to think in terms of two-way communication among all devices on the network. The data regarding the status and condition of any device, machine, or process can be accessed in seconds or minutes. It is well documented that networks reduce the amount of wiring needed to implement a machine-to-machine communications system. The mobile equipment industry has standardized on the CAN bus and reports great reductions in the amount of wire needed to connect their increasingly complex electrical and electronic systems. The data reported back to the main input/output connector offer valuable aid at troubleshooting time.
Bus technology can minimize the woes of startup because all networked processes and machines on the factory floor are almost inherently synchronized. Debugging times in the face of problems are reduced because so much information is available that the specific malfunction can be pinpointed in a logical way and often, very quickly.
The bus industry uses the term device to denote a final point in the bus structure. The bus may begin at the device or end at the device, depending on point of view. For example, a device might be a pressure sensor, valve, or a pump outfitted with multiple sensors. The other end of the bus may be a master control computer or command center that accumulates and processes production and performance data from the many devices.
Each device added to a bus must conform to the standards that define the specific bus. Simply stated, each device must be equipped with interfacing circuits that allow communication to take place. Whereas the master control computer oversees the long-term trends of the system or enterprise, the devices manage more immediate, instantaneous events, perhaps millisecond by millisecond, or even faster.
Arguably, the most important issue with buses is their two-way communications capability — the command center can send information to a device or sub-system, and the device can send information back to the command center. In shop floor jargon, we say the “devices talk to each other.” By implication, then, they also listen to each other. The upshot is that set up can be simplified because a new device, when properly configured and supported with control software, will tell the command center what it is and also send key parameters and calibration factors. In our personal computers, this is referred to as “plug and play.” An external hard drive and printer are examples of such devices and the computer is the command center.
Hardware for bus communication
Every manufacturer of hardware for use on the factory floor or in a vehicle must ask two questions (there are countless more, but these may be new to the fluid power community):
1. What input command signals are needed to adequately control the device that we manufacture?
2. What sensing devices must be on board my product(s) to enable them to adequately express their presence, status, and condition back onto the bus?
The first question is relatively simple to answer, especially if the device is an electrohydraulic machine that listens to electronic commands. Such devices are servo and proportional valves, electrohydraulic pressure- and flow-control valves, and electrically stroked pumps and motors. The servovalve, for example, needs a bus interface circuit that receives its digital command signal from the bus and converts it to an analog signal. The analog signal requires a power amplifier to supply the drive current to the valve’s torque motor. Similar assessments will lead to the necessary interfaces for the other kinds of devices.
The answer to the second question is more elusive. First, machine manufacturers must define what data about their machines will satisfy the future needs of bus users. For example, should a cam angle sensor be used on the variable-displacement mechanism of an electrically stroked pump or motor, or will a speed sensor suffice? If an output pressure transducer is required, will there also be a need for an inlet pressure sensor?
The answer certainly is yes to the second question if the pump will have an electronic pressure compensating mode rather than the conventional hydromechanical one. Will case temperature and case flow sensors be necessary if the pump’s condition is to be automatically determined by an interrogating computer? Should output flow be measured for control, diagnostics or both? How can standard products be modified to allow adding specific sensing options without adding cost to the product?
Good math models of some devices can be used to reduce the number of sensors. For example, the displacement of a motor may be inferable from its speed and the pump’s displacement when the internal leakage can be estimated from the model. If so, the motor does not need a displacement-measuring transducer.
A limiting factor on industrial buses is their speed of response, referred to as bandwidth. Some of these buses are Controller Area Network (CAN), ControlNet, Ethernet variations, Foundation fieldbus, Profibus, and more. Suppliers should be consulted in choosing a specific bus and its protocol. The protocols dictate the specific way in which the bits will be sent up and down the bus. In a practical sense, speed limitations will most likely require that closed loop control — such as a positioning servo system or a pressure control loop — will need to be closed at the site of the control loop with dedicated hardware (sensors, controllers, amplifiers, control computer, etc). The bus in these cases merely issues commands from time to time and the command center logs the device responses via the bus.
A look ahead
Multiple sensors will be needed on pumps and other fluid power components of the future. Because many sensors remain relatively costly, they can add appreciably to the cost of the component. This precludes the manufacturers from adding sensors just in case they might be needed.
Not knowing which bus standards will dominate hinders manufacturers from developing compatible products. The challenges are many, so some manufacturers offer products with interface capabilities to various bus protocols.
Handbook serves electrohydraulic system designers
