Finding the Balance Between ST and LL
Playing with very obscure programming techniques and languages is a perk of being a Controls Engineer. For example, I recently spent part of my weekend creating an 'Add On Instruction' (AOI) for an Allen Bradley PLC. A Programmable Logical Controller (PLC) is the brain of an industrial process. The AOI is a programming feature available to Allen Bradley PLCs via the RSLogix5000 or Studio 5000 programming software. However, the concept of an AOI exist in most high-end PLC systems and also exist in traditional programming languages such as Java or Python as functions, methods or classes. Much like these, AOIs allow the programmer to easily reuse code. For example, if it takes 10 lines of code to control a motor and I have 50 motors then I can create 50 AOIs as opposed to 500 lines of code.
Most engineers that are passionate about their technical skills will look for opportunities to sharpen those skills during their free time. For me the opportunity came in the form of a burning desire to learn Structure Text (ST). I was recently on a project where Structured Text was a big part of the original design and I was there to add additional functionality by modifying the existing code.
Here is a quick breakdown. The go-to language in the United States for programming PLCs is Ladder Logic (LL). Ladder Logic's cousin Structured Text is more popular in Europe. Ladder Logic is prevalent in the United States because of the broad knowledge base engineers and technicians have for it. Ergo, if team player in the controls engineering community then Ladder Logic. I cannot emphasize how rare it is to find Structured Text in the United States.
Here are examples of code that set a variable (tag in PLC lingo) to a value of 100.
Here is an example of Structured Text:
myVariable := 100;
And here is the equivalent example in Ladder Logic:
---------------------------------------------[ MOV ]--
[Source 100 ]
[Dest myVariable]
Both languages have their advantages but broadly speaking Ladder Logic is superior in its ability to help someone trouble shoot the code especially when the code is actively running and Structured Text is superior when the programmer wants to program lots of code in a small area.
Here is an example of Ladder Logic to convert temperature from Celsius to Fahrenheit:
--------------------------------------------[ MUL ]------
[Source A rawInput]
[Source B 9 ]
[Dest temp ]
--------------------------------------------[ DIV ]------
[Source A temp ]
[Source B 5 ]
[Dest temp2 ]
--------------------------------------------[ ADD ]------
[Source A temp2 ]
[Source B 32 ]
[Dest newTemp ]
Here is the equivalent in Structured Text:
newTemp := rawInput*(9/5)+32;
The Add On Instruction ('AOI') allows the programmer encapsulate Structured Text inside of Ladder Logic. In this scenario the core logic is Structured Text but the programmer may deploy the Ladder Logic version of the AOI throughout the code.
The AOI version in Ladder Logic could look like this:
--------------------------------------------[ Temp_Convert ]----
[tempC rawInput]
[tempF newTemp ]
In this example, the Ladder Logic passes 'tempC' into the Structured Text and the Structured Text passes the calculated value back to 'tempF.' All the programmer needs to do is assign which tag is the input and output and these are the tags called 'rawInput' and 'newTemp.' The power of the AOI is fewer lines of Ladder Logic with the Structured Text serving as the number crunching in the background.
Finding the appropriate balance of technology and programming style is an important part of engineering industrial systems. Here is a classic example that many in the controls community are familiar with. It's Friday night at the customer site when part of the industrial system is not working correctly and the sole maintenance technician wants to trouble shoot the system. He opens the maintenance laptop, opens the programming software, connects to the machine, and begins looking in the logic. Perhaps a sensor is not working correctly or perhaps a timer is acting too fast or slow. Regardless, most people in this circumstances prefer to trouble shoot with Ladder Logic. Imagine if the maintenance technician opens the programming software and finds Structured Text even if the Structured Text is nested inside an AOI and the AOI is deployed with Ladder Logic. The maintenance technician will be very annoyed especially if Ladder Logic could have accomplished the same.
A couple of weeks ago, I spent a weekend learning Structured Text and now I feel totally comfortable with it. The following weekend I created an awesome AOI for tracking machine center downtime, calculating OEE, etc. Here is my plan: I deploy the AOI with Ladder Logic. The AOI encapsulates the Structured Text. The Structured Text packs an amazing amount of logic inside the AOI. I don't intend for any body to trouble shoot it in an emergency situation because its not designed to control equipment. I fully intend on reusing it again and again. To me, it's an example of the right balance between Ladder Logic and Structured Text.
I agree with David, a great article. If I wrote I would not change a sentence. More importantly, very solid advice. Thanks