FORUM CTRLX AUTOMATION
ctrlX World Partner Apps for ctrlX AUTOMATION
Dear Community User! We have started the migration process.
This community is now in READ ONLY mode.
Read more: Important
information on the platform change.
03-01-2024 07:41 PM
Hello,
A customer noticed these warnings in his ctrlX PLC 2.04 project associated with DL_ReadNode and IL_ECatSoeRead function blocks:
After some testing in my own project, the issue seems to be related to having these function blocks within a user-defined FB. If I call DL_ReadNode from a PRG I get no warning. The same DL_ReadNode called within an FB yields this warning, but seems to function properly.
DL_ReadNode called from user-defined FB:
DL_ReadNode called from PRG:
Best regards,
Brian
Solved! Go to Solution.
03-05-2024 11:28 AM
You can suppress this warning by adding pragma {attribute 'no_assign'} to the wrapper block:
The 'no_assign' pragma is described in the CODESYS documentation here.
03-06-2024 08:43 PM
Thank you!
06-11-2024 10:31 AM
I'm having the same issue with IL_ECatCoeWrite. In my case this library function block isn't working correctly in runtime if the 'no_assign' pragma isn't implemented.
Does anyone know what this pragma does?
Why are these library functions causing this issue?.
It has to do with using pointers, but what goes wrong without this pragma?
The text in the Codesys documentation doesn't give me a clear inside in this.
06-11-2024 11:53 AM
General information can be found, like mentioned in the CODESYS online help.
06-11-2024 02:58 PM
You have to see the whole thing from a different perspective. The no_assign attribute gives the developer of an FB the option of preventing the FB from being used in an unauthorized way.
This enables him to prevent erroneous program reactions whose cause would not be apparent to the user of the FB.
As an example, the CoDeSys documentation mentions the use of pointers. As each instance of an FB has its own copy of the local variables. However, if pointers are used, they can refer to the same memory location. As a result, all instances would read or write the same variable, which is not intended by the developer of the FB. This is why he uses the attribute no_assign.