While Control Engineering offers an hour of webcast instruction with practical advice for automation programmers March 26, archived for a year, find more answers from the instructors here related to programming automation and programmable logic controllers (PLCs).
More practical advice for automation programming insights
- Explore additional tips, tricks and best practices for controls and automation programming beyond those offered in the Control Engineering webcast, “Practical advice for automation programmers,” archived until March 26, 2026.
- Understand some instructors’ best practices can advance controls and automation programming skills and increase your value in automation programming projects.
- See the webcast and preview article for more advice.
Mark T. Hoske, Control Engineering
Instructors from the Control Engineering webcast, “Practical advice for automation programmers,” provide more answers on programming advice for automation and programmable logic controllers (PLCs) below. The instructors answered additional audience questions that they didn’t have time for during the one-hour webcast. The instructors are:
- Braden Hadwiger, mechanical engineer, Huffman Engineering Inc.
- Jason Israelsen, PE, senior control engineer, APCO Inc.
What’s the role of object-oriented programming (OOP) in automation programming?
Hadwiger: Object-oriented programming’s role in automation is to create templates that can be reused and can be used to make global edits. This is especially useful for encapsulating PLC code and pairing that with matching objects on the operator interface.
Israelsen: Object-oriented programming is a design approach that structures data into “objects”—self-contained entities that encapsulate data and related behaviors. These objects can have consistent attributes and data types, making them especially helpful for scalability, maintainability and revision control. In practice, I’ve seen objects used to provide consistent interfaces for things like controllers, lead/lag control schemes, VFDs, valves, blowers and other equipment. It’s a powerful tool for standardizing complex systems.
Instructors for the “Practical advice for automation programmers” webcast from Control Engineering, March 26, also provide information here based on audience questions after the webcast. The experts are Braden Hadwiger, mechanical engineer, Huffman Engineering Inc., and Jason Israelsen, PE, senior control engineer, APCO Inc.
Courtesy: Control Engineering webcasts
Do you have real-life mistakes and consequences or “learned the hard way” stories?
Israelsen: I’ve seen situations where I wish a different programming language had been used. One example that stands out is a project where too much Structured Text (ST) was used, which made it difficult for the client’s team to troubleshoot due to their limited background with text-based programming. Another example involved using Function Block Diagram (FBD) as the primary language in a batch process. While FBD is great for modular logic, in this case, the batch structure caused the code to become overly complex and difficult to troubleshoot or maintain.
How much do you depend on what the customer is familiar or comfortable with?
Hadwiger: Most programming I complete depends on the end user. Typically, they are adding to their existing systems and want to use what they are familiar with. However, there are instances where I can give recommendations for changes to how their systems are set up, such as trying to implement a custom function-block where it makes sense.
Israelsen: The customer should have the final say in which programming language is used. That said, open conversations about language selection are important—they help avoid the “because that’s how we’ve always done it” mindset.
It’s also worth noting that comfort and familiarity aren’t always the same. For example, a customer may be familiar with Language A but actually more comfortable working in Language B. In general, graphical languages like Ladder Diagram (LD) and Function Block Diagram (FBD) tend to be more intuitive for most teams and are often a good starting point for broader usability.
How is artificial intelligence (AI) assistance improving programming productivity, safety and reliability, and what are the pitfalls of using this tool or approach?
Israelsen: AI assistance is great for standard solutions. I’ve seen it help with syntax, logic templates and general insight into well-established programming patterns. Where I’ve seen it struggle is in creative or non-standard scenarios, especially those involving novel approaches or niche implementations. I see AI as a helpful tool to generate ideas and kick-start development, but ultimately, the programmer is still responsible for the final solution. It’s important not to over-rely on AI and to fully understand the code it produces before using it in production.
Is there a programming language that is more adaptable to AI or AI friendly?
Israelsen: Because most AI tools are text-based, they tend to work best with text-based programming languages, such as Structured Text (ST). Additionally, open and widely adopted languages typically yield better results when using AI—for example, getting accurate syntax suggestions or reliable code generation. In contrast, proprietary or niche languages may have limited support or less accurate output.
What is your preferred approach to cybersecurity?
Hadwiger: Huffman Engineering’s approach to cybersecurity is to follow the Purdue model for Industrial Control Networks [from bottom-up, device, controls, supervisory levels]. This involves segmentation of different levels and networks in a facility and installing security appliances at the appropriate levels. If no data needs to be accessed externally, another approach is to seal off the network from the outside world completely and create what is known as an “air-gapped” network. However, this is not always practical depending on the type of facility.
Do you have any tips for organizing tags and comments in a way that makes projects easier to scale and troubleshoot later?
Hadwiger: The best way to make projects easier to scale and troubleshoot is to create a PLC standard that defines some of these items. For example, if my PLC standard says that all of the manual control of a motor is located in a control module routine for that motor, I know where to look in any PLC program that follows the standard. Creating a PLC standard to implement modular programming and organization also makes a project easy to scale as changes are made only to the routine they affect and new routines are added without changing old ones.
Israelsen: Yes—start by organizing tags based on equipment, control loops and location context. For example, if you have multiple signals coming from a motor, include an identifier that groups those tags logically (e.g. Motor1_RunCmd, Motor1_Status).
For larger systems, consider adding site numbers, building numbers, or area codes to your tags to support multi-site or multi-building architectures (e.g.,, Site01_BuildingA_Motor1_RunCmd).
Tag naming can be descriptive or follow a structured standard like ISA-5.1, depending on the application and audience. ISA-style naming is especially useful in regulated industries or large-scale systems where consistency and traceability are critical.
Object-oriented programming can help enforce consistent naming and organization, and having a well-defined naming convention is key to creating scalable, maintainable and easy-to-troubleshoot projects.
What are best practices for writing add-on-instructions?
Hadwiger: When writing add-on instructions, make sure to add plenty of comments and documentation as the template will be reused and will help in troubleshooting later. Another item is to make sure the testing process is very robust before placing them in production as some software does not allow online changes to add-on instructions and requires a PLC download, which creates downtime.
What are recommendations on version control and change management software?
Hadwiger: I’d recommend starting with your PLC manufacturer to see if they have a version control software offering. This often integrates the best with your version of PLC and can work with other brands as well. Otherwise, I would look for some that is intuitive to use or one that can be adapted easily. For example. Huffman Engineering uses both types, one from one of the PLC vendors we use and a software that was intended for 3-D modeling. We are to store code libraries in the PLC vendor software, and we adapted the other to version control drawings and documentation.
Are there conversion tools to convert Ladder Diagram to Function Block Diagram?
Hadwiger: This depends on the software. One approach would be to just encapsulate the ladder logic in a function block if it makes sense to do so such as motor control code or analog scaling. Otherwise, most ladder could be converted to function block by using the ladder logic to create a system map to then rewrite the code in function block.
Mark T. Hoske is editor-in-chief, Control Engineering, WTWH Media, [email protected], and moderator for this webcast.
CONSIDER THIS
- Need more instruction? View the webcast below or share with a friend.
ONLINE
- Register for the Control Engineering webcast, “Practical advice for automation programmers,” archived until March 26, 2026, here: https://gateway.on24.com/wcc/experience/elitewtwhmedia/2927718/4673040/ce.
- Also see the webcast preview article for even more control system programming tips.
