Emerson Exchange 365

• Not Answered

Migration from DV13.3 to DV11.3

Hi,

I have recently created a library consisting of CMs, EMs and Phases coded in DeltaV 13.3 and now have a requirement to use this on a DeltaV 11.3 system.

I wish to downgrade this library, however I understand that Emerson don't ordinarily support this.

I don't wish to do a complete re-write and understand that some testing may be required to confirm that code works as expected.

I have done this before by stripping the header and deleting/updating parameters not available in older DeltaV versions.
Has anyone else attempted this and what sort of issues have they encountered? I am particularly interested in version 13 to 11 downgrade issues.

 

Thanks

Amod

• migration
• 11.3.1
• downgrade
• 13.3.1

Amod Gokhale

• 8 May 2018 10:33 AM
• Cancel

3 Replies

• István Orbán

  

  • 14 May 2018 7:13 AM

  I am not sure exactly how to "trick" the fhx in this case, but keep in mind that some new function blocks were introduced in v13, and if your modules are using those, you'll have to pretty much rebuild them.

  • Cancel
• Andre Dicaire

  

  • 14 May 2018 3:36 PM

  Officially, this is unsupported. Meaning that if it does not work, Emerson will not issue any product change to make it work. There is a forward migration tool that will verify an FHX and modify it to address any known issues and make the FHX compatible for the newer release. There is no such tool for going backward.
  
  That said, and as you mentioned, by removing the version header, DeltaV will try its best to import the FHX, and as long as there is nothing "illegal" in the FHX, then it will import.
  
  So obviously, if your configuration contains function blocks or node types that do not exist in the destination version, the import will fail.
  
  Your best bet, and I strongly recommend this, is that you create a new database in the destination version, and import the FHX without the header into this location. Then, review the ImportExportProgress.Log file for any messages that would indicate an issue. Then, confirm that the new database contains everything you want and you can download and assign the modules and test them out. Then you can export what you want from this database and import into your target database of the same version.
  
  And make a database back up of the target database anyway, along with a complete export FHX just for peace of mind and the ability to recover from the unknown.
  
  So here's a tidbit about FHX files. The only export information that is different from the default information in the database. For example, a PID block has tuning variables defined in the library block. These values are typically changed in each module to match the process dynamics. If you don't modify the default value, the export will not have a GAIN parameter defined. No need as it is already in the database. When you tune or change that parameter and export, now the module will contain the "override" value.
  
  Why is this important? If a default value has changed, its possible that the export from the new database will not contain any explicit definition for the Parameter in the FHX, and when you import into the older version, the default value in that version will be assumed. Emerson tries not to make changes like this, and when it is required, they manage the forward migration by verifying and adding explicit override definitions for those parameters. When you strip out the version data and import in a past version, there is a slight risk you lose a value to a default value.
  
  Chances are your import will work, and between v13 and v11, I'm not aware of anything changing on the v11 blocks. But you'll have to own the results and confirm all is good.
  
  What you could do is once you've imported in the older version, and did not have any obvious issues, Export that database and use the migration tool to migrate back to v13. Now use a text editor to compare the two FHX files for any differences. If there are any changed default values and such, these should show up.
  
  Up to you on how much error checking you want to spend time on and what the consequence is if something changed....

  Andre Dicaire

  • Cancel
• Matt Forbis

  

  • 15 May 2018 11:53 AM

  In reply to Andre Dicaire:

  One item that I specifically remember has changed in the FHX file between 11 and 13 is how dynamic references are stored. If your module has dynamic reference parameters in it (aka, older version of PCSD for instance), you will not be able to import by just taking out the header of the v13 file.

  • Cancel