Starting with System Platform 2020 AVEVA/Wonderware discontinued supporting DI objects in favor of the OI server technology. Unfortunately this requires a migration effort of existing CXS BACnet applications to remove the DI device objects. While OI servers provide some new features on the communication side there are drawbacks on the engineering side:

• The server configuration is no longer edited in the IDE (has moved to the SMC)
• The server configuration is no longer stored in the Galaxy
• Deployment to a remote node requires an additional manual installation step

This article describes the steps necessary to migrate an existing DI object based CXS BACnet application to versions 2020, 2020R2, 2023 and higher:

In a nutshell these tasks need to be executed:

1. Replace the DI port and DI device objects with standard clients (DDE/SL or OPC)
   For remote server access it is always preferable to use the DDE/SL in order to avoid DCOM issues
2. Install the CXS BACnet Server(s) on the target nodes using the stand alone setup
3. Configure the CXS BACnet Server(s) using the SMC

Replacing the DI communication objects

There are two different strategies replacing the DI port and DI device objects:

• Client device objects
  Replacing each DI device object with a DDE/SL (or OPC) client using exactly the same name and topic.
  This also is true for redundant setups using the redundant DI object for each pair of device clients.
  Advantages:
  
  • Granular deployment on a device basis
    
  • Redundancy on the device level
    
  • Application object IO references don’t change
  • Minimal application modification

• Client port objects
  Replacing each DI port object with a DDE/SL (or OPC) client.
  This requires to populate the topic list with all previous DI device names .
  Advantages:
  
  • Single client for multiple devices
    
  • Redundancy on the server level
    

The decision which strategy to use is mainly driven by the desired structure and required granular maintenance. However, there are also procedural considerations:

• Client device objects can easily be created manually and the impact on the application is minimal since no IO references change
• The creation of client port objects can be fully automated by the CXS BACnet Application Generator adjusting the application object IO references automatically

Migration steps in detail

• Client DDE/SL device objects (manual migration)
  • Save the configuration file of the CXS DASBACnet Server with fully deployed DI objects
    The configuration file is found under:
    C:\ProgrammData\ConneXSoft\DAServer\DASBACnet\DASBACnet.AAcfg
  • Undeploy all DI objects
  • For each DI device object create a DDE/SL client with the same name and topic, removing the DI object.
  • Configure the topic to point to the associated device group
  • Install the CXS DASBACnet Server on the node where the DI port object was originally deployed to and copy the save configuration file back into the configuration location
• Client DDE/SL port object(s)
  • This migration can be executed automatically using the CXS BACnet Application Generator
    
  • The CXS BACnet Application Generator provides an OI mode setting in the ArchestrA options allowing a re-generation of the application with the correctly loaded namespace
    • Automatic creation of DDE/SL clients
    • Automatic configuration of the DDE/SL clients
    • Automatic adjustment of all associated application object IO references
    • Automatic generation of the stand alone CXS DASBACnet Server configuration file

Note: The upcoming version of the CXS BACnet Application Generator will also support the automatic migration to a client DDE/SL device objects application (first option)