cancel
Showing results for 
Search instead for 
Did you mean: 
SOLVED

"Attribute 'no_assign' missing" warning with DL_ReadNode and IL_ECatSoeRead

"Attribute 'no_assign' missing" warning with DL_ReadNode and IL_ECatSoeRead

bschmidt
New Contributor

Hello,

A customer noticed these warnings in his ctrlX PLC 2.04 project associated with DL_ReadNode and IL_ECatSoeRead function blocks: 

bschmidt_0-1709317177769.png

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:

bschmidt_2-1709318237693.png

DL_ReadNode called from PRG:

bschmidt_3-1709318284370.png

Best regards,

Brian

 

5 REPLIES 5

bostroemc
Occasional Contributor

You can suppress this warning by adding pragma {attribute 'no_assign'} to the wrapper block:

2024-03-05_04h21_43.png

The 'no_assign' pragma is described in the CODESYS documentation here.

Thank you!

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.

CodeShepherd
Community Moderator
Community Moderator

General information can be found, like mentioned in the CODESYS online help.

HmiGuide
Community Moderator
Community Moderator

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.

Icon--AD-black-48x48Icon--address-consumer-data-black-48x48Icon--appointment-black-48x48Icon--back-left-black-48x48Icon--calendar-black-48x48Icon--center-alignedIcon--Checkbox-checkIcon--clock-black-48x48Icon--close-black-48x48Icon--compare-black-48x48Icon--confirmation-black-48x48Icon--dealer-details-black-48x48Icon--delete-black-48x48Icon--delivery-black-48x48Icon--down-black-48x48Icon--download-black-48x48Ic-OverlayAlertIcon--externallink-black-48x48Icon-Filledforward-right_adjustedIcon--grid-view-black-48x48IC_gd_Check-Circle170821_Icons_Community170823_Bosch_Icons170823_Bosch_Icons170821_Icons_CommunityIC-logout170821_Icons_Community170825_Bosch_Icons170821_Icons_CommunityIC-shopping-cart2170821_Icons_CommunityIC-upIC_UserIcon--imageIcon--info-i-black-48x48Icon--left-alignedIcon--Less-minimize-black-48x48Icon-FilledIcon--List-Check-grennIcon--List-Check-blackIcon--List-Cross-blackIcon--list-view-mobile-black-48x48Icon--list-view-black-48x48Icon--More-Maximize-black-48x48Icon--my-product-black-48x48Icon--newsletter-black-48x48Icon--payment-black-48x48Icon--print-black-48x48Icon--promotion-black-48x48Icon--registration-black-48x48Icon--Reset-black-48x48Icon--right-alignedshare-circle1Icon--share-black-48x48Icon--shopping-bag-black-48x48Icon-shopping-cartIcon--start-play-black-48x48Icon--store-locator-black-48x48Ic-OverlayAlertIcon--summary-black-48x48tumblrIcon-FilledvineIc-OverlayAlertwhishlist