Advanced Structured Text — Programming a PLC in Easy-to-Read English

This chapter is dedicated to exploring concepts that many PLC programmers may find exotic. However, if you have a background in a traditional language, these concepts will seem very familiar.

Structured Text has many attributes that are like traditional programming languages such as C/C++, C#, Java, and the like. The IEC 61131-3 standard has adopted many of the features that are standard in most modern programming languages. However, due to the limited computer programming background of many PLC programmers, coupled with many PLC programmers relying solely on ladder logic, these concepts are often not known or fully understood.

The goal of this chapter is for you to learn how to write software that can fail gracefully without killing your PLC, how to access data directly from memory, how to properly document code, and more.

The topics covered in this chapter are not necessarily complex but are often...

Technical requirements

To follow along with this chapter, you will need to create a new Structured Text project and name it Chapter2. The project is created in the same way the Hello, World! project was created in the previous chapter. When creating the project, ensure you select Structured Text instead of FBD or Ladder Diagrams. The code for this chapter is also available on GitHub. It is recommended that you follow along with the examples in this chapter and then pull down the code from the cloud so you can modify it. The source code for this chapter can be pulled from the following link:

https://github.com/PacktPublishing/Mastering-PLC-programming/tree/master/Chapter%202

Understanding error handling

Errors can kill the execution of a program, which, in turn, can lead to injury or death. A fatal error will halt the execution of a program. These fatal errors are typically called exceptions. Essentially, an exception occurs when the PLC encounters a problem that it cannot handle at runtime. The ultimate fate of the PLC when an unhandled exception occurs is the program locking up and the PLC needing a reboot. On top of all that, if the condition that caused the error originally occurs again, the program will crash again, and the system will need to be rebooted. In essence, the only safe way to handle the condition is to modify the code to ensure that the condition does not happen again.

Exception errors will not show up during the compilation process. Instead, exceptions occur when the program is running. Due to their nature, it is often difficult or impossible to fully predict when an exception will occur. To make matters worse, some exceptions can...

Understanding pointers

To understand a pointer, it is first necessary to understand the basics of how variables are stored in memory. For many PLC programmers, creating a variable or a tag is simply inputting a name and assigning it a data type. However, some mechanics go on under the hood. For starters, a variable is much more than just a name and a data type that holds a value. A variable is a dedicated memory block that the computer, in this case, the PLC, uses to hold a value of a specific data type. The memory block is generally not human-readable; as such, the variable name is just a human-readable facade that makes accessing and manipulating the data in the memory block easy.

Representing PLC memory

Figure 2.7 is a graphical representation of a PLC’s memory. It is a simplified way of conceptualizing how the PLC sees its memory addresses:

Figure 2.7 – A graphical representation of computer memory

As you have probably deduced,...

Understanding references

A reference is a type of pointer that is more user-friendly and requires less syntax than a traditional pointer. A few big advantages of using a reference are that you do not have to use the ^ symbol, you do not have to use the ADR operator, and finally, references are type-safe.

References share many similarities with pointers, including similar syntax. As such, much like pointers, a reference must be declared. Therefore, the first step in learning how to use pointers is to understand how to declare them.

Declaring a reference variable

Declaring a reference is almost the same syntax as declaring a pointer. This can be thought of as a shorthand way of using a pointer. The only difference is that the REFERENCE keyword is used as opposed to the POINTER keyword.

This is the syntax to declare a REFERENCE variable:

<variable> : REFERENCE TO <data type>

Putting this syntax into practice, we can create a reference to an integer, as in...

Understanding documentation

For many programmers in general, documentation is viewed as more of a petty pain than anything else. However, proper code documentation is vital to the longevity of a codebase. With that being said, it is often not clear what should be documented or, for that matter, how to properly write documentation.

The past code examples were easy enough to understand when the proper context was provided. However, if the context was taken away, chances are you would have a difficult time figuring out what the code did. In practice, this is very bad. Other developers that inherit your work should be able to open the project and understand the code with minimal effort.

Documentation also helps you personally. Let’s assume that in 6 months when your customer wants an upgrade, you’re going to be the one who is going to implement the upgrade. Chances are you’re not going to remember how the code works. There is no silver bullet that’ll make...

Understanding state machines

As a software engineer, especially one that writes PLC code, you must understand what state machines are. State machines to PLC programmers are what the Model-View-Controller (MVC) pattern is for web developers. To be a quality PLC programmer, you must understand what a state machine is and how to implement one.

The most simplified way to think of a state machine is as a series of states that can transition from one state to another. A simple example of a state machine is a lightbulb connected to a switch. The following diagram represents the state of a lightbulb:

Figure 2.14 – Lightbulb state machine

As can be seen with the arrows, if the lightbulb is on, it can transition to off when the switch is flicked down. If the lightbulb is off, it can transition to an on state when the switch is flicked up.

The majority of state machines that you are going to work with as a PLC programmer are called finite state machines...

Summary

This chapter has explored some of the more complex features of the Structured Text language. Many of the features explored in this chapter can help improve the quality of your PLC code. In short, error handling can help catch unforeseen errors, proper code documentation can prolong the lifespan of your codebase, state machines are a vital part of any PLC program, and although pointers may not seem that important now, they will become more prevalent as the book progresses.

Of all the concepts explored, state machines, documentation, and error handling are going to be used the most in the day-to-day life of a PLC programmer.

Now that Structured Text has been explored, the next thing to explore is debugging.

Questions

Answer the following questions based on what you've learned in this chapter. Cross-check your answers with those provided at the end of the book, under Assessments.

1. What is the difference between a pointer and a reference?
2. What does the ^ symbol do?
3. What are three keywords that can be used with a TRY-CATCH block?
4. What is self-documenting code?
5. What is the difference between a good comment and a bad comment?
6. Why should you code to a variable?

Further reading

Have a look at the following resources to further your knowledge:

• CODESYS documentation for TRY-CATCH statements: https://help.codesys.com/api-content/2/codesys/3.5.13.0/en/_cds_operator_try_catch_finally_endtry/
• CODESYS documentation for pointers: https://help.codesys.com/api-content/2/codesys/3.5.14.0/en/_cds_datatype_pointer/