Object development - DataTagAccess as InternalElement

[FabianSIK]

Hi all,

I try to develop a new object which should utilize the DataTagAccess as an "InternalElement". Building the object was no problem, but while testing TwinCat always gives me an exeption when using the read and write commands of the DataTagAccess.

I followed the "Press with 2 cylinders" example from the training and double checked everything. The exeption is thrown in the Extension OnCall method of the DataTagAccess object. I guess that some internal methods are not called correctly. Also the OutHmi struct of the Extension is not filled.

I used the code from an already testet subtree which works just fine. Just converting it to an object gives me problems.

Has anyone tried to build an object using internal elements and maybe got the same problem?

Thanks for any help.

Regards
Fabian

[StefanKayser · Accepted solution]

The reasons, why you get an exeption is, because you referenced the wrong library in your  library.
You Referenced the Library AtmoDataTagAccess but you need the Library NexeedDataTagAccess.

The HMI is not filled, because you referenced your chain to _outCmd and you give OutCmd to the HMI. These are 2 different variables.

[FabianSIK]

Thank you, that worked. Also for finding the additional bug.

[nexidator]

Thanks a lot for your input, @StefanKayser !

Some more hints about what went wrong here: Usually it does not matter to which version placehoders are resolved while developping a library. (That's why we always use placeholder references.) It's the job of CpStudio to resolve all placeholders to the correct version.

In this case, the problem lies in the object description of the NexeedDataTagAccess object. Since the placeholder name differs from the file name in the new library version of NexeedDataTagAccess, the object description needs to explicitely "tell" CpStudio the placeholder name. This was missed when renaming the library. So what CpStudio currently does is creating a reference using the placeholder NexeedDataTagAccess and resolving it to the correct library. The placeholder AtmoDataTagAccess @FabianSIK  is correctly using in his library is not resolved at all, so it defaults to the version used during object development.

We will publish a corrected version of the NexeedDataTagAccess object with the next monthly release.