When I was teaching the PLC, it was very apparent that students had preferences for languages based on the task at hand. For example:
-
For analog operations, they gravitated toward Function Block Diagram (FBD).
-
Ladder Logic (LD) was preferred for general-purpose work.
-
Some students preferred Structured Text (ST) as it has a C-like feel similar to the microcontroller work we had previously completed.
Despite these natural preferences, it’s not about which language is being used, but rather how that language is being used. We could argue that program organization overrides most considerations about the “best” language. This universal statement equally applies to the PLC, embedded microcontroller, and all associated languages. Let’s not forget that the PLC is unique in its ability to mix and match IEC 61131-3 languages. This allows those natural student preferences to be used in a single PLC.
For clarity, let’s repeat this statement: “PLC program structure trumps language.” This is especially true as the program size increases.
Recall that we define PLC programming in terms of Program Organization Units (POUs) including small programs, functions, and User Defined Function Blocks. It is highly desirable to break a large program into smaller modules as shown in Figure 1. We can use the classic Kernighan and Ritchie definition:
K&R: A function provides a convenient way to encapsulate some computation, which can then be used without worry about its implementation. With properly designed functions, it is possible to ignore how a job is done; knowing what is done is sufficient.
The trick is knowing where to define the boundaries between POUs. If we are very careful to resist the siren’s song of copy and paste, we can use the AI to identify the POU boundaries and test corner cases.
Figure 1: Block diagram showing the namespace for IEC 61131-3 software. The three types of POUs are seen on the right-hand side including programs, functions, and user defined function blocks.
The AI is Helping the Programmer
To fully answer the question, we need to recognize that computer software is moving into a new cyclical development realm where AI is helping the developer to write improved AI prompts to generate the software. Instead of grinding through low-level details, the programmer is shifting to a high-level in partnership with the AI.
What can the AI do for the PLC programmer?
Personally, I view this as a win as the AI can help parse the programs into meaningful building blocks.
-
The AI can help define the blocks at the interface level potentially leading to clean, tested, and well-documented code.
-
The PLC programmer is now able to operate at a higher level of abstraction with emphasis on the interaction between the blocks.
-
This promises to improve maintainability as an AI operating on a block can quickly analyze the corner-case conditions and prevent drift between the “helpful” comments and actual code.
ST is Highly Compatible with AI Assisted Code
The previous comments are directly applicable to ST as the LLMs can digest the text-based language. We also recognize that ST is a portable language with potential to be used across PLC families and vendors. It is not locked to a particular PLC or programming tool.
What is the counterargument against using AI for PLC code?
We recognize that the AI has no concept of the PLC to machine interaction or of the timing aspect of a process. Consequently, a skilled programmer is required to observe, interpret, and then code the machine to perform correctly. Likewise, the AI does not necessarily understand failure modes. It takes a skilled programmer to write an HMI interface to assist technician troubleshooting.
Related Articles by This Author
If you enjoyed this article, you may also find these related articles helpful:
- Should PLC language match technician skill?
- Building a Structured Text User-Defined Function Block (UDFB) using Siemens TIA Portal
- Single Pushbutton On-Off Control Including a Ladder Logic Demo in the Modicon PLC
About This Author
Aaron Dahlen, LCDR USCG (Ret.), serves as an application engineer at DigiKey. He has a unique electronics and automation foundation built over a 27-year military career as a technician and engineer which was further enhanced by 12 years of teaching (interwoven). With an MSEE degree from Minnesota State University, Mankato, Dahlen has taught in an ABET-accredited EE program, served as the program coordinator for an EET program, and taught component-level repair to military electronics technicians.
Dahlen has returned to his Northern Minnesota home, completing a decades-long journey that began as a search for capacitors. Read his story here.