PLC programming: What you need to know

While the programmable logic controller (PLC) is very important, the programming inside the controller is just as critical and can be overlooked.

By Matt Fether July 7, 2022

Courtesy: Matrix Technologies Inc.

Learning Objectives

Programmable logic controller (PLC) programming starts during the definition phase of a project while generating the design documentation.
PLC programming should be done in such a way so it is easily understood by the end user.
Standards and the specific application also should be considered with PLC programming.

Programmable logic controllers (PLCs) act as the foundation for many manufacturing operations and are capable of many tasks. While the controller is very important, the programming inside the controller is just as critical and can be overlooked. Matt Fether, a department manager at Matrix Technologies, offers insights on how he programs PLCs and tips on how to make programming easier.

Question: How are your PLCs getting programmed?

Answer: This starts during the definition phase of a project while generating the design documentation. If a control system is properly defined and documented by following the proper procedures for project execution, then the actual programming of the controller is a medial step in the project execution and provides for a more efficient development. The use of reusable code, standard object libraries, and replication tools are a few items to leverage to further enhance the efficiencies of the development. Use testing procedures throughout the programming phase on projects. If an operation is to be generated on more than one unit, generate the operation on a signal unit and thoroughly test it before replicating it for the next unit(s).

Use replication tools during development to save time and help to eliminate the “fat fingering” aspect that comes along with just banging away on a keyboard to generate programs.

Q: Are PLC programs organized in a way that enables others to modify or update them later?

A: Produce applications that can be easily interpreted by the end user. At the end of a system integration project, the applications generated and/or modified are turned over to clients. It is best to develop applications in a way that those who work with the systems regularly can understand them. A system integrator should become a partner with a client, rather generating “proprietary” applications. System integrators should have design reviews with clients throughout the project lifecycle. This helps to ensure continuity between the client’s expectations and the system integrator’s design.

The organization of an application starts well before any programming ever takes place, and at a minimum should at least be considered during the proposal phase. Multiple factors are considered includingwhat the application is controlling, the size/complexity of the system, and whether it is a brand-new application or modifying an existing one. It also is important to discuss the organization with the client to understand their standard nomenclature and areas of their plants so they can be incorporated into the applications. Again, the goal is to generate applications the end-user can easily navigate to locate specific equipment and/or devices. Easy navigation is especially important when troubleshooting during production. Any additional downtime to a process or equipment due to “combing through PLC code” results in a loss of revenue.

The following screen capture illustrates PLC code that was recently implemented for a batching process. It is written in ladder logic, using Studio5000 Logix Designer software from Rockwell Automation, for a 1756-L75 processor from Rockwell Automation. Courtesy: Matrix Technologies Inc.

Q: Do you have expertise on hand to debug the code?

A: When an automation engineering staff is well versed in debugging code, engineers assigned to the project are responsible for the definition, development, and commissioning of the developed applications. This entails the debugging of the initially developed programs to ensure they are ready for the factory acceptance test (FAT) as well as during the onsite commissioning phase of the project. This provides a more efficient and successful project for clients.

Using a thorough testing process that starts during the early stages of programming helps eliminate the time-consuming exercise that comes with debugging an entire system and helps ensure applications are successfully developed.

There can be certain circumstances when additional resources may be needed for either the final internal testing or onsite commissioning phases of a project. Schedule timelines and/or project complexity may require additional resources to finalize internal testing of programs. Properly defining applications and ensuring they are properly organized helps make this a near-seamless transition.

There can be instances where a resource not involved in development is needed for the project commissioning phase. While this is not ideal, by following project execution procedures and having a thorough project handoff, the new resource can come up to speed quickly.

Q: Are you using the best language for the application?

A: While there are several different programming languages, the most common continues to be ladder logic. Some applications are written in structured text or use function blocks for certain tasks. Structured text may be used to add functionality to an existing programmable controller that was originally programmed in structured text. Function blocks can be used for certain tasks such as for analog input filtering or proportional-integral-derivative (PID) loops. However, some vendor software packages require a certain level of licensing to access the function block programming. If the end user is limited on accessibility based on current software licensing, then using function blocks would limit the ability to view and/or modify the programming in the future.

An engineering consulting firm, should use the programming language our clients are best suited to support once the system is put into operation. It is not helpful to provide clients with proprietary applications that they cannot access and maintain. The best language for the application is the language client will be happy with at the end of the project.

Q: Other than traditional IEC 61131-3 programming languages, what should be considered?

A: Several factors need to be considered prior to developing programmable controller applications. The most critical is how the system should be architected that best suits the immediate need yet allows options for easy expansion soon. The process or equipment being controlled should be considered, as well. Is the correct hardware and software package being chosen for process or equipment? If the system being controlled is a packaging line, are we following the OMAC PackML model or using a client’s provided model?

Standards also need to be considered prior to any development. Is the application going to be using any ISA standards like the ISA-88 model for batch process control? Will we be using any client provided or vendor provided global objects? These two questions, along with many others, start to provide an insight into the controller memory size required.
Another important consideration is the overall system architecture design. Understand what the existing, or potentially new, network architecture is going to look like. Does the system need, for instance, several communication modules to function while providing a robust/secure network design?

Also consider any potential interface with manufacturing execution systems (MES) and data collection systems. Do either of these systems require any tagging structures and/or nomenclatures we will need to incorporate into the application?

These are a few examples of several considerations that need to be accounted for before programming begins.

When architecting control systems, ensure the programming fits the application’s immediate needs, as well as allowing for future expandability.

Matt Fether is department manager at Matrix Technologies, a CFE Media and Technology content partner. Edited by Chris Vavra, web content manager, Control Engineering, CFE Media and Technology, cvavra@cfemedia.com.