Failure to Parse POINTER TO Object using FB_Init

[engineerjoe440]

Here's one that seems to have a bit of an odd syntax:

VAR
    pt_Results : POINTER TO DynamicVectors.class_BaseVector(SIZEOF(struct_EventDetails), 32);
END_VAR

It seems to me that it's almost a bit pointless to have the FB_Init in this particular context. Still, this was "valid logic" encountered in the wild.

[klauer]

Another good find, thanks @engineerjoe440.

Hmm, I'm not really sure where that call-like syntax fits in. Generally, these variable block declarations are handled with this rule: https://github.com/klauer/blark/blob/4cd1d061f96d1c72bf018af11b05f27789cae850/blark/iec.lark#L435

I'll show my ignorance here - do you know what the type definition of pt_Results looks like when compiled?

[engineerjoe440]

This definitely is a weird one!

From what I can tell, there's really not a difference between the following:

pt_Results : POINTER TO DynamicVectors.class_BaseVector(SIZEOF(struct_EventDetails), 32);
pt_Results : POINTER TO DynamicVectors.class_BaseVector;

I don't think the FB_Init stuff actually does anything. I could be wrong, there, but since this ends up just being a POINTER TO *something*, I don't know if it really matters. I think this is just a way to be "friendly" and perhaps a little overly verbose, because this seems like more of a description, than actual valid logic.

Does that help at all?

Sorry I haven't been more active, recently!

[klauer]

That helps - I think I understand better now. It does seem to be extraneous information; there's nothing to initialize for a pointer declaration as far as I know.

No worries at all about being inactive! Whatever level of feedback/help/comments/etc you can offer is greatly appreciated when you have the time.

[engineerjoe440]

It does leave me curious... since I've found this in a CODESYS environment, I wonder if the same syntax will "compile" in a TwinCAT environment (to be ignored in the same way), or if it's considered "illegal" syntax in TwinCAT.

[klauer]

I haven't had a chance to check - I'm curious as well. Tentatively am planning on addressing this in the grammar by the end of November, unless you get a chance of course!

[engineerjoe440]

Fingers crossed I'll have some time in the relatively near future, but I suspect it'll be in December. Hah! 🎄

[klauer]

Confirmed in TwinCAT - it just throws away the arguments and lets it compile. The number and type of arguments do not matter:

pt_Results : POINTER TO FB_ProjectB(1, 2, 3, 4, 5, 6);
pt_Results1 : POINTER TO FB_ProjectB(A:=5, B:=6);

FUNCTION_BLOCK FB_ProjectB
VAR_INPUT
    iValue : INT;
END_VAR
END_FUNCTION_BLOCK

Additionally - this typo actually compiled without issue (note no 2nd argument name):

pt_Results2 : POINTER TO FB_ProjectB(2, :=5, B:=6);

However, output parameters were seen as syntax errors (phew!):

pt_Results3 : POINTER TO FB_ProjectB(C=>fValue);
// ',' or ')' expected instead of '=>'

[engineerjoe440]

That's definitely interesting about the 2nd argument name missing. Sneaky, sneaky!