Industrial controller programmers can hone their control system programming skills for programmable logic controllers (PLCs), programmable automation controllers (PACs), industrial PCs, embedded controllers and edge using extensive advice from two programming experts.
Compendium of automation programming insights
- Explore tips, tricks and best practices for controls and automation programming from instructors in the Control Engineering webcast, “Practical advice for automation programmers,” archived until March 26, 2026.
- Understand how instructors’ best practices can advance controls and automation programming skills and increase your value in automation programming projects.
- See the webcast and more answers article for more advice.
Tips, tricks and best practices from industrial controller programming experts can help to hone control system programming skills for programmable logic controllers (PLCs), programmable automation controllers (PACs), industrial PCs, embedded controllers and edge devices. Knowing practical advice about IEC 61131-3 programming languages can make programmers and their teams more useful in current and future controls and automation programming projects.
While Control Engineering Registered Continuing Education Program (RCEP) webcast “Practical advice for automation programmers” aired March 26, 2025, and remains available for viewing until March 26, 2026, below receive guidance from the notes and slides from the webcast instructors. The control programming instructors are (Figure 1):
- Jason Israelsen, PE, senior control engineer, APCO Inc., has excelled over the past decade, improving system efficiencies in the water and wastewater industries with expertise in programming supervisory control and data acquisition (SCADA), human-machine interface (HMI) and PLC systems. His role involves computer-aided design (CAD) for control panels, commissioning control systems, research, manufacturing and building management systems (BMS). Israelsen holds B.S. and M.S. degrees in Mechanical Engineering from the University of Utah. He is a licensed PE in Control Systems.
- Braden Hadwiger, ME, mechanical engineer, Huffman Engineering Inc. Hadwiger joined the team first as a co-op student and then after finishing his degree in 2022 as a mechanical engineer. His experience includes PLC programming and HMI design for utility customers, primarily in the water/wastewater industries. Hadwiger is known for a methodical approach to solving complicated problems and the trusted relationships he quickly builds with customers. Before joining Huffman Engineering Hadwiger was an assembler and interned for Film Sense where he manufactured Multi-Wavelength Ellipsometers. Hadwiger has a B.S. Mechanical Engineering – University of Nebraska – Lincoln.
A poll question during the webcast asked those participating in the live presentation which learning objective was most important. Results follow.
57% Explore tips, tricks and best practices for controls and automation programming, including workflow, control programming library hygiene and documentation help.
25% Understand how the instructors’ favorite best practices can advance controls and automation programming skills and increase your value.
18% Review IEC 61131-3 programming languages, why some might be more useful than others and important things to know when choosing one over another.
Review IEC 61131-3 programming languages
Reviewing IEC 61131-3 programming languages provides explanation about why some might be more useful than others and important things to know when choosing one programming language over another. Israelsen explained the IEC established the IEC 61131-3 programming languages with the goal of:
- Ensuring some form of compatibility across platforms (before each manufacturer had its own proprietary language).
- Helping to cater to the different backgrounds of electricians, software engineers and process engineers.
- Supporting various process (for example, discrete versus continuous control).
- Flexibility, reusability and maintainability.
The active languages are
- Ladder Diagram (LD)
- Function Block Diagram (FBD)
- Structured Text (ST)
- Sequential Function Chart (SFC).
Instruction List (IL), a fifth language, has been deprecated, meaning it’s no longer recommended for use.
Israelsen explained more about each language and explained how they’re useful.
Ladder Diagram (LD)
Ladder Diagram, the most commonly used language, is an intuitive graphical interface for relay-based logic and easy for technicians to troubleshoot, best used for on/off controls and relay logic (Figure 2). Israelsen said key functions are contacts, coils, timers and latches. While it’s widely used, especially in North America, it’s weak for loops and complex algorithms and can be hard to manage as projects grow large with lack of modularity.
Function Block Diagram (FBD) programming language creates a flow diagram that can simplify control logic by encapsulating into reusable blocks. It’s best for modular and reusable logic, process control, proportional-integral-derivative controls (Figure 3). FBD was derived from block-oriented control diagrams used in the process control industry. Key functions include signal processing and PID loops. It is popular in process industries like chemical plants, refineries, water treatment and other process applications. It can be harder to debug than LD, uses more memory and can become more cluttered without care. It’s highly scalable with function block libraries.
Information about Structured Text (ST) programming language
Structured Text (Figure 4) is versatile text-based programming, best for complex operations and calculations, loops, advanced control and related applications, Israelsen said. Derived from other languages like Pascal and C, key functions are items like looping, heavy math and data processing. It’s gaining popularity, he said, especially with items like PC-based control. Structured text is non-graphical, so less intuitive for non-programmers and subject to syntax errors. ST is very scalable.
Information about Sequential Function Chart (SFC) programming language
Sequential Function Chart (SFC) (Figure 5) is a flow-based diagram for handling states of process of equipment. It’s best for state-based processes, batch operations and multistep workflow.
Israelsen said SFC is derived from a French state-machine standard for process control (Grafcet). Key functions are for batch processing and state-driven automation. SFC is popular in pharmaceuticals, chemical processing, robotics, etc. However, it is not standalone (needs to pair with our languages), limited for high-speed control and can be difficult to debug. It scales well for state-based logic.
Deciding among LD, FBD, ST and SFC programming languages
When deciding which control programming language to use, Israelsen said, consider process (what you are controlling), platform (what tools you have), environment (where you are working) and development needs (maintenance and scaling). The answer may be to use multiple languages. Israelsen cautioned programmers not to fall into the trap of just using what you like or “we have just used that.” Thinking like that is a “trap because you could work yourself into a corner.” Be intentional about what language you will use (make a specific decision).
Israelsen recommended assessing what you are controlling.
Discrete control, or on/off control, might be for tank empty and fill levels, temperature heat and cool levels and batching.
Continuous control examples include PID control, step control, flow pacing, setpoint control and when a process doesn’t stop. Digital input and output (I/O) control examples are when a valve is fully opened or fully closed, a pump is on or off, pressure high, temperature low and a leak is present.
Analog I/O examples include pressure, temperatures, flow, pH and various analyzers.
A table helps discern among control programming languages
Israelsen, in discussing a generic table (Figure 6) based on the principles of the languages, cautioned that platform specifics aren’t included here. While it looks like FBD is the best all-around language, keep in mind that “process considerations” are only one item of reference in choosing a programming language.
Some examples in applying the table (again, ignoring some considerations):
- PID control with analog I/O – FBD
- Discrete control – LD and/or SFC
- Discrete batching control – LD and/or SFC
- Manage analog I/O – ST and/or FBD.
Software platform considerations of programming software selection
Software platform considerations of programming language selection include software licensing available in your facility, which may limit availability to certain languages, Israelsen said. Licensing costs be weighed against features. Some platforms have more developed interface for certain languages. Some platforms have more tools and functions for certain languages. For example, one software platform, may have a specific pulse function available in LD. You are developing in FBD but that pulse function is not available in FBD.
Even if your licensing provides access to all the languages, certain software platforms have developed the interface for certain languages more than others. For example, platform A may have intuitive and well-developed LD and SFC capabilities, but not so much with FBD. Platform B may have intuitive and well developed FBD and ST, but not so much LD.
Environmental influences to programming software selection
Environmental considerations of programming software selection cover where you are working.
Existing standards: Maintaining consistency across systems has value, Israelsen explained. For example, if everything in one plant is programmed with LD, suddenly introducing ST might cause maintenance issues. As noted, some functions and tools might not be available in ST as it is in LD even in the same software platform.
Team skillset: Even if a certain skillset seems ideal, it may not be practical if the team lacks the expertise to manage it. For example, a team might have many who have electrical backgrounds and LD is the best for them to troubleshoot. ST users might benefit from some background coding (like Python or C).
Industry standards: Historically, some industries have preferred programming languages based on process, regulations, safety and other factors.
LD is dominant in discrete manufacturing (automotive, packaging and material handling).
FBD/ST are preferred in process industries (oil and gas, water treatment, chemical processing).
Pharmaceutical manufacturing follows S88 batch standards, which often favor SFC for sequential control and ST for calculations.
Programming development, maintenance, scaling
Israelsen noted that loops may be a necessity for an automation or control application. ST is the one language that excels with programming control loops. Other programming languages could potentially work in simpler scenarios. For example, an implementation of a loop could be for most-open-valve control on a grid of 16 valves. You could loop through all the valves to determine which one should be the most-open valve.
Templating and reusability (Figure 7): Reusable templates (both function blocks and data types) reduce engineering time, debugging and maintenance and can speed up adding features. Related considerations include version control and software updates, scalability, function blocks used for pumps (runtime, counters, power, auto/manual methods, etc.) and data types (analog alarming, scaling).
Israelsen said just because a certain language is your favorite doesn’t mean it is the one you should be using. Select the right type of code for the right task. Encapsulate data into functions to “hide” or “clean-up” code. He said to use the strengths present in each language. A potential approach might be:
- I will use LD by default
- I will ST secondarily
- I will use SFC when I have a batch process.
Tips, tricks and best practices for control programming.
Tips, tricks and best practices for controls and automation programming can include workflow, control programming library hygiene and documentation help.
Israelsen suggested creating a checklist for PLC configuration, defining a structure for code, including comments and coding cleanly.
A PLC program contains many details, Israelsen said, and it is easy to forget various settings, configuration or templates. A checklist can help ensure a quality setup. For example:
1. Software – Be intentional about what software you are using. Consider what is being used as standard on-site including patches and hot fixes.
2. Firmware – Be intentional about what firmware you are using, or perhaps just record what the firmware was for future maintenance.
3. Network settings – IP addresses, gateways, time syncing, etc.
4. PLC languages – What is the plan for the PLC languages you will be using?
5. Function block versions – Ensure to implement site standards for function blocks.
6. Data type versions – Ensure to implement site standards for data type versions.
7. Time settings – Time zone, daylight saving, NTP servers, etc. Note, some protocols use timestamping so time syncing can be important.
8. Other items to consider in PLC programming are:
a. Error handling
b. Checks for PLC power limitations
c. Cybersecurity settings
d. Change default passwords
For a reliable code structure, Israelsen suggested defining common parts
- PLC health
- I/O health
- I/O mapping
- Communications.
Tutorial in control programming tag naming
Tag naming structures can differ (Figure 8). Knowing and following the standard will improve collaboration and consistency. Section naming is similar to tag naming but for the project sections. Define and/or use site specific data types for best results. Have datatypes include a version number to help with maintenance. Define and/or use site specific function blocks. Have function blocks include a version number to help with maintenance.
Comment control programming code wisely
Israelsen said comments help with maintenance, troubleshooting and collaboration, but added that control programming comments should be created with wisdom (Figure 9). Too few comments in code little leaves confusion and too many can lead to clutter. Be clear and concise. When creating comments focus on making comments with the “why” in mind, not the “what.” Doing so creates clearer code comments and helps avoid the trap of over-commenting.
Clean code advice varies by control programming language
“Clean” control programming code improves readability, troubleshooting, collaboration and maintenance, Israelsen said. Tips follow for clean code in each language.
LD
Avoid long complex rungs with lots of branches. Use smaller and sequential rungs or subroutines (embedded code).
Minimize one-shots and latch overuse
FBD
Avoid overly complex diagrams (like a spider web). Encapsulate/embed code into.
Clean up wires minimizing direction changes and overlaps
ST
Watch indentation and spacing
Avoid deep nested if statements
SFC
Use clear states
Simplify transition conditions
Use other languages for complex logic.
No language is “cleaner” than others, but some languages are better suited for certain processes and logic, Israelsen added.
Automation programming effectiveness with the V-model
Hadwiger said he uses the V-Model process (Figure 10) to execute projects and for effectively implementing automation programming.
The first step is to define scope and create specifications. Depending on industry, this can be a conformed specification from a consulting engineer, a functional requirement specification, software design specification or something similar. This document defines what requirements the program is supposed to meet, and what the outcomes are supposed to be. This can include design for other portions such as hardware, visualization techniques, reporting and historical data management depending on the type of specification. As shown in the V-Model, the specification drives the project or program and serves as the one source of truth for design and implementation. The specification can change along the way, but it should be updated as it is changed and the reason for the change should be documented. Even in industries that don’t require this type of documentation, writing some sort of specification provides one source of truth for how the system is supposed to work and what it is trying to accomplish.
Once the specification is completed, design and development of the programming can begin. From this point on, the specification drives the rest of the development process including creating testing documentation, such as factory acceptance testing (FAT) and site acceptance testing (SAT) or qualification documents. This verifies that the programming accomplishes what the design intent was, which could be missed if all testing documentation was created based on the programming and not the specification document. As shown in the V-Model, the specification drives project or programming completion from start to finish.
Control programming code libraries
Maintaining a library of code can pose a number of challenges such as how to handle revisions, storing the code library and implementing the code stored in the library, Hadwiger said. At Huffman Engineering, we keep these libraries clean and organized in a few different ways.
The first and most straightforward way is to use some of the library management tools created by the manufacturer if they are available. Such tools can be used to store code, track changes and revisions and even deploy code in bulk, depending on the manufacturer or type of programming.
The second use for configuration management software is to manage the revision levels and store the code library, Hadwiger said. Once custom pieces of code are completed, tested and validated, it can be stored in the configuration management software. This software acts as a front end to a database that stores the files. The software tracks the revision number, who was the last person to change it, who has access to change which files and keeps comments for different revisions. The software also stores and backs up programs during the project lifecycle. For example, backups are recorded before programming is started when modifying an existing program, before and after the factory acceptance test, before the site acceptance test, before commissioning and after the project is completed.
The third way to manage code libraries is by creating a program template. This template program includes all of the custom code for a specific customer or for a specific manufacturer. It will also include template routines that show how the custom code is used. This template is used to build the rest of the program. The benefit of using a template program is that instead of updating specific pieces of custom code and importing them to a new program, instances inside the template program are updating, start with the template when a new program is completed. Since the template program is revision controlled, it’s possible to ensure that the custom code instructions are the most up-to-date versions. This is useful if there is not a specific software package provided by the manufacturer for revision management software. The template is useful for newer engineers learning how to use already-built custom code libraries.
Revision management can be performed with manual revision numbers and file structures. This is not as robust as a revision management software. It relies on users to accurately update the manual revisions and verify that revisions are archived correctly inside the file structure determined by the organization. One way to help with this is to have a changelog that is periodically compared against the files located inside the file structure. If the file edit dates or names do not match the changelog, discrepancies can be identified and resolved. This type of revision management may not be adequate depending on what type of industry. The main advantage of manual revision management is that there is not additional cost or implementation time of revision management software and can be easier to use.
Control programming documentation best practices
Recurring themes, Hadwiger said, include best practices related to documentation and how to use documentation effectively (Figure 11). One way to organize documentation effectively is to use a document matrix or a master table of contents for a set of documentation. This can contain all of the documents for the control system, such as user manuals for equipment, operator manuals for running the system, drawings and locations of where the documents are stored such as file locations or physical locations in the case of hard copies. This provides one reference for a user looking for a specific document or descriptions of the different documents if a user does not know where to find the information they are looking for.
Embedding document references in control programming comments
Another practice is to place references to specific documents inside the logic programs such as drawing numbers in I/O mapping routine comments or process piping and instrumentation diagrams (P&IDs) numbers for a specific process, Hadwiger said. Reference control narratives or functional requirement specification document numbers in logic comments can help users find more information. Including comments related to PLC or control system logic in other documents such as PLC addresses and I/O tag names on electrical drawings also can help. The example shows the PLC I/O tag name and the tag to which the point is mapped.
Control programming comment context notes
Another helpful documentation practice is to add context to comments inside logic comments, Hadwiger said. A comment may describe what the logic is doing, which may or may not be helpful in certain situations. Adding comments about what the logic is trying to accomplish can add helpful context when troubleshooting a program. For example, if a piece of logic limits flow from one system to another, the related comment tied to that piece of logic may only describe what the PLC or controller is looking for to limit the flow. Adding more context (such as the flow needs to be limited due to a design limitation of one system or because there is a regulatory requirement) can be more helpful to a user trying to understand what the logic is trying to accomplish and how the logic works.
Best practices to increase control programming value
“Personally,” Hadwiger said, “I prefer to write PLC code in Function Block Diagram. I also use ladder logic for certain types of routines depending on if the instructions I want to use are available in function block or not. This is also dependent on the customer I am working for. For example, one of my customers uses Ladder Logic almost exclusively at one facility, but I was able to use some of the function block code I was familiar with by converting the logic from a custom function block instruction to Ladder logic. This met the needs of the customer by using ladder Logic to match what was already at their facility and allowed me to use the custom code I was familiar with. It also allowed the customer to gain the additional features the custom code provided.”
The main advantage of Function Block Diagram, according to Hadwiger, is that it organizes all inputs and outputs for an instruction or custom piece of code into one place and in way that allows seeing all at once. It also allows encapsulation of PLC code often such as the code for controlling a motor or valve. For example, one customer’s custom library of code is written in Ladder logic, but it is encapsulated in Function Block Diagram. This custom code is used for individual pieces of equipment such as a motor with a variable frequency drive. An example of this function block is shown in Figure 12. It’s also worth noting that most modern programming software allows encapsulation of code written in different languages. That provides the ability to create a custom function block whose code is written in ladder logic, function block, SFC or structured text.
“I prefer function block because I am able to see all of the inputs and outputs from this piece of code and quickly determine what the issue is such as the code not seeing a specific input, not receiving an auto start command from the process logic or not turning on a run output. I am also able to see inside the individual function block instance at the ladder logic to do further troubleshooting if necessary.”
Another benefit of function block diagram, Hadwiger said, is the ability to draw out the process flow chart of a system and use that as the basis of the function block diagram program.
Benefits of creating a PLC standard for a facility
Another best practice that I highly recommend is to create a PLC standard for a facility, Hadwiger said. This can be paired with a separate standard for SCADA or HMI standard or can be part of a more comprehensive set of standards documents for a facility. Typically, a PLC standard includes information such as the type of hardware used, how to organize PLC programs and how tags are created, named and organized. A standard for PLC use in a facility also can reference pieces of custom code, how they operate and when they should be used.
This type of document is useful as it builds uniformity across a facility makes it easier to maintain, troubleshoot or make changes to PLC code, Hadwiger said. For example, if a PLC standard is used for organization of the PLC program, it becomes much easier to know where to look for issues when they arise no matter which part of a facility you are in. It facilitates PLC code encapsulation and reuse reducing the time it takes to create new programs. It makes it easier to train new staff as the different PLC programs use the same instructions and are organized in the same way.
A PLC standard can be used to create uniformity even when different PLC manufacturers are used. For example, a custom piece of code can be created in different programming software, but can function in the same way gaining benefits even when having different hardware manufacturers.
A PLC standard can be used with a SCADA or HMI standard to create visual elements corresponding with PLC instructions to speed up development and deployment time and can make it easier to troubleshoot when there are issues.
The graphic (Figure 13) is an example of a matching object tied to a function block located in the PLC created for a customer. This allows PLC and HMI/SCADA programming to be deployed more easily and quickly and allows changes to be made to templates instead of individual instances.
Another practice is having a way to identify if a PLC tag has some sort of external access such as a setpoint that can be edited from an HMI as part of a standard. Typically, this is an identifier such as the area of the plant or which PLC it comes from, and it included as part of the tag name. Putting some sort of identifier, such as “OI” (for operator interface) at the beginning or “HMI” at the end of a tagname to identify that this tag is editable from an HMI and that the value may come from outside the PLC if there is no standard.
Most important: Control program organization
The most important best practice in my opinion to implement is program organization, Hadwiger said. “I tend to organize PLC programs in one of two ways. The first way is based on the ISA 88 standard used for batch control systems.” The ISA 88 standard (Figure 14) defines the physical model of system and the functional model of the system. The ISA 88 standard defines levels from the control module to the enterprise level. This model can be used fully for implementing batch control systems or can be implemented partially for non-batch control systems. For non-batch control systems, the PLC program can be organized up the unit or process cell level. Creating control module routines for individual pieces of equipment or sets of related equipment and then process or unit level routines make the PLC program very clean and makes it much easier to troubleshoot programming and make changes if necessary.
For example, it helps to implement any code used to run an individual piece of equipment such as a pump in manual control inside a control module routine. This includes code such as equipment specific alarms, interlocks, permissives and equipment mode control. Then create another routine for controlling the process where the piece of equipment is used, such as a pressure or flow PID. Creating a separate process or unit routines for other control functions helps, such as sequencing pumps on- and off-based on process conditions. This allows someone troubleshooting the PLC program to easily find the area of code that needs attention or find the issue. For example, if the program is not starting when an operator expects it to, you can quickly find the piece of equipment and see what the issue is, such as a permissive not being met, the process conditions not calling for the pump to start or trouble with a sensor used in the process. This organization method allows changes to be made easily. Changes to one section of code do not affect other parts of the code that do not need to be modified. For example, suppose a pump station or process loop is originally based on pressure but needs to be changed to control flow. It’s possible to change only the process routine and not the code that runs the pumps, so I only have to verify the changes I made and not the entire PLC program. This also applies to other processes such as sequencing pumps on and off. For example, if I changed a sequence to use a Lead, Lag and Lag2 pump instead of only a Lead and Lag pump, I would only need to verify that the sequencing part of the process works correctly instead of the entire process and pump control.
Another benefit to this type of organization, Hadwiger said, is the ability to easily scale programming to the size of system being implemented. More equipment and more processes just need to be added to the programming and don’t require changes to the existing programming. This method is effective for organizing small programs.
Using control strategies in control programming
The other method of organization is to implement control strategies and has similar benefits to the one based on the ISA 88 standard. This method of organization can have different types of names, but Hadwiger referred to it as using control strategies. This method involves placing all or most of the code related to one control loop in one routine or set of routines. For example, this could be a control loop that consists of a pump with a VFD, a pressure transmitter and PID loop. The input from the pressure transmitter, alarms and fault handling for the pressure transmitter and VFD, and the PID loop would all be located in the same routine.
The benefits of this type of organization are that all the related PLC code is located in one routine or several related ones. This provides one place to go for troubleshooting and programming changes similar to the ISA 88 based method. This method can make it easier to troubleshoot an individual control loop than the ISA 88 method. In the earlier example, organizing the PLC program using control strategies can make it easier because all of the inputs, outputs and process logic are located in one place. However, the ISA 88 method can be more effective if a process involves lots of different pieces of equipment or if you want to group similar code together such as creating an I/O map, a routine of all process alarms or code that is used many places in the PLC program, but does not fit one control loop such as a PLC overhead routine.
Other types of organization best practices are to keep scripts centralized where possible and to read data from both devices that need to communicate, Hadwiger said. Running scripts from a client or edge device can be useful in certain situations, but can be difficult to troubleshoot. Keeping event driven scripts or data conversion scripts in a central server or location, such as a SCADA server, allows a user to go to one location for troubleshooting or changes.
Setting up two devices that need to communicate with each other to read the data from both ends is also a useful practice. This can help with troubleshooting, as you are able to identify where the data is coming from. If one device reads and writes to the other device only, it can difficult to know where the data is coming from in the device that has no instructions placed in it.
This control programming compendium was edited from Israelsen’s and Hadwiger’s webcast notes by Mark T. Hoske, editor-in-chief, Control Engineering, WTWH Media, [email protected], and the moderator for this webcast.
KEYWORDS
Control programming, automation programming, control programming languages, IEC 61131-3
CONSIDER THIS
Need more instruction? View the webcast until March 26, 2026.
ONLINE
Register for the Control Engineering webcast, “Practical advice for automation programmers,” archived until March 26, 2026, here:
https://event.on24.com/wcc/r/4889733/5E31A9026B9EBAF183113E22254C5167
See more answers article for more control system programming tips.
