Advantages of Re-Usable Code


Recently I’ve seen some good discussions on PLCs (Programmable Logic Controllers) vs. PACs (Programmable Automation Controllers), and it got me thinking about what really differentiates the two. Some have said that it is having a more powerful processor, or more capable software. Others have said that it is the ability to fully utilize all of the IEC 61131 programming languages and capabilities.

In the US, many programmers base their knowledge and abilities on their experience with Allen-Bradley’s products. After all, probably 70% or more of the installed base in US manufacturing consists of A-B PLCs. If so, the ControlLogix family was a huge jump in the capability of PLCs; among other improvements over the SLC and PLC5 families are the fact that it is tag-based, allows the use of UDTs, and has Add-On Instructions (AOIs). Tags could also be made local to each program, allowing them to be duplicated for re-use.

But all of those capabilities except for being tag-based already existed years before that on other platforms. IEC 61131 has existed since 1993 or so, and other PLCs leveraged that early on. Siemens for instance has had User Defined Types or Structures since the S7 platform came out, and local variables could also be defined within Functions and Function Blocks. As a matter of fact, Siemens’ Function Blocks (FBs) are very similar to Allen-Bradley’s AOIs, except that the retentive values have to be included in a separate data block.

In my opinion, one of the most important differences between the older, register-only based systems and the more modern ones is the ability to build re-usable code blocks. Platforms that support this must have several important features:

1. Local vs. Global variables. Re-usable code must have variables that apply to each instance of the code; ideally only formatting the data once for the original code. What I mean by this is that a list of tags or symbols should not have to be re-named for each instance or call. For instance, duplicating a subroutine several times and iterating the addresses inside of it, though it saves time, isn’t really re-usable code.

2. User-Defined Data Types. Creating UDTs allows structures to be built that can be exported from one application to another. They allow components to be described using generic terms such as “Speed”, “Start”, “Reject”, etc. UDTs don’t require tag based systems, but they do require advanced use of symbols. This is one reason the Allen-Bradley SLC and Micrologix systems really don’t allow re-usable code, while the S7 does, despite both being 1990s -era systems.

3. Protectable¬† Self-Contained Blocks. It is important that the code be contained in a block that allows variables to be passed in and out, and also protected so that users can’t change a specific instance of it. This requires a password or software key.

These are just some of the requirements. Other features like being able to write code in other IEC compliant PLC languages such as Structured Text also help make platforms much more powerful and “Rapid Code Development” friendly.

Whether your favorite platform uses subroutines with local variables or customizable instructions, reusable code is a critical part of creating powerful programs quickly! I am quite familiar with how Allen-Bradley and Siemens accomplish this, but I would love to hear how some other platforms allow for reusable code and what their methods are. Leave a comment here or send me an e-mail, I’d especially like to hear from users of CodeSys, Beckhoff, GE, Mitsubishi, Omron and Automation Direct!


Electrical Engineer and business owner from the Nashville, Tennessee area. I also play music, Chess and Go.

7 Comments on “Advantages of Re-Usable Code

  1. Lenze PLC Designer 3 is CodeSys based and IEC61131 compliant. The PLCs have motion libraries as standard and the code must be more sophisticated than a simple ladder programme. So modern programming techniques such as functions, function blocks, structures enumerations unions are utilised. It can even do OOPS which is perfect for reusable code. Variables don’t use addresses so the PLC variant and size is unimportant to the programme, any IO can be mapped at any time. There are 6 programming languages available which can be freely intermixed so if you like your logic in ladder, your maths in structured text and your machine sequence as a flow chart thats no problem. I have used Step7 and AB and they are okay but I do think CodeSys suits a programming background rather than an electrical background. I must state of course that I am employed by Lenze but this is my genuine personal opinion and not corporate hype.

  2. The code of any PLC software where the programmers can do his/her own function blocks is potentially capable to be reusable. The great challenge is to have codes codes that goes across PLC manufacturers. There are some intents to do that with Open PLC and the introduction the real object oriented software to the PLC world. Meanwhile the biggest player are no in.

  3. Yaskawa MPiec controllers are MultiProg based, 61131 compliant, and can be had for under $1000. Fuji and Mitsubishi offer some affordable 61131 complaint controllers, but US support and availability can leave a bit to be desired. I favor MultiProg to CoDeSys, but that’s a personal bias. The new Parker Automation Controller is CoDeSys based and also handles G Code, very interesting.

  4. TwinCat handles libraries of reusable code very well and the hardware is probably the most affordable out there, a half decent controller running windows embedded with Ethernet ports, USB and hdmi connection that by the way floors the execution times of pretty much any other PLC out there sets you back less than $1000. Definitively one of my favourite Soft PLC platforms.

  5. Phoenix Contact’s PCWorx platform makes software editing in IEC61131-3 flexible. Having the PCWorx Pro editor to program the standard ILC, through to Axio & the beasty Compact Controllers makes code creation & re-use easier since there’s no translation.

    Write the blocks & attach the variables. Create a library of Blocks to share with your programming team.

  6. I have worked with Schneider PLCs from 1998 to 2011 covering Modicon Nano, Modicon Micro and Modicon Premium PLCs. Nano had a DOS-based software in 1998 upto 2004 when it was discontinued. Nano was replaced by Schneider Twido PLC (Modicon brand name was discontinued) whose programming software was similar to that of Nano but based on Windows OS. Micro & Premium PLCs had PL7 Software based on Windows.
    At all times, the Modicon PLCs software was compliant with IEC-61131. I always made it a point to create standardize the PLC program by using same or similar portions of code (Flowchart and ladder logic was my preference) for the various elements in the machine.
    Subsequently with Schneider M340 PLC and UnityPro SW, I was able to continue to standardize the code with the combination of Flowchart and ladder logic.
    Now, when I look at the PLC Program that I created long ago (more than 10yrs), I am able to recollect the concept and debug / update the logic on those PLCs because I had standardized the code in the PLC.