VAR_INST and FB_Init

[ColonelPanic-Dev]

Hey there,
The main way I've been writing my tests is to keep all the data for each test in a VAR_INST block in the test method, something like this

METHOD Test01 : BOOL
VAR_INST
    fbFoo : FB_FOO;
    aBar : ARRAY [..] OF FB_BAR;
END_VAR

This keeps the scope for all the variables clean and small. Works great! Until I try to pass one variable into another during instantiation, like so

METHOD Test02 : BOOL
VAR_INST
    fbFoo : FB_FOO;
    aBar : ARRAY [..] OF FB_BAR(fbFoo); // FB_BAR now has an FB_Init that takes FB_FOO
END_VAR

While this form works fine in the main body of a function block, as well as VAR_INPUT, VAR_OUTPUT, VAR and VAR_STAT in a method, it doesn't work with VAR_INST. The compiler complains that "Identifier 'fbFoo' not defined".

I have two theories. Either the instantiation order of VAR_INST is strange, or the renaming the variables get by the compiler isn't respected by the compiler in this particular layout. But I don't know if there is anything I can do about it. One thing I have found does work is putting fbFoo and aBar into a struct, then they recognize each other just fine. However, this would require a new struct for every test since the length of aBar is different for most tests. Not ideal and very cluttered

tl;dr
Does anyone know a syntax, pragma, or work around that will allow you to pass a variable in a VAR_INST block into the FB_init of another variable in the same block? Ideally without touching the implementation area.

[sagatowski]

Same problem here, not sure why the compiler has this behaviour.
I only use VAR_INST if I need to run multi-cycle tests though, and in that case I simply move everything that goes into the constructor into the instance variables area of the test-suite, and give them an unique name (for every test). If you run single-cycle tests, you can simply use VAR and then you don't have this problem.
One thing that would be worth to investigate if this is the same behaviour in the compiler for 4026?

[ColonelPanic-Dev]

Pretty much all of my tests are multi-cycle, ya. My hope is to keep the definitions of the objects in VAR_INST, so that its easy to read. My declaration area currently looks something like this most of the time

VAR_INST
    env : TestA_Environment; //Struct containing the fb, a timer, current step number etc
    steps : ARRAY [0..4] of TestA_Step := [
        (
            StepName := '1 - Rising edge',
            IN := TRUE, Out := 10
        ), ...
];
END_VAR

So each step of the test has inputs and expected outputs and a name, stuff like that. Makes defining tests very straightforward and easy to write/alter/read. Once all these things end up in the main block its clunkier. Obviously all of my complaints are style-related more than anything.

I'll try this in 4026 and see what happens

[ColonelPanic-Dev]

Well, it doesn't work in 4026 either, but has a dedicated compiler error now
C0536: The initial value for a VAR_INST variable may not use local variables
Shame! Seems a bit arbitrary but I'm sure there are some underlying reasons why this can't be done. Thankfully since I only have one test suite per function block I can use VAR_STAT and get the effect I want, but I guess I'll have to figure something else out for other use cases

[ColonelPanic-Dev]

So in summary, unless someone pops up with a secret angle, you cannot instantiate variables in VAR_INST using local variables in the same header. This works everywhere else, but not in a method's VAR_INST.

Work arounds that I know of (that largely don't meet my needs wants in 4024):

1. Put the object you want to pass to the others in the main function block, as Jakob suggests, or a gvl or something
   • This violates keeping the scope as small as possible, so not great for production code but fine for unit tests if you're careful
2. Put all the objects in a struct, then put the Struct in VAR_INST
   • This doesn't work nicely if one of the things is an array, since you'll need a different struct for each array size. Also, nobody likes structs like this polluting the namespace
   • With 4026, a psuedo struct made with a function block and VAR_GENERIC solves the variable array issue, and setting that FB to be internal at least makes the namespace look clean. Would have been nice if Structs and Interfaces had VAR_GENERIC support though. Oh well
3. use {attribute 'noinit'} pragma and instantiate those function blocks in the implementation area by calling FB_Init manually
   • clunky and ugly, since you'll have a bunch of extra stuff in the implementation area to handle the initialization, and can't declare any of the members inline on the not-initialized objects. But, it keeps the scope local

[sagatowski]

Thanks @ColonelPanic-Dev for the great summary!
Would it be possible for you to create a PR and put this in the FAQ (minus maybe the wants/my wishes etc 😅)
I think this information would be valuable for others.

Thanks!

[ColonelPanic-Dev]

Done