TwinCAT 3, Using Methods for internal FB functionality or just for interfaces?

Question

I´m old users of Beckhoff technologies, especially TwinCAT. At the moment, we are suffering a transformation of our PLC architectures due to the new functionality that are bring by TwinCAT 3 (Object Oriented)

At the moment we are developing our new PLC architecture and we are having several concerns about how to go forward. One very good example that is pretty much taking our attention at the moment is the new Methods and the overall differences with the Actions.

From my own point of view Methods are created not just in order to define and implement interfaces but also as a way to simplify the FunctionBlocks and their internal state machine. For example, if I have a FB_Conveyor which has its own state machine inside I could select to create and internal METHOD (M_INIT) for the conveyor which will inspect the conveyor in order to check if there is any products when conveyor it is in INIT state, checking the Method output value. MEthod will contain its won state machine and will not be ready until it´s output returns TRUE value.

The first concern comes here, as some of our realtime programmers opinion is that methods are not done for this, that in this cases we should implement FB_INIT which is called from the FB_CONVEYOR and it contains its own variables, so both have a REF to FB_MOTOR.

The principal argument is that METHODS are a tool in order to create interfaces and control FBs, so for example that my own FB_CONVEYOR could have been extended from a I_Conveyor which has a method M_TakeIn, but NOT for implementing internal functionality as initializing it.

One argument is also that Methods use its own stack variables, so all data of a method are temporary and only valid during the execution time. This means that if methods goes too big by the one implementing it we will not be able to ensure correct latency on the realtime. Then on my own experience TC will always take as much resources of processor to ensure the correct cycletime, so using internal stack variable is not actually an architectural mistake, but it is ok and desirable because actually TC ensure real time operation but doesn´t need to be implemented as a total realtime (C based real time) process.

Discussion has been going on, and it is very interested how different opinions are coming to place regarding the fact if Methods should be used or not as an internal operation or should we actually follow the architecture of TC2 Motion FBs, where different function block control different functionality and each one share a REFerence to certain Axis (FB_MOVE, FB_HOME, etc)

Haven´t found any real answer to this in any documents, Methods are pretty much always mentioned in case of defining interfaces but never in case of programming internal FB functionality.

So, is it ok to use Methods for internal functionality, this will help in the future when converting the hole FB in an interface for which the method init would need to be re implemented depending of the case.?

This question is pretty much the same for new versions of CodeSyS which are also having methods and interfaces.

Answer 1

The Method is different from Action mostly because it has it's own declaration. By default, all variables in method will be of VAR_TEMP type, meaning that they will only exist during the run. So each cycle they will be reset. VAR_TEMP using limited stack space and large data types can't be declared as such.

But you can declare any type of variables inside the method. Like VAR_INST that will be private for each instance as it's created at FB (Function Block) level (default variable in FB). Or you can declare VAR_STAT that will be common to all instances. Method can make the code much more clear.

Both Method and Action can use all variables from it's FB.

Both Methods and Actions can be developed using different programming language than the FB. Example: the FB is written using ST but it's Method or Action can by written in Ladder Diagram.

Personally I see no connection between Method existence and Interface. I would not hurry to use all the functions that OOP has to offer. Inheritance, Interface and Properties can make your program a nightmare if not used wisely. While Encapsulation in TwinCAT is virtual at best.

Edit: When Method is created in Program (static object in TwinCAT) VAR_INST cannot be created in this method, as no instance exists in Program. Only VAR_STAT and VAR_TEMP can be used in Program's method. It's very similar to other programming languages that cannot instantiate static classes and their variables can also be only static.

Answer 2

you have pretty much got the point but still to cut the long story short, function blocks in PLC define a general "class" of functionality. This class will have certain inputs and outputs, and methods/actions to manipulate them. One has to create an instance of the function block, to use the methods. The instance lasts as long as program's execution and deleted afterwards (PLC stop).

In the new TwinCAT and CodeSys, actions have been extended with methods. The methods have their own input and output variables and code that manipulates them. One can use this feature, to separate (read better modularize) his/her code as well as execute it as and when required.

Read more about it here: http://infosys.beckhoff.com/content/1033/tc3_plc_intro/html/pou_method.htm

Answer 3

I have used methods as interface and also to divide the function block code to smaller parts.

For example, I have a logger block that writes given string to a log file. It can also read that log to a PLC array too.

The block looks like this:

FB_Logger

• AddLogLine
  • Public method to add log line
• SaveLogToFile
  • Public action(could be a method too) to save the log file
• LoadLogFromFile
  • Public action(could be a method too) to read the log file
• LogArray
  • Public getter for log array. A PROPERTY of type REFERENCE TO ARRAY..
• GetLogFileHeader
  • Private method to create header to the file
• GetLogFileLine
  • Private method to create a log line
• SaveFile
  • Private method to start saving
• ShiftLogItems
  • Private method to shift the log array

The function block itself has also some code that is called every cycle.

I use those OOP features in a very rich way. Sometimes I add methods to PROGRAMs to make them more clear. Before I had one function block and five helper functions, now I have one function block with private methods.

Just test it out!