acfproject template includes an incorrect parameter value in the call to RegisterComponent

[martinboers]

There is a bug inthe acfproject template that causes a problem for ACF components that have GDS ports defined. When the PLC component (not the PLCnext Runtime) is stopped and restarted (e.g. from PLCnext Engineer), the ACF component ports disappear from the Global Data Space and are never restored. This causes the ports to disappear from the OPC UA server, and the GDS component throws errors if these ports are the Start or End port on any GDS connection.

Cause:

The acfproject template includes this call in the component Initialize method (in the .cpp source file):

    PlcDomainProxy::GetInstance().RegisterComponent(*this, false);

The following description is from a Phoenix Contact firmware developer:

The second parameter of RegisterComponent is named isSystemComponent. This parameter shall indicate whether the component was loaded by the ACF (isSystemComponent = true) or it was loaded by the PLM (isSystemComponent = false). The components loaded by the PLM (like normal components providing C++ programs) may provide different ports each time they are loaded. Therefore, the types and ports provided by these components are cleared when the PLC is reset (during unloading the project). On the other hand, the components loaded by the ACF have fixed ports their whole lifetime and are independent of the project.

In the PlcDomain and MetaDomain the components are sorted in different lists based on isSystemComponent. Due to isSystemComponent = false the types and ports of the component are cleared on PLC reset and not initialized again when the PLC is loaded. When the GDS tries to connect the ports it cannot find the given port and throws an exception.

To fix this set isSystemComponent = true in your component.

[twilker]

Will be fixed with the next version

[martinboers]

Fixed in version 2021.6.1