1

An important part of OOP is to use access specifiers to make member methods and variables inaccessible from outside of the object.
When declaring a function block method is is easy to control the Access Specifier, but I have not found a way to control access to member variables.

Is it possible and if yes, how?

1

Mikkel
  • 138
  • 7

3 Answers3

1

Every variable that you declare under the VAR section of your Function Block is considered private.

There is no public or private keyword for variables in IEC 61131-3

Another thing you can do if you absolutely want to use public/private keywords is to define properties.

In general, the normal convention is to have read-only variables in the VAR_OUTPUT section of the Function Block and writable variables in the VAR_INPUT section of the Function Block. Again, the VAR section is considered a private section even though you could read this variables with the fbName.var notation or write them through their address (but this is a very bad programming style).

Twincat2 also allowed the variables in the VAR section to be written to with the fbName.var notation but this changed in Twincat3 in order to achieve better incapsulation.

To learn more about programming conventions in the IEC 61131-3 world, I recommend you to read the programming guidelines of the PLCOpen organization:

https://plcopen.org/guidelines/guidelines

Filippo Boido
  • 1,136
  • 7
  • 11
  • Okay. I was actually of the impression that the variables in the VAR section behaved like "Public" variables. – Mikkel Oct 04 '21 at 12:44
  • in Twincat 2 yes, not in Twincat 3 – Filippo Boido Oct 04 '21 at 12:49
  • Yep they are private. However, it's always good to remember that they still can be accessed outside in TwinCAT 3 using for example `ADR()`. So example the following still works: `ptr := ADR(fbBlock.privateVariable); ptr^ := 123;`. However, nobody does that by accident (and thank god it's possible, it has helped few times). – Quirzo Oct 04 '21 at 14:50
  • or you can just use a property as you would do in other OO languages.. – Filippo Boido Oct 04 '21 at 15:04
  • Was that comment for me? I didn't mean that it should be used like that. Just that it's possible to edit values inside FB even though they aren't visible outside. – Quirzo Oct 04 '21 at 15:32
1

You can actually still access internal variables of an object direcly in code (no pointers), but they are read only. The code completion will not display the internal variables though, but after you finish typing the name structure, you will see no compile errorrs - test := fb1.internalVariable will be a valid read action actually while fb1.internalVariable := 5; will end up giving you an error, saying that the variable is not an input to the function block (or any other object for that matter).

ziga
  • 159
  • 1
  • 6
  • Okay. So they are kind of private, but the restricted write access makes it safe to use. – Mikkel Oct 05 '21 at 12:59
  • Yes, you can read the variable even though you are not supposed to as already stated by @Quirzo in the comment to my answer. It's bad programming style and you should use properties or VAR_OUTPUT if you want a VAR to be read only. – Filippo Boido Oct 08 '21 at 09:06
1

You can also use the hide oder hide_all_locals pragma to suppress local variables being found in auto-complete and crossreference-list (see https://infosys.beckhoff.com/content/1033/tc3_plc_intro/2529654667.html?id=5927203996458905204 )

Gauss3k
  • 141
  • 3