Many of the inputs on our machine automation systems require extensive signal processing for filtering, averaging and other calculations. We know that PC-based control would be a good solution, but our customers require us to use a PLC. Unfortunately, the PLC brands specified don’t include much in the way of signal processing capability at the I/O. This drives us to use a quite expensive model of the specified brand of PLC, even though our I/O counts are low and our other automation requirements are quite simple. However, our customers would accept a PLC with at least some I/O from a vendor of our choice, a vendor specializing in I/O with signal processing and other capabilities. Can we easily mix and match I/O from different vendors with one PLC processor, providing that PLC processor contains industry standard digital network interfaces? Are they any gotchas?
—from December ’08 Control Design
ANSWERS
Rev Up Existing Hardware
Today, vendors of modern I/O systems integrate more and more functionalities inside the I/O modules. This means that these modules are no longer just simple analog or digital modules but are capable value averaging, fast Fourier transformation (FFT) and even oscilloscope functionality for signal processing. Digital modules support functions that capture inputs in high resolution and send this data as pattern over a slower bus to a PLC. For the output direction these modules provide drum sequences for the outputs that are set independently by the module over a specified time period.
It is even possible to connect interfaces like RS-232 or RS-485 to a bus coupler that gives you the possibility to attach, for example, a bar-code reader at any place of your machine without running an extra wire to your cabinet. The advantage of intelligent I/O modules is the extreme fast reaction, even if the bus connection or the PLC is relatively slow. This gives you the possibility to combine modern high-speed analysis for analog and digital data with even older existing hardware. In many cases, an independent vendor of I/O systems can provide additional functionalities that the PLC vendor might not support. Many vendors have a modular I/O system that can be assembled exactly for your needs and can be combined with all standard digital bus systems like Profibus, CANopen, DeviceNet, EthernetIP andPowerLink. In any case, open bus systems should be the preferred solution because this will give you the highest flexibility to switch between these bus systems if necessary and make sure that your application is prepared for extensions in the future.
Stephan Stricker, product manager,
B&R Industrial Automation
Connection Considerations
Connecting I/O modules or subsystems from multiple vendors certainly has been made easier since standardized fieldbus networks such as Profibus, Interbus or DeviceNet found industry-wide acceptance. The same goes for the emerging trend to use Ethernet-based communication protocols like Profinet, Modbus TCP or EtherNet/IP to read and write data to these devices. While use of these protocols standardizes the basic communication, they do not always guarantee a 100% flawless integration of devices from multiple vendors.
Pay special attention on areas such as configuration of the individual modules. Every vendor uses a different set of parameters to configure a module and access the data. For more complicated or configurable devices, you need to make sure that any required drivers or function blocks are available for the specified PLC model.
Other considerations are the connection method and connector style. While a device from Vendor A might use a traditional copper connection, a similar module from Vendor B might use a fiberoptic connector or an entirely different connection method or cable set. If you do your homework before you purchase components from different vendors, you minimize any integration issues and should be in good shape with the startup of your system.
Bjoern Falke, product marketing, automation,
Phoenix Contact
External Help for PLCs
Keeping a PLC’s analog I/O simple, and of course low cost, usually means trying to stick to one multi-channel input card flavor, such as the common 4-20 mA type. This is not too difficult even with a lot of different input sources to be fed in, such as millivolt, potentiometer, frequency, voltage or milliamp signals. Most process field devices give 4-20 mA outputs anyway, but for the rest of those above, linearization and conversion by discrete external conditioning modules into 4-20 mA is a well-used solution. However, for critical measurements for control or safety, the user will want to keep spares for each module type, which then offsets his input card savings a little.
Fortunately, there are conditioners in one configurable module that can handle inputs from any thermocouple, RTD or potentiometer, as well as a range of millivolts, resistance, frequency, current and voltage. These help users minimize their electronics inventory and, through easy-to-use configuration software, enable quick setup of a wealth of parameters, such as input type, range, response time, sensor break action, output action and linearization. Such a broad range is not possible with PLC channel setup. Hence, it could be such universal external discrete modules that act as the major analog functionality element of the I/O interface to the PLC.
The problem is solved then? Not quite.
First, even the non-converted 4-20 mA field device signals could benefit from an isolation module in the signal loop, perhaps due to common powering or where their cables are routed or what grounding/shielding is installed. Discrete isolation modules for these inputs could help here, too.
Second, there are two basic flavors of PLC 4-20 mA I/O channel card—passive and active—without considering HART communications. These are relevant because each converter’s or isolator’s output above has to suit the input channel type. The converter’s output needs to be output loop-powered when used with an active input channel card, and it normally should be a current source when used with a passive input channel card. The exception is when an output loop-powered converter gets its power from a separate dc supply in its output circuit, allowing the input channel card to be passive.
Murphy’s Law would state that when the PLC is supplied with a mixture of active and passive channel cards, the converter’s active/passive output types supplied will be in inverse proportion to those required by the input channels.
The definition of “universal input/output converter” is open to interpretation, but the concept is making progress.
Alan Balcombe, global product engineering manager
Weidmüller
The Associated Files
Yes, you can mix-and-match I/O from different vendors with a common PLC. When using open fieldbus networks to one common PLC, many different vendors can be connected to the same network communicating data. Each of these networks has some type of configuration and might have associated files.
Profibus needs the vendor GSD file, Profinet needs the XML_GSD, DeviceNet needs the vendor ESD files. These file types help add the personality of the device to the configuration software.
Small processors featuring modular architecture provide cost-effective choices when factoring in size, flexibility and networking capability.
Additional functions can be easily integrated into most projects by selecting the correct modules and advanced features. The industry is providing an increasing array of modules for signal processing capabilities, such as -10 V, +/-10 V, 0-20 mA, 4-20 mA, thermocouple, RTD and many others. Several of these modules also offer the flexibility of programming via software. Smart modules, such as those using the HART protocol, can provide more information about the remote device and signal. Intrinsically safe modules have also been engineered for signal collection/processing in hazardous locations. Additional advanced modules like serial communications modules, stepper motors modules and AS-Interface modules bundle big application solutions into small packages cost-effectively; these types of solutions are typically costly to get in big processors.
Choose the correct open network for complete control and data acquisition. Today, Ethernet seems to be the topology of choice for many operations. The protocol is communicated across Ethernet. This is easy to interface a PC for an HMI and data logging with data speeds of 100 Base-T. Ethernet makes it possible to keep the PLC processor on the factory floor but makes it convenient to network and interface to an enterprise system.
Some of these remote I/O control systems have a programmable processor. These can be programmed like a PLC to perform a specific task locally while still interfacing to the common PLC across the network. As an example, the remote processor may be programmed with a serial module to gather ASCII data from a bar-code scanner. The remote processor pushes the ASCII data to registers and flags the main PLC that it received new data. The main PLC reads the data from the remote unit. This process is removed from the main PLC, which helps to keep scan times to a minimum.
Tracy Lenz, senior support engineer,
Wago
Let’s Talk
In regard to the first part of the question, we feel your pain. You need a little bit of advanced I/O signal processing, so you need a little bit of intelligence, but otherwise, the I/O count is low and requirements are not very stringent. Unfortunately, you find out that to gain the measure of intelligence and signal processing that you do need, you’re going to have to go with the advanced, and of course more expensive, PLC and I/O.
Most remote I/O systems are as you described. They simply read the state—on or off—of discrete inputs and the value in raw counts of analog inputs and then send these back to the PLC, which handles all the logic and processing. The PLC then communicates back to the remote I/O, indicating the states it wants written and the discrete outputs.
What Opto does is handle many intelligent functions at the I/O level with no programming. Remote I/O that’s intelligent and has advanced signal processing capabilities—filtering, averaging, min/max, gain/offset, along with PID loops, thermocouple linearization, ramping, counting, scaling and engineering unit conversion—communicating to your PLC.
This intelligence can be configured at the I/O level with no programming, either in our I/O or in whatever PLC is attached to our I/O. The intelligence is run or executed down at the I/O level as well, thus de-burdening the PLC scan time, as well as the network speed between the PLC and the I/O. All of this is facilitated by our Snap “brain.” Most vendors just have a communications adapter, bus coupler or remote I/O adapter at the I/O.
By using Snap I/O with built-in EtherNet/IP or Modbus TCP, access to signal-processing I/O is now available on a number of PLC platforms that support these protocols. Gotchas could be how the PLC manufacturer facilitates the exchange of data with third-party I/O systems within their software. For example, RSLogix 5000 uses a method known as the Ethernet module, a rather generic interface that works well but requires the exchange of data in a single data type format: either real data types or double-precision integer (DINT). The former is ideal for analog floating point data; the latter ideal for discretes. This is usually not a problem, as long as the engineer recognizes the limitation and accounts for it.
Arun Sinha, director, business development,
Opto 22
Three Ways to Connect
The need for extensive signal processing and analysis, high-speed analog measurements and advanced math in machine automation systems led to the development of the programmable automation controller (PAC), which combines the ruggedness and reliability of a PLC with the openness and high-performance of a desktop PC.
There are three fundamental methods of connecting PACs into existing PLC architectures.
- Basic analog and digital I/O—Analog/digital data can be outputted from the PAC into a PLC. This is the most basic way to integrate PACs with PLCs. For example, a 4-20 mA signal could represent the result of a calculation running on the PAC.
- Industrial networks—A majority of PAC products support industrial protocols such as DeviceNet, Profibus and CANopen, along with Ethernet-based protocols like TCP/IP, UDP, Modbus TCP/IP and EtherNet/IP. This gives engineers a lot of networked options for connecting PACs to PLCs. I2S used Ethernet protocols to transfer data between the CompactRIO PACs and to also interface the PACs and PLCs to the networked HMI.
- OPC connectivity—PACs can also act as OPC (OLE for process control) clients or servers and send and receive networked data to PLCs or other PACs using OPC tags. The OPC standard provides a generic set of routines to allow automation systems from different vendors a way to interface easily.
Many vendors that specialize in I/O with signal processing and other capabilities offer products with fixed functionality, leaving engineers with few options when project requirements evolve. All National Instruments PACs are programmable with NI LabView, making it easy to incorporate hundreds of advanced math, signal processing and analysis functions, as well as new function blocks based on IEC 61131, allowing engineers to adapt to changing requirements.
It is important that any PAC integrated with an existing PLC-based system contain enough horsepower to perform the acquisition, processing and transmission of the results without slowing down the PLC control loop.
Kurt Williams, product manager,
National Instruments
80/20 Rule
Programmable automation controllers (PACs) define a new generation of industrial controllers which feature the PC’s openness, high-performance CPU, rich memory and powerful software functionality, as well as the PLC’s reliability and robustness.
About 80% of applications can be finished by 20 ladder-logic instructions. These average requirements have resulted in the recent growth of low-cost, tiny PLCs with digital I/O that uses ladder logic.
The other 20% are more complex, and traditional PLCs cannot fully satisfy them. These higher-level applications usually require complex control capabilities, high-speed analog measurements, multiple-program support with different cycle times, open communication functions and enterprise-level network integration. PACs will play a major role in different application domains by adhering to open industry standards and providing multidiscipline programming and functionality. For machine automation systems that require extensive signal processing, many control solutions try to reduce the signal refresh rate, but you will lose some of the information being measured. Specifically with PLCs, some of the signal conditioning is built into the cards. With the PAC and complex SoftLogic control software, we can set up a small FIFO and take the average of the signal. The signal conditioning is incorporated into the PAC’s program and processed by its CPU. This will give you a more accurate measurement.
John Wilhite, control and I/O product manager
Advantech, Industrial Automation Group,
April’s Problem
We have used proximity switches on our dry material handling machines for a number of years. We are now contemplating an upgrade to programmable proximity switches. This should allow us to improve performance by fine-tuning switch characteristics via software. It should also allow us to stock fewer different types of switches. Are these and other improvements worth the time, the trouble and the expense of upgrading from standard to programmable proximity switches?
SEND US YOUR COMMENTS, SUGGESTIONS OR SOLUTIONS FOR THIS PROBLEM. We’ll include it in the April ’09 issue, and post it on www.ControlDesign.com. Send visuals if you’d like—a sketch is fine. Email us at [email protected]. Please include your company, location and title in the response.
HAVE A PROBLEM YOU’D LIKE TO POSE to the readers? Send it along, too.
Leaders relevant to this article: