Why you should use OPCClient objects instead of legacy DINetwork objects

As newer versions of PLCs have been released, many of the deprecated DINetwork Objects have not received the necessary software enhancements to allow them to function correctly with the latest firmware versions. To simplify the migration from DINetwork Objects in existing galaxies, the OPCClient object, based on industry standards, has been enhanced to function as the single DIObject capable and sufficiently full-featured to replace the deprecated objects and maintain connectivity with current and future PLCs.

This enhancement to the OPCClient object is part of the ongoing evolution of System Platform away from legacy DAServers and OI Servers, and towards the use of communication drivers. Many users continue to use legacy DINetwork Objects because of the ease of use provided by the default syntax that these objects allow, and to avoid having to reconfigure their IO references.

This evolution of the OPCClient object is designed to simplify the migration of existing System Platform galaxies. In prior releases of System Platform, the OPCClient object required that you provide the entire PLC hierarchy for IO references, and thus converting from a DINetwork object to an OPCClient object required changing all existing IO references. In System Platform 2023 two additions were made to the OPCClient object:

• The new HierarchyPath attribute that was added to the OPCClient object allows an easy migration path from legacy DINetwork objects. HierarchyPath is only configurable in the IDE and cannot be changed at run time.

• A <Default> scan group was added to the Scan Group tab of the OPCClient to further simplify migration. This default group allows any scan group items that were in the DINetwork object's default scan group to be switched over seamlessly.

  Note: References to items in custom scan groups can also be easily migrated.