• Not Answered

Control Modules, Named sets, and graphics files transfer between DeltaV V14.5 and V15

We currently have two DeltaV systems: a standalone PK controller running DeltaV V14.5 and a full DeltaV system recently upgraded from V14 to V15. The full DeltaV system is not identical to the standalone PK system; it contains additional configurations and designs. The standalone PK system is a smaller subset of the full system, used for specific purposes.

After the recent upgrade to V15, we encountered an error when attempting to import locally modified codes, named sets, or graphic files from the standalone PK system back into the upgraded V15 system.

Is there an application or specific steps that can facilitate transferring individual files (such as CMs, named sets, or graphics) between these two systems? Specifically, we are looking for a way to transfer files from V14.5 to V15 and vice versa, without backing up or copying the entire project. Our goal is to ensure consistency for shared elements while maintaining the distinct configurations of both systems.

Your guidance on this would be greatly appreciated! Post

• DeltaV

Wei Sun

• 22 Jan 2025 6:33 PM
• Cancel

3 Replies

• Andre Dicaire

  

  • 23 Jan 2025 1:31 AM

  With out seeing the specific errors, it is hard to know if I can help. Migrating FHX files from lower to higher version requires the FHX to be migrated using the Migration utility found on the higher version system, under the Database Administration tools. The Migration utility updates the FHX as needed to address any changes, typically with new features on hardware and such, but sometimes affecting syntax in module structures. It also updates file header information that must match the import database. So the import would fail if the v14.5 FHX is not migrated to v15.
  
  There is no support for exporting from v15 down to v14. The same check is done to confirm the FHX version matches the import database and will reject the import when it sees the v15 header data.
  
  If you strip out the header information, the importer will attempt to import, but if the data structure of an object has changed, the item or items will fail to import. The resulting configuration might not be functional. The FHX import tool validates data and tries to protect the database from invalid formats. Small, focused imports like Named Sets and Alarm Types can typically be imported back, but there are no guaranties, and any negative results will have one resolution: Restore from backup.
  
  If the issue is simply that you did not migrate when importing to v15, you have a resolution. If you want to pursue reverse imports, I strongly suggest that you use a separate database/project in the v14.5 PK engineering station that you can import and FHX with the stripped out header. If the import works, you can them export a v14 FHX to bring this to your production system. Do not attempt to export the PK controller or other major components as v15 controller export is incompatible with v14 (Ethernet port configuration is different and there are new features v14 does not support).
  
  I have had no issues exporting DeltaV Live displays from v14 to v15. I have not tried the reverse. I think I would avoid v15 XML exports imported into v14. Develop new on PK Engineering and import to v15 to be fully supported. If you compare a v15 export and a v14 export of live objects, you can determine if there is any change. Again, I would recommend such imports be done on an interim sacrificial project to avoid any negative impact to the production database.
  
  Know that if you run into any issue exporting v15 to import into v14, you will be in unsupported territory. Proceed with caution. I suggest you work to get the PK Standalone to the same major version as soon as possible.

  Andre Dicaire

  • Cancel
• Wei Sun

  

  • 23 Jan 2025 6:36 PM

  In reply to Andre Dicaire:

  Hi, Andre,
  Thank you so much for clarifying the potential solution. Your professional reply in DeltaV Forum are the best knowledge source for me. Thanks again!
  Our V14.5 system is a standalone PK controller with one Engineering and one Operation Industrial PCs. Can we upgrade those to V15, too? If yes, then we probably would do it. Another thing is that we still use DeltaV Operator so there is no Live conversation issue, yet.

  • Cancel
• Andre Dicaire

  

  • 23 Jan 2025 8:34 PM

  In reply to Wei Sun:

  Thanks.
  
  Operate displays typically migrate back and forth, but If there are new features, which means new VBA functions and such, and you build in v15, those things would not work. The good news is that restoring a display file will fix (undo) the unsupported whatever. You just need to be careful moving backwards and keep it simple. The medical advice from Rodney Dangerfield's doctor, dr. Vinney Boomba, "if it hurts when you do that, don't do that" whatever "that" happens to be.
  
  Upgrading the stand alone to v15 would help with back and forth. However, my understanding is that Emerson has not released an online upgrade solution for PK Standalone. Even if you only have one project and it is the active one, I'm thinking the default DeltaV upgrade process is hampered by the Standalone Projects and how those directories are mapped into DVData folder. Anyway, if you can do an off line upgrade, getting to v15 would be recommended if you need to share FHX files between the systems.
  
  On PK Standalone, the controllers SD cards hold the project database, including the DeltaV database, displays, and other databases and directories under DVData. If you upgraded the Engineering Station to v15, it would be unable to load the project stored on the SD card as the database version would not match the installed version of deltav executables. That and the presence of multiple projects for multiple PK controllers is a new paradigm for the configuration. If you were to create a new V15 PK engineering station and create new projects for each of your controllers (in your case one controller?), and then exported/migrated and imported from the v14 database(s) into the v15 Databases offline, you could then connect to the PK but not upload the project. At this point, I think you would be able to update the PK controllers, and do a total download to get to v15. Finish with upgrading the HMI.
  
  The other difference in PK Standalone is that online changes are stored for upload on the SD card. You would want to upload all changes into the v14 database before starting. If additional changes are made during the Export/import/upgrade steps, you might still be able to upload into v15. But you would also be able to use PHV events to view any changes and update the database manually, as needed.
  
  Using an upgrade export the controller should come into the v15 database as commissioned and communicating. I think a total download is best at this point so that the SD card has a known good v15 download stored. You should then be able to store the project to the SD card. And once the HMI is updated, the engineering station should update any displays. I would make a test change to confirm everything is working, including a parameter change and check the upload works. I would check with the GSC to confirm if there are any newer recommendations or documentation that can help guide an upgrade to v15 on PK standalone. I think it can be made to work, but again, I have not done this.

  Andre Dicaire

  • Cancel