Machinedesign 1383 Device Level Buses 0 0

PLCs bus into the future

July 1, 2000
IPC 1995 displayed a few new products in PLC hardware and software. But the real news was the proliferation of sensor-actuator (or device-level) buses. Now you have nine from which to choose

Early in 1994, Allen-Bradley Co. and Honeywell each introduced a communication system that connects switches, sensors, small motor starters, and other such devices to programmable logic controls (PLCs) or personal computers (PCs). They were A-B’s DeviceNet and Honeywell’s SDS, (see PTD, “Open networks link factory floor devices,” 7/94, p. 19). Within the last year, the total number of these systems, also known as device- level buses, fieldbuses, and sensoractuator buses, has grown to nine. (See the box, “Glossary,” in this article for definitions of network terms.)

Users will benefit from lower wiring and cabling costs, reduced bus and device installation time, and increased uptime and reliability of their automated systems. But with more buses, selecting the right one is now more difficult. Each bus differs in speed, amount of data transmited over the cabling, and number of devices it connects.

Why so many buses?

“These device-level buses are as big a change in the industry as PLCs were almost 30 years ago,” says Charles Juda, marketing manager, Namco Controls Corp.

The major factors for this proliferation: a continuing need to increase production accuracy and speed, while cutting costs; advances in microprocessors and communication technology; and the intense competitiveness and marketing savvy of major players in this industry.

By many estimates, 80% of the manufacturing integration market involves I/O connections to sensors and small devices. Various remote I/O solutions combined with small, mini, and micro PLCs have been a popular way to get the intelligence near the control device, Figure 1. However:

• This solution requires a lot of wiring.
• It doesn’t provide enough integration among devices that work with a PLC — such as sensors, switches, and motor starters.
• It doesn’t cut production costs.
• PLC vendors remote I/O products tend to be proprietary, complicating communications solutions.

“Thirty years ago, the PLC industry promised to cut costs,” says Richard Bazany, director of network products, Square D Co. “Instead costs have gone up as functionality has increased. However, device-level buses, Figure 2, can take out 40 to 70% of cost while maintaining functionality and performance.”

These buses are designed to connect devices without going through traditional PLC I/O modules. Benefits include:

• Devices connected on the cable are integrated together.
• Intelligence and control are distributed to where you need them.
• One four-wire cable connects all these devices. Connection costs plus install and debug time are cut by at least half while still giving users their local, remote, and distributed I/O options.
• Maintenance and fault detection are improved.
• Overall reliability and up time of the entire system increases.

These new buses, with their open configuration, are an alternative to the proprietary products. “Users have seen that the bitbased buses solve the remote I/O problem. They replace remote I/O,” says Rich Canfield, fieldbus program manager, Square D Co. “And they have faster speeds and cost less.”

Control manufacturers with remote and distributed I/O products have noted this as well. When DeviceNet and SDS received so much media and customer attention, other vendors were inspired to publicly link with a bus specification and promote it. Thus, the seeming suddenness of so many buses.

But many of these buses are not new. Some have been in standards development or approval processes for years. Some have not and will not go through this often time-consuming procedure. Sponsors of such buses intend to take their solution directly to the customer and try to establish a de facto standard.

It’s too early to tell if any of these buses have market staying power. As Dave Shepard, PLC marketing manager, GE Fanuc puts it, “There are too many networks. We’re out of control, so driven by vendor greed versus actual user benefits.”

In addition to the need to increase productivity and the intense competitiveness of this market, recent advances in technology influence bus development. Technology has finally made it possible to reasonably meet user demands for better integration at lower costs.

These buses take advantage of advances in microprocessor technology, especially application specific integrated circuits (ASICs). A bus’s protocol, or the rules governing data format, transmission format, and network housekeeping details, are coded onto an ASIC chip or chips. These chips are small enough that sensor and switch manufacturers can embed them in their 18-mm diam products.

Bit, byte, or packet

Some buses are faster than others, some handle more data, some go longer distances, some are less expensive, and sometimes, a bus is not the best solution. Depending on your production needs, you may need one two-wire cable that connects a few sensors to one control, or several networks that implement the full seven-layer ISO model.

Device-level buses exist in three versions: bit, byte, and packet. Bit-type buses, such as Seriplex and ASI, transmit a few bits at a time, typically one to four bits. They send on/off, there/not there signals, or simple counting data. They transmit at the shortest rate — usually less than 5 msec/bit — because they don’t send several bytes of format coding with the data.

Byte-type networks send bytes of data. Data transmission speeds are high, but not as high as the bit networks. Typical speeds are 125 to 500 Kbaud. A few can go higher. Byte-level buses typically handle mid-level automation functions such as process or cell-level control. Byte-type buses include CAN-based buses and lowlevel versions of Profibus and Interbus-S.

The packet buses include Ethernet and TCP/IP, which send large amounts of data, called packets, to various computing systems.

These buses and networks also tend to segregate along process or discrete applications. Fieldbus, Profibus, and LONworks are considered buses for process applications.

Of course, many claim their buses are open to all products and controls. “However,” adds Mr. Shepard, “the term open is being misused.”

There is no accepted definition of “open.” Users define it as the ability to use any device from any vendor, easily connect it to his or her system, and have an integrated, fully communicating system. Vendors haven’t quite reached this point. Some vendors feel that if a product plugs into the backplane of their device, it’s open. Others feel that as long as they provide an I/O port, they’ve met open requirements.

Complicating this matter — even buses based on the same standard protocol may be incompatible with each other. DeviceNet and SDS are based on the CAN protocol, but you can’t send data from a control on DeviceNet to a sensor on the SDS bus, yet. “There isn’t a single CANbased system that’s compatible with another,” says Mr. Bazany. “Everyone has a different application layer. Not only that, some buses with the same name are incompatible with each other. LONworks has four versions. Profibus has several.”

The Buses

In the early 1980s, the process industry defined the specification for a network that would let them monitor process sensors located in the field or at plants miles from a computer at the home plant. Known as Fieldbus, now sponsored by the Fieldbus Foundation, only a portion of it has reached standards approval, see the Table.

CAN was introduced for automotive applications in 1987 and has been adapted for factory automation networks. It consists of three layers of the ISOseven layer model. The physical layer defines the communication method and type of cabling. The data transmission layer controls access to and transmission over a network. The application layer details the services available to users, types of data that can be transmitted, and reporting methods for process variables. CAN does not specify all details of these layers; giving vendors some flexibility.

The CAN bus specification handles devices including drives; digital sensors; and flow, pressure, or temperature sensors.

The ASI bus was developed by eleven sensor, actuator, and control vendors including Allen-Bradley, Banner Engineering, Datalogic Products, Eaton, Omron, Pepperl + Fuchs, Siemens, Telemecanique, and Turck. It sends data among proximity and limit switches, photoelectric sensors, contact closures, and controllers. A bit-based bus, it sends information in bundles up to four bits in length. Data transfer rate is 167 Kbits/sec. It connects to other buses, including Profibus and Interbus-S, and CAN-based buses such as DeviceNet, through gateways.

DeviceNet, a CAN-based bus, connects devices such as sensors and actuators to high-level devices—like PLCs. An unusual characteristic of this bus is that you can remove nodes without shutting the bus down. Several data transmission rates are available. The rates depend on how many devices are connected to the cable and cable length. According to its sponsor, DeviceNet is not competitive with fieldbus networks because it can’t transmit the large packets of data needed for the analyses fieldbus applictions require. Instead, DeviceNet can be used in conjunction with a fieldbus.

This year, Allen-Bradley sold its DeviceNet specification to a vendor organization, Open DeviceNet Vendors Association (ODVA).

Interbus-S is a non-proprietary sensoractuator bus supported by Phoenix Contact. According to the company, European drive manufacturers, Drivecom, have standardized on this protocol for communications with PLCs and PCs. Two chips are embedded into products. All input and output data are updated simultaneously.

LONworks, according to some, was the first device-level network. From Echelon, the company is following the strategy of other bus sponsor companies and is signing up as many product partners as it can. Honeywell, for example, plans to offer an interoperability path to LONworks through its SDS bus.

Profibus is an accepted standard in Europe. It is a digital communications network that can pass a range of data formats, from bits to full packets, connecting sensors to PLCs to cell controls to supervisory controls. It has been available in the U.S. for several years, but has not achieved the critical mass of users needed to make it a de facto standard. At first, the Profibus Trade Organization worked with official standards organizations for acceptance. Now, it is taking the specification directly to the marketplace.

SDS connects sensor and actuator devices to PLCs and, from a recent announcement, to PCs. Currently in a master- slave arrangement, Honeywell plans to offer the bus in a peer-to-peer network scheme soon.

This bus enables sensors to monitor a process and report status. Users may also query the sensors for diagnostic conditions. For example, a sensor can indicate if its lens is dirty or a reflector is out of position. The sensors signal a PLC or PC only when there’s a problem. In this way, the bus avoids overwhelming the control with a continuous stream of data.

Seriplex is a bit-based bus that has been available since 1990, but was recently bought from Automation Process Control by Square D Co. and its parent, Groupe Schneider. Plans are in the works to offer several gateways to LONworks and DeviceNet.

Several sensor companies have versions of Seriplex — Namco with Prox- Blox, Pepperal & Fuchs with VeriNet-3, and Banner with Photobus. According to Square D, Seriplex does not compete directly with Fieldbus, DeviceNet, LONworks, and others. Users can combine Seriplex with LONworks to create a communications system with features similar to Fieldbus.

Several of these buses are capable of handling independent motion control applications, connecting motors and drives to PLCs and PCs. For more on these buses in such applications, turn to “More choices link motors and drives to controls” in this issue.

Selecting an I/O network

With all the choices and options, and possibly more on the way, how do you choose the right bus for your application? The Table gives specific information on data rates, number of I/O devices a bus can support, cable length limits and so on. Also, control vendors offer a few tips:

• Select a bus that connects with the sensors you use, or plan to use.
• Be sure the bus meets your speed and data throughput requirements.
• Be sure the selected bus communicates over the distances you require.
• If you have other buses or networks, be sure the topologies, i.e., a ring configuration vs. a trunk-drop configuration, are compatible.
• Lastly, vendors suggest that the selected bus should have a large enough installed base to assure its long-term survival.

Future shake out

There will be one. With nine buses, neither device manufacturers nor customers can afford to support all of them. The European manufacturers will also influence which bus stays and which goes as the world manufacturing market shrinks. But there will always be several buses to choose from because users have different needs.

— symbolic representation of an “On” or “Off” state of a device. In computer code, it is indicated as a “1” or a “0.”
— years ago, Bus referred to the path or paths data traveled on the backplane of a computer board. The definition is broadening to include data traveling within the physical medium of a few wires or cables.
— eight 1’s or 0’s grouped together, in any combination. Each group of eight bits represents an instruction, a command, or datum.
— the ability to have one device connect, attach, or communicate with another.
Data highway
— another term for bus or network. Also, a network system created by Allen-Bradley.
— in communications, a configuration where control, command execution ability, or intelligence (such as microprocessor intelligence) is spread among two or more devices.
— a general term used to describe any bus that connects devices to microprocessor-based controls. Synonymous with device-level bus, sensor-actuator bus, mid-level bus.
— a specification, for process applications, that is currently under admission for acceptance as a standard.
— software on a board or chip that converts one communication protocol to another. Like converting a DOS program to an Apple-based program. Sometimes gateways also convert cable types.
— hardware interface device between different cable types. Connects these cables together into a network.
— Sufficient communication among devices, such that performance is enhanced to a level not possible as independent devices. Devices become part of a whole as opposed to separate pieces of a system.
— a transmission rate of one byte per second.
— All the cabling, wiring, and software parameters and control used to connect microprocessor-based devices over long distances. Distance is less of a factor now.
— Several bytes of data grouped together in a network message.
— a specification that defines input signal levels, polarities, and speeds, and a devices’ output signals.

Sponsored Recommendations

How BASF turns data into savings

May 7, 2024
BASF continuously monitors the health of 63 substation assets — with Schneider’s Service Bureau and EcoStruxure™ Asset Advisor. ►Learn More: https://www.schn...

Agile design thinking: A key to operation-level digital transformation acceleration

May 7, 2024
Digital transformation, aided by agile design thinking, can reduce obstacles to change. Learn about 3 steps that can guide success.

Can new digital medium voltage circuit breakers help facilities reduce their carbon footprint?

May 7, 2024
Find out how facility managers can easily monitor energy usage to create a sustainable, decarbonized environment using digital MV circuit breakers.

The Digital Thread: End-to-End Data-Driven Manufacturing

May 1, 2024
Creating a Digital Thread by harnessing end-to-end manufacturing data is providing unprecedented opportunities to create efficiencies in the world of manufacturing.

Voice your opinion!

To join the conversation, and become an exclusive member of Machine Design, create an account today!