Does Vention’s MachineAgent Signal the Beginning of the End of IEC 61131?

While IMTS was light on Programmable Logic Controller (PLC) engineering announcements, the same cannot be said for robotics control engineering. Vention launched MachineAgent, the fully agentic machine programming tool, with a live demo. Vention is primarily focused on robotics; however, it has begun to incorporate other domains such as motion, machine vision, and other control aspects within its MachineMotion AI device. MachineAgent generates the code that is executed on MachineMotion programs fully in Python using Large Language Model (LLM) agents. Afterward, the generated code is converted into Machine-Native Code (MNC). While agentic code engineering is not a brand-new concept (with many initiatives launched this year at Hannover Messe), engineering entirely in Python drives a more democratized user experience compared to machine-native controller solutions.

Artificial Intelligence (AI) has been threatening the role of the Integrated Development Environment (IDE) this year, with end users beginning to transition away from long periods of programming in the IDE, to agentically-developed code with a human review period. However, even in this new automation environment, code was still produced according to International Electrotechnical Commission (IEC) 61131 standards—the PLC standard for MNC, which created a disconnect between the physical world and engineering contexts, a bottleneck impacting code quality. In recognition of this, Vention, and software-defined automation newcomer ConSynSys have moved to develop code entirely in Python. While Vention then turns this code into MNC, ConSynSys executes entirely in Python.

Transitioning away from MNC to Python (or other Information Technology (IT) programming languages) is a double-edged sword for these two companies and others that will follow in their footsteps.

• The Bad: Higher overall complexity or slower cycle times. For providers that translate IT-based code, embedding Application Programming Interfaces (APIs) and other commands introduces new margin for error and potential for mistranslation. For Python-based executor, the code cannot execute as fast as the original MNC can, limiting use cases where cycle times are very short.
• The Good: Enhanced AI usability. The corpus of training data in Python is much larger than that of MNC data for public LLMs such as Claude, producing higher quality script, and reducing review times.
• The Best: Alignment with a younger workforce and democratization of manufacturing control engineering. Today’s incoming engineers are more familiar with AI and, more importantly, have been learning IT programming languages as a part of their curriculum, so a transition makes them more effective faster, which amid the training shortfalls plaguing manufacturing is an attractive capacity.

It is critical for Incumbents such as Siemens, Rockwell Automation, Mitsubishi Electric, Honeywell Technologies, and ABB to note that IEC 61131 and other MNCs will not be going away in the near term. While many of these companies support IT-style programming in one way or another (see ABI Research’s Software-Defined Automation (SDA) competitive assessment (CA-1615) to find out which vendors and languages), it is becoming important to consider how these languages are deployed. Is it strictly tied to a compiler? Should there be an expansion of languages supported? How could independent AI models be trained to drive closer alignment with IEC 61131 languages? Considering the cycle time limitations, for any use case solution, building the strongest compiler will be the best alternative.

For disruptors such as Vention and ConSynSys, minimizing conversion complexity and developing conditions to shorten the Python minimum cycle time will expand the use cases for Python-based engineering. Expanding the use cases will not only improve competitiveness for the solutions in their target markets but also create the environment to hasten the decline of MNC.