IO module replacements: Check documentation, controller programming, grounding
Control Engineering: When replacing input/output (I/O) connections, what are key considerations?
Kurt Wadowick, I/O systems product specialist, Beckhoff Automation: Engineers should carefully evaluate the current documentation and determine if it’s in proper shape and if the electrical drawings are accurate. They absolutely must be correct; otherwise, any upgrade project is automatically in peril. It used to be a huge concern to run down information, but since the rise of the Internet, manufacturers of all equipment have scanned-in old paper documents or posted all the needed documentation as PDFs. Today, this issue really comes down to knowing how to do a proper Google search. In most cases, it’s all there on the Internet.
Responsible engineers should collect manufacturer and model part numbers of sensors and actuators. This step can be skipped if the I/O device being replaced has exactly the same specifications as the new device.
During any upgrade, engineers should collect manufacturer and model part numbers of the controller’s I/O cards. Ask yourself if the new I/O system can fit in the same installation area as the old system. If the I/O modules’ location must be adjusted, will the field wiring still reach them? Does the new I/O system run on the same power supply as the previous system being replaced? If it differs, then dc power supplies may have to be added along with fuses for circuit protection. Routing of additional wiring for new dc power supplies must be carefully considered. Do not mix signal types, and keep 120 V ac wiring away from the 24 V dc I/O wiring.
Other, possibly more subtle issues can also cause troubles. The filter time of an input must be taken into account. If the old input had a filter time of 0.3 ms and the new input has a filter time of 1.0 ms, then it’s possible the new input could miss an event as it takes more than three times longer for the new input to note a change in the input signal. Even if the new input were significantly faster, this could still create an issue. The new, faster input can catch sensor “glitches,” but the old input may have had so much filter time that it would never see the “glitch” even though it had been there all along. If the new and much faster input can now detect the “glitch,” a program that previously worked fine may now start making erroneous decisions.
Q: What functionality do attached applications need to incorporate?
Wadowick: Electrical drawings and panel layouts are generally done in electronic form by a program such as AutoCAD, or in more modern times, Solidworks. This can present several challenges if you’re not careful. Do you have the original copies of the layouts in electronic form (on disk, CD, flash drive)? What version of the software was the original done in? Practically speaking, it’s usually an older version since it’s typically years later that a rework of the electrical panel is contemplated. So will the old file open properly in the new version of the software? Having to redraw everything from scratch is very time-consuming, but unfortunately often necessary.
Also be sure to consider the PLC program. Do you have the source code with all the comments and documentation that can be opened in the programming software? Are you using the latest copy of the software? It’s important to start with the software that is actually running on the machine. Will the program files open in your current version of the programming software? Does the newer version of the programming software allow you to import all the comments and documentation from the older version?
Q: What types of signals (analog, digital, serial, mixed…)?
Wadowick: Sensing was once a simple choice of digital or analog (or of serial at the worst). In recent years, however, sensor networks such as ASi, DeviceNet, IO-Link, HART, and many others are now more commonplace and may offer benefits that offset the sometimes greater price of these devices. Even wireless technologies have begun to appear. Of course, these also represent new challenges. Wireless is a great buzzword, but issues can arise with FCC licensing, reception around corners and through machinery, or having to deal with batteries.
Q: How many channels are needed? What design and how granular should the modules be?
Wadowick: A feel for the process is needed to understand how many I/O channels are needed. Some companies offer a fine, granular approach to I/O. A single analog point or as low as two digital points on a single I/O terminal are available—from Beckhoff Automation, for example—as well as up to 16 digital points on a single 12 mm wide terminal. Today, most I/O device manufacturers are pushing for much higher I/O counts per terminal. Beckhoff even offers slightly larger I/O blocks that deliver up to 64 digital points and has maintained options for OEMs and end users that want a very exact I/O count.
Q. What network protocols are required, and will they be wired, wireless, serial, digital, or a combination?
Wadowick: In a retrofit situation, a great deal of effort is often exerted to stay with the sensor and I/O network protocols already in use. If ASi is already in use or IO-Link, then it sometimes makes sense to stay with those protocols and not switch to DeviceNet, or HART, or some other protocol.
Q: What are the sensing, signal conditioning, distributed control, isolation, and other requirements?
Wadowick: Signal conditioning can be as simple as providing a properly grounded, shielded cable for an analog sensor. Similarly, isolation can be as simple as keeping sensitive analog input circuitry away from high EMI sources such as drives or ac motor contactors. As a general practice, don’t buy a 16- or 24-bit analog input terminal and then provide a noisy field wiring connection to that input terminal. Doing so is a waste of good money. Filtering a signal cannot give back the signal resolution lost to noise.
Distributed I/O can reduce field wiring from one location to another down to just the dc power and the fieldbus cable. The cost of the device to couple from signal levels to the fieldbus (the coupler) should be offset by the reduction in field wiring.
Q: Will the I/O connections be enclosed or exposed?
Wadowick: Whether the I/O connections are enclosed or exposed depends on the rating—IP20 (panel-mounted I/O) versus IP67 (machine-mounted) modules. Many of the same questions that arise from using distributed I/O also apply to machine-mounted I/O. On the plus side, the sensor and actuated wiring is greatly reduced with machine-mounted I/O. The cost of the machine-mounted boxes, connectorized cables, and the effort to get dc power out to the field-mounted modules are offset with savings from eliminating electrical panels, requiring much less conduit and the ability to troubleshoot the I/O without having to open an electrical panel door.
Q: What are among the most-overlooked considerations?
Wadowick: Frequently overlooked considerations include noise and grounding, cable routing, and the need to keep signal types separated from each other. Do not route a critical fieldbus network cable like EtherCAT, Profibus, or DeviceNet right past or routed along with variable speed drive motor wiring, 3-phase power wiring, or other high-energy and switched circuits. Ground might appear fine at dc ohms with a standard multimeter, but signals in the variable speed motor leads or any other switched ac or dc circuit are not at dc. As frequency increases, ac reactance also rises. A circuit that reads at virtually zero ohms at dc could be more like 10 to 100 ohms at the actual ac frequencies, and in that situation, the low dc resistance ground is not taking care of grounding so high frequency noise will be present.
Mounting the actual I/O modules in a location right next to switched mode dc power supplies, variable speed drives, or any other electrical gear that uses high speed switching circuits is a bad idea. Just because it “fits” doesn’t mean it’s a good idea to mount it anywhere the I/O can be mounted. Approximation to EMI sources must always be taken into consideration.
– Mark T. Hoske, CFE Media, Control Engineering, www.controleng.com, and Kurt Wadowick, I/O systems product specialist, Beckhoff Automation.
See channels for
Industrial PCs and PLCs