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.
This article is part of the DigiKey Field Guide for Industrial Automation
Location: Teach It → PLC Language for the Classroom
Difficulty: 
Student — difficulty levels explained
Author: Aaron Dahlen | MSEE | Senior Applications Engineer, DigiKey
Last update: 06 Mar 2026
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.
Continue Exploring Industrial Control Systems
If this discussion was helpful, you may also want to explore:
DigiKey Navigation
- Full Catalog: Industrial Control & Automation
About This Author
Aaron Dahlen, LCDR USCG (Ret.), is a Senior Applications Engineer at DigiKey in Thief River Falls. His background in electronics and industrial automation was shaped by a 27-year military career as both technician and engineer, followed by over a decade of teaching.
Dahlen holds an MSEE from Minnesota State University, Mankato. He has taught in an ABET-accredited electrical engineering program, served as coordinator of an electronic engineering technology program, and instructed military technicians in component-level repair.
Today, he has returned to his home in northern Minnesota, completing a decades-long journey that began with a search for capacitors. Read his story here.