What You Need to Know About PLC Program Structures

    Posted by Jacob Miller

    Aug 4, 2017 5:10:42 PM

    Read Time: 9 Minutes FUSIONOEMCOLOR (92).jpg

    A program is the brain behind any automated system, it takes inputs from various sensors or devices, makes logical decisions based upon that information, then determines a desired output, such as moving a load, communicating information, or even waiting for more information.  As you can probably guess, even a relatively simple system can quickly get complicated as user adjustments, environmental influences, and interruption recovery are accounted for. Any seasoned programmer knows there is more than one way to control a system and achieve the desired effect, and each solution is as unique to the programmer as their personality.  While this flexibility is an advantage to ensure each system is optimized for its physical differences, it also adds a particular and challenging problem when it comes to multiple programmers working in, or supporting the same piece of logic.


    There are three main advantages to having a solid and consistent program structure.  First, multiple programmers are able to share the work load while designing and creating a program.  A well-structured program allows for the code to be easily handed off between programmers, or for multiple programmers to work on various sections, while ensuring the final product is a cohesive unit. Second, programs can be quickly and stably modified across similar machine platforms.  A well-structured program allows for various sections of logic and their function to be easily identified and sections of logic to be quickly and confidently added or removed.  Finally, and probably most important to seasoned programmers, is the advantage of being able to troubleshoot, and support legacy products.  A well-structured program will allow a programmer to quickly and confidently gain an intimate understanding of the machine, even if it was written years, or decades earlier.  This dramatically reduces the risk of updating or modifying a system that has been functioning.

    Characteristics of a well-structured and thought out PLC program will include the following: 

    1. State Logic, a method for laying out the actual transition of the logic.  
    2. Clear Comments, helping a user understand where they are in the logic and what the original programmer was thinking.
    3. Program Organization Units (POU's), a structuring method for allowing modular growth of a program.
    4. I/O Mapping, a strategy for program format which makes utilizing the same program across multiple platforms a simple process.

    State Logic

    PLC's have traditionally been programmed in a language referred to as Relay Ladder Logic.  Relay Ladder Logic, is very simply controlling various outputs or internal bits, based on inputs or internal bits.  Typically, due to the number of possibilities, multiple rungs of logic, each with its own set of bits, are needed to create the desired scenario.  This method of programming, while the simplest to get started, can quickly become overwhelmingly complicated, and navigating the logic feels like navigating a bowl of spaghetti.  Without a clear understanding of the purpose and impact of each rung, even minor updates can result in unexpected and catastrophic changes.  

    With the development of PLCopen (IEC 61131) and its Sequential Function Chart (SFC) programming method, a much cleaner or more reliable method of program structure has been adapted, commonly referred to as State Logic.  State Logic is very simply defining a set number of "states" or conditions, that the machine can be in.  The logic will then sequentially move through different machine states, one at a time.  The current state of the machine is what will drive various outputs, or trigger various functions.  The initial development of a State Logic program can be labor intensive and complicated, as different machine states must be identified, along with the decisions or conditions that will allow for the logic to progress to the next state.  A natural tool for defining state information is a flow chart.  A flow chart is a pictorial diagram of how the machine's logic should function.  An additional and extremely valuable benefit of creating a flow chart, is the opportunity for customers or non-programmers to be able to understand how the machine will function and make decisions, prior to investing in all the labor in creating the logic, and function requests or changes can quickly be added or addressed early on in the project.  Once a Flow Chart has been created and reviewed, the state logic can quickly and accurately be added to program.  The documented flow chart can also be an extremely useful tool to train or hand off the logic to another programmer, they are able to see and understand all of the critical decision making logic before ever opening the program software.

    State Logic programs should be laid out sequentially, and grouped together by state.  This allows for a programmer to quickly find the state the machine is in, and isolate any conditions that will allow the machine to leave that state.  With this structure and information, a programmer can positively assess all scenarios before adding or modifying the logic.  Changes can be made in a controlled manner, reducing the amount of risk.


    A Comment is a label, it is a string of characters in the same place as the logic, that has no impact on the function of the machine.  A clear set of comments allows insight into what the original programmer was thinking and trying to accomplish with each rung of logic.  With the introduction of PLCopen (IEC61131) commenting a PLC program has never been easier, there are many ways to comment a program, and when all used together the can provide a complete picture of how the logic should operate.  Tag names are the first line of commenting.  A tag name (available in PLC's that conform to IEC61131) allows the programmer to assign a unique string of characters to identify a bit in the logic.  Instead of using a memory number, an easy to search and remember name can be given.  This allows tags to be structured and grouped in a manner that is convenient and easily findable.  For example, a bit that turns on when an e-stop is pressed could be named: Fault_EmergencyStop_Pressed, this bit tells you a lot of information about what this signal should be doing throughout the logic.  Additionally, when the tag list is sorted alphabetically, all similar functioning tags will be grouped together.  

    The next step of commenting, would be the tag description.  The name of a tag should be descriptive, but tag names that are overly long, can be hard to read and cumbersome to navigate in the actual logic.  The tag description can be written with proper English in sentence format and contain more information that will help a programmer understand how that bit functions, or even how the real-world input is supposed to act.  For example, adding information about the signal, such as (High=Blocked) for a photoeye sensor, allows the user to know how this photoeye has been wired. 

    The final method of commenting, in a well-structured program, would be comment blocks inserted through the program logic.  These blocks allow visual breaks in the logic when scrolling through multiple rungs, they also allow critical information about groups of logic to be quickly communicated.  Math equations, Formulas, and Conversion Logic in a PLC are often hard to fully grasp and identify.  A comment block is an ideal location to add the formula being used, a sample equation, or even constant values or rules that were assumed during the creation of that calculation.  Having this information readily available saves substantial and valuable time while supporting and debugging logic.  The programmer is able to identify, in a familiar format the exact goal of that logic, and even verify the original thought process.  Another extremely beneficial use for Comment Blocks, is on deactivated rungs.  Many times, rungs are deactivated for testing, a programmer may want to cancel a rung, or perhaps modify a rung without completely removing the old logic.  Uncontrolled, this can create a messy and cumbersome project.  In an ideal scenario, each programmer would go through and remove negated or deactivated logic regularly, real world experience confesses that this rarely happens.  Adding a quick comment block to deactivated logic, indicating the date, your name, and the reason why you chose to negate the logic, will allow you or future programmers to accurately assess if that chunk of logic can be safely and permanently removed, keeping a program neat and efficient.


    Program Organization Unit's (POU's) is a further defined method for grouping and organizing logic. Traditionally logic was kept in one program file, this means that a user will have to continue to scroll through however many lines of code there are for that particular program.  A program only using a couple hundred lines of code, may not be that difficult to navigate, but as the program grows tens of thousands of rungs, soon just finding one rung of code or even a section of code can be difficult, time consuming, and increase the chance of error.  With the development of PLCopen (IEC61131) came the use of Program Organization Units, this allows a section of code to be defined, and moved into its own sub-routine.  This allows for a user to only search relevant code for the rung he is looking for.  For example, if the Fault Logic can be isolated to one POU, a programmer looking to review or modify the fault logic, now only has to scroll through rungs that have to do with Faults.  This allows problems and modifications to be made much quicker.

    POU's can introduce an additional benefit as entire sections of logic, can quickly be copied to different platforms, or removed or deactivated for testing.  This allows for common, and well proven chunks of logic to be easily used repeatedly.  Effort and thought put into POU structure and logic layout, will continue to pay dividends as that logic can be re-used and further refined.

    IO Mapping

    Input and Output Mapping is mapping each real-world PLC input or PLC output to a user defined tag (UDT) inside the logic.  Each real-world input or output is connected directly to an address independent tag, which then gets used throughout the software.  Often a real-world input will need to be used in multiple places throughout the program.  For example, if there is a proximity sensor that is detecting product, you may use that input to make a decision when it is blocked, you may make a different decision when that sensor is not blocked, further you may use that same sensor input in tandem with other sensor inputs to make completely different decisions.  The complication is introduced when an address needs to get changed, perhaps an additional I/O card was added resulting in shifted I/O addresses.  Or perhaps the software is being used on a similar machine platform, but the new machine was wired differently.  Traditionally the only option would be to scroll through each rung of the logic, searching for the bit that is being used, then updating the address in each location.  When using I/O Mapping, the bits being used throughout the logic are independent of the physical address.  This means by updating in one spot, where the physical address is mapped to the internal bit, you are able automatically update the signal throughout the entire logic, everywhere that signal is being used, without having to worry about accidentally changing which side of the signal (on or off) was originally trying to be used.

    Grouping Input and Output Mapping into their own Program Organization Unit (POU) allows for a programmer to quickly isolate the I/O Mapping, and quickly make changes where needed.  This also allows for a programmer, who knows only what output is turning on in the real world, to quickly back track to see what conditions are turning that output on.


    When the State Logic, Commenting, POU and I/O Mapping tools are all used to their full potential, a program can be fun and easy to navigate and support.  Each of these tools can, and should be, further configured and defined for consistent use across a department, allowing for easy training and quick on-boarding of new products.

    Topics: plc, programming

    Subscribe Here!

    Latest Blog Posts