Say an engineering team wants to switch their design’s PLC from one model to another — a relatively infrequent but ordinary specification decision. How well do XML files really work for importing and exporting? How much are component manufacturers really motivated to make that work … and not lock engineers onto one specific hardware?
Engineers are right to be skeptical about this. Ultimately, file portability depends on the system-hardware manufacturers … whether the components are connectivity components, smart drives, or other devices using soft motion and IEC 61131 programming.
PLC and PAC hardware is associated with the most limited file portability; in most cases, controller manufacturers offer online software libraries with pre-written code to simplify new machine setup, differentiate their product line, and (not coincidentally) fix users to their particular brand.
That means even if a programming engineer has his or her own XML files, any instances of code based on the hardware suppliers’ libraries will likely not transfer to other devices very easily. Such situations demand that engineers rewrite parts of that code.
That said, limited software portability is ultimately less of a snag than the learning curve (especially in learning a new programming language if that’s required) associated with moving from one brand of device to another. Migration will always necessitate adjustments to the code … but programming based on standards means engineers don’t need to start from scratch during migrations.
Familiarity with industry-standard programming empowers engineers and spurs component manufacturers to make ever-more competitive technology … as the manufacturers can no longer assume OEMs will never migrate simply because of some familiarity with their software.
What’s the most common reason for design engineers to switch motion-controller brands?
Besides migrations made to leverage offerings with open-source programming flexibility, technical support is the next biggest reason design engineers switch controller brands. That’s especially true if they consider their current support insufficient or somehow contentious. Excessive lead times can also spur switches — especially if an important end user is left in a lurch during a machine-down or other critical situation. Quick and reliable manufacturer support of an OEM to recommission machinery and get it back up and running is paramount if an end user is losing hundreds of thousands of dollars an hour.
Another area of differentiation is manufacturers’ graphical user interface (GUI) for hardware setup. Hardware performance from most manufacturers is fairly competitive across the motion industry, but GUI ease of use and functionality vary widely.
When looking to specify a new controller for new machine builds, design engineers should seek:
• Motion-component suppliers that fully support the IEC 61131-3 standard and not just one language of the standard
• Controllers with ease of integration and programmability — for efficient and sophisticated setup of HMI, PLC, and IoT gateway (Cloud connectivity) functionality … preferably all in a single device
• Hardware with functional safety over a suitable network such as EtherCAT, for example
• Suppliers that offer their software for free or at reasonable cost — so that there’s no huge investment needed to try out or license the software
Insight from this FAQ derives from a recent chat with Marissa Tucker, product manager of controls and automation at Parker Hannifin about specifying controls based on standards rather than brands. For more information from Parker on PACs as well as free simulation software for trying out IEC 61131-3, visit parker.com/emn/pac.
Tell Us What You Think!