Chapter 8: Options to Consider When Creating PLC Blocks

This chapter explores additional options to consider when creating programmable logic controller (PLC) blocks. There are many different approaches that programmers can take when designing, creating, and then implementing logic solutions. This chapter explores how to retain standardization while offering a flexible approach.

In this chapter, the following topics are covered:

• Extending standard functions
• Extending standard data
• Managing data through instance parameters
• Asynchronous data access considerations

Extending standard functions

A well-built paradigm or design pattern should allow for the extension of standard objects without affecting the object itself. For example, standard objects should consist of other standard objects that can also be used outside of their parent object.

Have a look at the following screenshot:

Figure 8.1 – Example of an extension

Figure 8.1 shows an example of an extension whereby Standard Object Instance 3 has an additional instance of Standard Function Block 1 that is used outside of the normal parent. Because all instances of Standard Object use Standard Function Block 1, and Standard Function Block 1 is in itself a standard, it can be used outside of Standard Object, and data that would normally be passed to Standard Function Block 1 from the Standard Object interface can be passed directly instead.

If the example in Figure 8.1 were to be replicated in Totally Integrated Automation Portal (TIA Portal), the Standard...

Extending standard data

Similar to program blocks, standard data blocks that use UDTs or structs can also be easily extended without breaking standardization. For this to work, a data block needs to be structured in a particular way.

Have a look at the following screenshot:

Figure 8.4 – Example of a data block structured with UDT and bespoke data

Figure 8.4 is an example of a data block that consists of the following two areas:

• Asset UDT Data—This is the data that standard objects will access.
• Asset Bespoke Data—This is an extension of the standard data.

Now, have a look at the following screenshot:

Figure 8.5 – Example in TIA Portal data blocks

Figure 8.5 demonstrates this pattern in data blocks. Asset_1 has the UDT defined as a variable named Typed, and that is the only variable that appears in the data block. This means that any standard object that requires data from Asset_1 can...

Managing data through instance parameters

When creating standard objects that have multiple methods of operation, it is worth considering which resources may be shared between the methods that an object can use. Sharing resources has a positive impact on memory allocation and simplification of an object.

Principle to this approach

Consider a standard control object that can be run in one of three modes. Only one mode can be run at any one time. You can see an example of this in the following screenshot:

Figure 8.7 – Example layout of a standard control object with multiple control methods

The standard control object accepts a common data structure (UDT, for example) and contains logic to read the selected method. In Figure 8.7, the three methods contain different timers that are in use. All methods require at least one timer, with the largest method (Method 1) requiring three timers.

If a function block were written in this manner, it would...

Asynchronous data access considerations

It is important to remember that many modern human-machine interfaces (HMIs)/supervisory control and data acquisition (SCADA) systems will access PLC data asynchronously. This means that instead of waiting till the end of the PLC scan to obtain or write data, the HMI/SCADA system will interrupt the scan to update or obtain data.

Normally, this is not an issue. However, when references via InOut interfaces are in use, it can cause unexpected behavior. This can be very difficult to diagnose because the next time data is updated, it may not be updated in the same place in the scan.

Have a look at the following screenshot:

Figure 8.13 – Example of an erroneous configuration with InOut interfaces

Figure 8.13 is an example of a configuration that is valid by the compiler but introduces issues if data blocks are interfaced with an HMI.

The blue data blocks represent asset data—they are connected to InOut...

Summary

This chapter has covered the topic of extension. This is when standard control objects' standard methods are extended outside of the standard control object, usually by using a child object that already exists.

This form of extension is a solution to adding methods to a project without changing the standardization of objects.

This chapter has also covered the extension of standard data. This allows asset-oriented data to consist of standard UDT data that is extended by bespoke data. This further supports the method extension by allowing non-standard setpoints and other data.

The next chapter moves away from PLC and over to the TIA Portal WinCC environment, in which HMIs and visualizations can be created to support projects.