Tc2_Utilities pinned version to 3.3.38.0

[ZigaJavornik]

Hello,

I was wondering, is there a reason for having utilities pinned to 3.3.38.0? Not sure how old it is, but I am far away from that version, thought I think that they made a big leap from 3.3 to 3.8, Beckhoff things ... If all the tests pass, could it be updated perhaps?

BR

[fisothemes]

Interesting, I didn't even know I pinned that.

Thanks for raising the issue, I'll fix it on the next update

[ZigaJavornik]

Not related to this issue, but since I have you here :)

Would you mind if I make a PR and make all your properties more user friendly? It is really neat to have them have the {attribute 'monitoring':='call'} as well as having them be declared as <PropertyName> : REFERENCE TO <PropertyType> .

This way you get 2 big benefits

1. you can monitor the properties in online view
2. You can access the structured properties directly, instead right now, you need to copy the value to a local structure, then access the values there.
   

When you declare the gettter of the property like Property REF= _property then you have direct access:

{attribute 'monitoring':='call'}
PROPERTY GenericError : REFERENCE TO ST_GenericError

GenericError REF= _genericError;

Again, not this issue, but let me know and I will look at it this/next week and make the PR if you would agree to it. I really like this library, I was going down the deep end with some "malloc" implementation but then I found this gem.

[fisothemes]

Thanks for your kind words! 👍

I glad you enjoy this library.

This is a great suggestion for a PR. I’ve thought about these improvements in the past, and to be honest, there are several aspects of this library that I’m not entirely happy with. That’s why I’ve been planning a Version 2 to address these and other issues, as detailed in the v2 branch proposal. It’s still in early development, and I haven’t found the time to work on it properly yet.

Here are my thoughts on the suggestions you’ve raised:

Monitoring Attributes

I’ve been cautious about using monitoring attributes in libraries due to their potential side effects:

• {attribute 'monitoring':='call'}: While this works fine here, as the getter only performs assignment, it could cause issues if future refactoring adds logic to the getter. This would put me in the difficult position of removing a feature people might rely on to improve the library. Additionally, since the monitoring service invokes this periodically, it could lead to unintended behaviour.
• {attribute 'monitoring':='variable'}: This adds implicit variables, which could unnecessarily increase the memory footprint of the function block.

Given these considerations, I’d prefer to leave properties as they are for now.

Component Access

In Version 2, I’m transitioning the Error type from a STRUCT (ST_ERROR) to a FUNCTION BLOCK (FB_Error) that implements an error interface (I_Error). This approach preserves immutability while allowing component access.

Changing _Error_Status : T_Error to _Error_Status : REFERENCE TO T_Error would expose the local variable Error : T_Error to external mutations. However, since T_Error is an alias, I could potentially replace ST_ERROR with FB_Error and have _Error_Status return an interface pointing to FB_Error. My main concern is backward compatibility. This change could break existing code where the assignment operator is used.

If you absolutely need component access, there is a workaround I hesitate to recommend.

In TwinCAT and Codesys, local variables aren’t truly hidden and can be accessed externally without compiler complaints. For example:

FUNCTION_BLOCK FB_List EXTENDS FB_Collection IMPLEMENTS I_List
VAR
    Error : T_Error;
END_VAR

PROGRAM MAIN
VAR
    fbList : FB_List;
    sErrorMessage : STRING;
END_VAR

sErrorMessage := fbList.Error.sSOURCE;

While not ideal, this is an option if necessary.

Next Steps

For now, I’d recommend either leaving the properties as they are or forking the library to make the changes you need. On my end, I’ll make some minor updates and accelerate development on Version 2 to address these concerns and more.

Feel free to open issues or share suggestions for Version 2.

[ZigaJavornik]

Thanks for your kind words! 👍

I glad you enjoy this library.

This is a great suggestion for a PR. I’ve thought about these improvements in the past, and to be honest, there are several aspects of this library that I’m not entirely happy with. That’s why I’ve been planning a Version 2 to address these and other issues, as detailed in the v2 branch proposal. It’s still in early development, and I haven’t found the time to work on it properly yet.

Here are my thoughts on the suggestions you’ve raised:

Monitoring Attributes

I’ve been cautious about using monitoring attributes in libraries due to their potential side effects:

• {attribute 'monitoring':='call'}: While this works fine here, as the getter only performs assignment, it could cause issues if future refactoring adds logic to the getter. This would put me in the difficult position of removing a feature people might rely on to improve the library. Additionally, since the monitoring service invokes this periodically, it could lead to unintended behaviour.
• {attribute 'monitoring':='variable'}: This adds implicit variables, which could unnecessarily increase the memory footprint of the function block.

Given these considerations, I’d prefer to leave properties as they are for now.

Component Access

In Version 2, I’m transitioning the Error type from a STRUCT (ST_ERROR) to a FUNCTION BLOCK (FB_Error) that implements an error interface (I_Error). This approach preserves immutability while allowing component access.

Changing _Error_Status : T_Error to _Error_Status : REFERENCE TO T_Error would expose the local variable Error : T_Error to external mutations. However, since T_Error is an alias, I could potentially replace ST_ERROR with FB_Error and have _Error_Status return an interface pointing to FB_Error. My main concern is backward compatibility. This change could break existing code where the assignment operator is used.

If you absolutely need component access, there is a workaround I hesitate to recommend.

In TwinCAT and Codesys, local variables aren’t truly hidden and can be accessed externally without compiler complaints. For example:

FUNCTION_BLOCK FB_List EXTENDS FB_Collection IMPLEMENTS I_List
VAR
    Error : T_Error;
END_VAR

PROGRAM MAIN
VAR
    fbList : FB_List;
    sErrorMessage : STRING;
END_VAR

sErrorMessage := fbList.Error.sSOURCE;

While not ideal, this is an option if necessary.

Next Steps

For now, I’d recommend either leaving the properties as they are or forking the library to make the changes you need. On my end, I’ll make some minor updates and accelerate development on Version 2 to address these concerns and more.

Feel free to open issues or share suggestions for Version 2.

I see that you have way more IT world experience over me :)
I give very little thought to immutability of objects, but for the most part this is due to the reason the libraries I create I use, so I just say "I know not to write this property" - not ideal, yes. As far as monitoring goes, I think it is essential to good debugging experience, which is already kind of bad when it comes to OOP style programming in TwinCAT (still okay though). These changes are something I usually implement, but your implementation works just as fine, so I will stick with what is provided :)

Who knows, perhaps PLC++ will give us all these things we want, my only worry is when is it coming out (from my experience 4026 was already "released" but I know for a fact that they are still testing it and has many many bugs ...).