7 tips every PLC programmer should know

A good programmable logic controller (PLC) programmer should always keep the end user in mind and write code that is understandable and reusable. Using efficient methods and practices makes life easier for the programmer as well as the client. Every programmer should know these seven tips to make full use of the PLC and control system.

1. Implement modular systems.

In a modular PLC system, several additional modules can be used, which offers the advantage of overall flexibility. A modular PLC system also offers scalability, ability to accommodate a greater number of I/O devices, easier troubleshooting and a faster system in general because the modules can be easily replaced.

PLC programs should be organized in a way that makes sense, such as by separating out each of the devices and using a structure that can be reused and easily understood. When using a modular structure, the programmer can make modifications across all devices of the same type rather than by making changes for each individual device.

Keeping the code modular allows all parties to understand where the responsibility lies for each section of code. For example, if there is a stack light, the code that drives it is coming from a stack light structure rather than from a mode block.

2. Structure the code as specified by the client.

The programmer analyzes the end user’s specifications and drives a code standard to follow suit. This gives the maintenance teams and support staff a standard layout and structure so they can easily understand and support the equipment on a day-to-day basis.

The end user will specify the programming environment for the PLCs to be consistent with the type of equipment in the facility, ensuring that all functions and features work properly. During the development phase of the project, the programmer should reuse any standard code blocks or other code that has already been developed for existing interfaces. Although it may take the programmer a bit longer to come up to speed on those code blocks, the end user’s personnel are already familiar with it and can support it more easily than learning a new interface.

3. The “right” language is not always the “best” language.

Programmers are not always able to use the “best” language for the application; they must follow what the end user is specifying. As mentioned above, the client’s team will be handling the equipment at the plant on a day-to-day basis, and if they aren’t familiar with the programming language used and can’t support it, the programmer is going to get the 2AM call when the equipment goes down.

The IEC 61131 languages are the only languages typically employed in a production setting. Different manufacturers may have a proprietary language brand, but they are all mostly the same. One difference is for specific functions, for example, a search or sorting routine. A search or sorting routine with “for” or “while” loops is not as clean and easy to follow in ladder logic as compared to a higher-level language such as structured control language (SCL), for example. Where the code might just a few lines in SCL, it may take 10 to 15 lines to execute the same function in ladder logic.

PLC programs should be organized in a way that makes sense, such as by separating out each of the devices and using a structure that can be reused and easily understood. Courtesy: Applied Manufacturing Technologies

4. Understand data processing needs.

What data processing will be done in the cell? If the system needs a manufacturing execution system (MES) but doesn’t have one, that places a tremendous load on the PLC for storing, retaining and managing data. These functions should be performed by an external PC instead.

If the user has recipe control systems, the primary means of data parsing should be on a PC rather than on the PLC, based on how big the recipes are. If there are intermittent search routines or high-load routines, they can drive up the scan time and could miss sensors. These situations can have a major impact on how the PLC performs.

5. Make sure the code is well commented.

Make sure the code is well commented. Obviously, the programmer understands the details and intricacies of the code when it is being written, but the code will no longer be fresh in the user’s mind when called to troubleshoot at the site weeks or months later. If the code has unusual sections that are outside of what would ordinarily be seen, extra comments will help the next programmer understand why the code does not look as expected. This could prevent future programmers from making changes to “fix” the code, which could potentially create a worse situation.

6. Standardize fault messages.

When programming the system, make sure all fault messages are targeted and are standard across the same types of devices. If a sensor can fail in a certain way, make sure the fault is configured the same way for all the sensors in that system. Similarly, cameras, or any type of device that is connected to a PLC, will have specific failure modes. Ask the end user what failure modes they have encountered and plan for those contingencies, as well.

7. Match the software environment to the PLC brand.

To ensure maximum stability and avoid any unexpected problems, if possible, use the same environment as recommended by the PLC manufacturer. This will allow the code and application experience to be as seamless as possible.

Keeping the end user in mind throughout the process and follow these simple tips for better efficiency, stability, and user experience.

Alex Kennedy is a senior control engineer at Applied Manufacturing Technologies, a CFE Media and Technology content partner. Edited by Chris Vavra, web content manager, Control Engineering, CFE Media and Technology, cvavra@cfemedia.com.

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.