Aaron,
A little confused why you need to import twice. If you manually create the
equipment units in the 6.0 galaxy before importing the cps should import into
their respective equipment units. If you export at the cp level you should get
all the fbms/ecbs in the export file and therefore when you import they should
get created and the IO connections should be restored.
If you export all cps at the same time the template versions in the export
files will be the same for each exported cp. As each cp is imported templates
unique to the cp will be created. Subsequent cps that are imported will contain
templates that already exist in the galaxy but they should import all instances
since the templates in those cp exports are the same version as the templates
that came in with preceding cp imports.
Do you use galaxy security? You cannot export galaxy security. The only way to
retain galaxy security is to migrate the galaxy from 3.0 to 6.0.
You mention using sync deploy status and upload in the 6.0 galaxy. Sounds like
you do not intend to deploy the cps from the 6.0 galaxy? Will the CSA database
exist and be up to date on the 6.0 system? Instead of using sync deploy status
you could use SyncDb. This will mark all compounds/blocks found in the cp as
deployed in the galaxy and rebuild the CSA database. SyncDB will take much
longer to run than Sync Deploy status.
David Johnson
Principal Application Engineer
Process Automation
Industry Business
Foxboro by Schneider Electric
D 15085493801
F 15085496788
E david.johnson@xxxxxxxxxxxxxxxxxxxxxx
70 Mechanic St.
Foxboro, MA 02035
United States
*Please consider the environment before printing this e-mail
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Aaron Boshammer
Sent: Tuesday, January 31, 2017 5:19 PM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] Galaxy Migration FCS3.0 to CS6.0
We are moving from an IA 8.6 host to an IA 8.8 host (to allow us to move to a
virtualised V90 platform). Our galaxy will therefore have to be upgraded from
FCS3.0 to version 4.0 or above. We have recently performed a galaxy migration
from FCS4.0 to Control Software 6.0 for our OTS system, and following the
upgrade path 3.0 -> 4.0 -> 5.0 -> 6.0, we found that during the 4.0 -> 5.0
database upgrade there were errors each time we tried.
To get around these errors in the live plant system, we are thinking of
bypassing the upgrade path by performing the following:
On FCS3.0 galaxy:
Step 1: Remove all undeployed blocks,
Step 2: upload runtime changes,
Step 3: checkpoint,
Step 4: Export Objects (on a per CP basis).
On newly installed Control Software 6.0 galaxy:
Step 5: Import objects,
Step 6: assign to correct Equipment Unit,
Step 7: Import objects again (originally it imports to unassigned and therefore
the IOM_ID references are all lost, the second import fills all that back in),
Step 8: use synchronise deploy status to mark everything as ‘deployed’.
Step 9: Upload runtime changes again
Has anyone got any experience with the above process and can think of a reason
why it would not be a good idea to perform. Our alternative option is to just
install FCS4.0 as the new galaxy by performing an upgrade to the
FCS3.0 galaxy. (We prefer the 6.0 option so that we can get the live plant to
the same version of the OTS).
Thanks for any insight you can provide,
Aaron Boshammer
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________
*** Confidentiality Notice: This e-mail, including any associated or attached
files, is intended solely for the individual or entity to which it is
addressed. This e-mail is confidential and may well also be legally privileged.
If you have received it in error, you are on notice of its status. Please
notify the sender immediately by reply e-mail and then delete this message from
your system. Please do not copy it or use it for any purposes, or disclose its
contents to any other person.
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
