CODEWITHSUNDEEP
plctwincatstructured-text
ziga
ziga

Reputation: 389

Are there any cons to using VAR_INST

Ever since I started working with TcUnit I have been, in many cases, working with a lot of VAR_INST declarations for a whole bunch of tests. This is due to the nature of how PLC world works, where you need to keep calling the body to do something, the tests are running in "parallel", which could mean tests that share the same function block must be sure what state it is in - if another test would be changing any property it would fail every other test.

My question is, are there any cons to using instanced variables inside methods? This is not a real world example I usually do, I very rarely find the need to use them on machine code, but in case I do, I was wondering if I should take notice when I do use it.

Upvotes: 3

Views: 220

Answers (3)

Kudapucat
Kudapucat

Reputation: 128

I use them all the time. It's just a function block variable that is hidden from other methods and the FB. You can see this when you link to ADS variables in scope and such.

Upvotes: 0

Jakob
Jakob

Reputation: 1540

No disadvantage to use VAR_INST. It will become an instance variable, but only accessible from the method of where it is declared.

I rarely use VAR_INST, except in the cases of defining test-cases using TcUnit, which is a perfect example of where VAR_INST makes a lot of sense. This makes it possible to instantiate the subject-under-test (SUT) in your test-method and thus it won't have any dependency to any other tests (tests should not depend on other tests). The only disadvantage of using VAR_INST compared to declaring your SUT's as normal instance variables (VAR) is that it's not possible to inject dependencies to FBs that are declared as such. There is an excellent FAQ in the TcUnit website that discusses this and what you can do about it.

Upvotes: 2

Fred
Fred

Reputation: 7015

I have never used VAR_INST, and a cursory look at the documentation indicates this is basically the same as declaring a variable in a VAR block in the function block body (which I use profusely). I am not entirely certain what benefit there is to a VAR_INST in a method compared to VAR in the function block, but having variables at the instance level in OO languages is something pretty much universal. It is OK to do that. It could probably be argued that the ability for methods to access instance variables is what qualifies a language as object oriented (or else methods would be functions).

As with most language constructs, I would assume whether VAR_INST is right for you depends on your use cases, modelling style and proficiency with the language.

I will note that, for debugging, I have used VAR_STAT in the past in methods to declare variables I intended to remove after debugging, knowing there was only one instance of a given function block in the system (avoiding the singleton aspect becoming an issue). Knowing about VAR_INST, I would use that instead in such cases.

Upvotes: 2

Related Questions