Recall a time that we could not use certain applications across platforms. For instance, RSLogix used to not be able to run on Apple. Now, there are ways that it can. Software dockers or simulated Windows environments allow non-native software to run on a Mac machine. The point is that the hardware is no longer a limiting factor. The same trend is occurring in automation with open-source programming in the programmable logic controller (PLC) arena.
The advantages of open-source PLCs include cost-effectiveness due to reduced licensing fees and lower hardware costs, vendor independence and flexibility. The development of these open solutions is making inroads.
One example is Ignition. CoDeSys has also increased its market share. Both are platforms that cross market lines by utilizing their platforms with traditional software languages and tools, and not just putting a PLC frame up on a box with a chip and some I/O.
Active development in the open PLC arena has influenced the bigger PLC manufacturers. In recent years, Rockwell Automation introduced FactoryTalk Optix, which is a direct result of the market share that Ignition took over in a short 25-year period. Ignition was able to do this because it is easy to use, because its environment does not care about Windows or Apple and because Inductive Automation gave free training. Another thing that some people do not know is that Inductive Automation used the product in-house and worked on it in-house, along with input from customers, to improve the product. This emulates what happens with open-source products.
Open source allows an iterative software process, which enhances continuous improvement. Thus, it makes products like CoDeSys incredibly powerful and allows collaboration between vendors to create software that allows versatility for users. An example is that Bosch Rexroth uses CoDeSys SoftMotion libraries to perform motion commands on its ctrlX platform.
Recently, CoDeSys expanded its libraries and introduced the standard robot command interface (SRCI) libraries. The open-standard software is flexible enough to run on any platform. It has capacity to run any robot from a PLC platform.
Think of ladder as the visual representation that it is. Under the hood is Pascal or C, C++ or Java, or the like. Pascal is closest to structured text, but the machine language is the key. RoboDK software emulates almost any robot with one interface, so why can’t a PLC control any robot? Also, if you can see the robot’s inputs and outputs and communicate, then the platform no longer matters.
Get your subscription to Control Design’s daily newsletter.
Protocols are defined as a set of rules that governs the formatting and processing of data, which enables communication between devices or systems.
Just like virtual machines and dockers can emulate Windows on a Mac desktop, an interface can be built to make the handshake between the PLC and a robot. If the protocol is a standard format, then that interface may be shared across PLC platforms and run different robots. Traditional computer science people would call the interface an interpreter.
What happens with an interpreter? The interpreter can run parallel in the environment and wait for robot commands from the PLC, convert the command into the right protocol, send the command to the robot and get the response back, and then convert it back for the PLC to understand. This can happen without having to compile. This means your robot application may become a compilation of commands in a function block, or you may create a reusable template. Either way, robot interfaces with PLCs will become easy to duplicate and deploy.
SRCI already is being implemented by many vendors, including ABB, Comau, Duco, Epson, Fairino, Fanuc, Huayan, iNexBot, JAKA, Kawasaki, KUKA, Mitsubishi Electric, Siemens, Staubli, MRobot, Universal Robots and Yaskawa. Why? The market is demanding flexibility, and flexibility requires protocols. Profibus has more information on the SRCI technology and SRCI membership.
