Attribute ‘no_virtual_actions’ΒΆ

This pragma is used for function blocks that are derived from a function block implemented in SFC and use the fundamental SFC sequence of this base class. The actions called from it exhibit the same virtual behavior as methods. This means that the implementations of the actions in the base class can be replaced by the derived class with its own specific implementations.

If you apply the pragma to the base class, then its actions are protected against overloading.

Syntax:

{attribute 'no_virtual_actions'}

Insertion position: top line in the declaration part of the function block

Example

The function block POU_SFC is the base class for the derived function block POU_child.

The derived class POU_child calls the sequence of the base class written in SFC with the special variable SUPER.

The exemplary implementation of this sequence is limited to the initial step, followed by a single step with a linked step action ActiveAction. This step with a linked step action takes care of the configuration of the output variables.

an_int:=an_int+1;    // Counting the action calls
test_act:='father_action';
METH();              // Call of the method METH in order to set the string variable test_meth

In the case of the derived class POU_child the step action is replaced by a special implementation of ActiveAction. Active Action differs from the original only by the assignment of the string 'child_action' in place of 'father_action' at the variable test_act.

Likewise, the method METH, which assigns the string 'father_method' in the base class of the variable test_meth, is overwritten so that test_meth is now given the value 'child_method'. The main program PLC_PRG calls an instance of the function block POU_child named ‘Child’. As expected the value of the string reflects the call of action and method of the derived class:

Now, however, you place the pragma {attribute 'no_virtual_actions'} in front of the base class:

{attribute 'no_virtual_actions'}
FUNCTION_BLOCK POU_SFC...

As a result the behavior changes: while the implementation of the derived class is still used for method METH, the call of the step action now results in a call of the action ActiveAction of the base class. Therefore test_act is now given the value 'father_action':