Re: [foxboro] Spare AW

I don't know if the formatting will come out as something readable or not,
but here's what I sent Rob.
 

Regards,

 

Alex Johnson

Invensys Systems, Inc.

10707 Haddington

Houston, TX 77063

+1 713 722 2859 (voice)

+1 713 932 0222 (fax)

+1 713 722 2700 (switchboard)

alex.johnson@xxxxxxxxxxxxxxxx

 

It must be the time of year, the topic of how to properly back up a CP and
how to recover from the loss of the hard drive on the hosting AW has come up
several times and I'm getting tired of doing this one at a time. So, here
are my thoughts for all to ponder.

 

This is really a case where free advice is worth what you pay for it.
Remember, this does not replace the standard company policy of:

 

1)       SAVE ALL

2)       Failure

3)       INITIALIZE

4)       Reboot

5)       LOAD ALL

 

However, even the company standard procedure does not address everything,
e.g., #include files. So, be sure you keep those up to date somewhere off
platform.

 

So, with all of the expected caveats about free advice and standard
documented procedures, read on.

 

 

I have the general outline of a procedure, but it is NOT for the faint of
heart. There are at least a few difficulties and probably more. The ones
that I can think of are:

 

1)       Recovery of Sequence Code Source and Ladder Logic source is not
going to happen, you must have up to date backups of this code. Basically,
my advice is, "Make a SAVE ALL every time you recompile a Sequence Block or
a PLB block." Also, if you use #includes you need to back those up, they
won't be on the SAVE ALL.

2)       Block Order recovery can be awkward. You can use the order shown by
the CP in the FoxSelect or Select window as the master and make the workfile
match it - see below for what I'm talking about.

3)       dbvu does not like dumping out the parameters of CPs that have
certain ECBs in them. I'm talking about the -t option (at least the last
time I tried it on a CP60). This can make life tougher.

 

General words of advice:

1)       Get help from Field Service! I can't stress this enough. There are
guys who have had the (mis)fortune of doing this more than once. You
probably have not.

2)       Understand what the relationship is between CSA, work files,
checkpoint files, CP RAM, and the Sequence Block and Ladder Logic source
code.

3)       In the future, be dead certain to make SAVE ALLs after all changes
to Sequence (IND, EXC, DEP) or PLB blocks. This preserves your source code.
Regular Save Alls will minimize the work, but will not eliminate the need
for this procedure.

4)       If you use #include statements in your sequence code, you'd better
back those files up! SAVE ALLs don't preserve them.

5)       Save Alls can be automated using scripts that can be found on the
Cassandra Web Site. While that will not totally remove the need for SAVE
ALLs after alterations of Sequence and Ladder Logic code, it will help.

 

Here is the general gist of the procedure.

 

1)       Setup a duplicate system off line. It should contain at least an
AW/AP with the latest backup tape for the CP host and a CP of the same type
with the same letterbug.

2)       Boot the off-line system

3)       Determine which compounds/blocks have been added / deleted between
the two CPs. You can use a variety of tools to get this information. 

a.       Workfile contents

                                                               i.      The
print options of the ICC and ICC Driver Task can document the workfile

                                                             ii.      The
refs toolkit - on the Cassandra site - can document workfiles

b.       CSA

                                                               i.      The
CSA tools (see the attached file csa_util.doc) can be used to see what CSA
thinks is there.

c.       CP's Running Database

                                                               i.
/opt/fox/bin/tools/dbvu - can be used to examine a checkpoint file and pick
out compound and block names.

                                                             ii.
FoxSelect can be used to determine what the CP actually has in it (same info
as dbvu)

d.       Block Order - Use Select or FoxSelect to see the order of the
blocks as known to the CP.

e.       Source Code Files - are a problem because they are on the host and
not in the CP. There is no way to to ensure that you actually have the
latest source code for the Sequence Blocks and PLB blocks.

4)       Use the off-line system to build a correct CP image. That is, one

a.       That has the correct set of compounds and blocks. This is a pain.

b.       That has the right block order

c.       That has up to date Sequence and Ladder Logic blocks

                                                               i.      The
correct Sequence Code and Ladder Logic files 

                                                             ii.      The
correct #include files.

                                                            iii.
Recompiled source

5)       Once you have an up to date CP configuration in the off-line
machine, you need to move it to the main machine.

a.       Make a backup of the critical files

                                                               i.      cd
/opt/fox/ciocfg

                                                             ii.      tar
cvf <cpLbug>.tar <cpLbug> <cmpdName> <cmpdName>

where <cpLbug> is something like CP0001

<cmpdName> is the name of a compound in the CP that contains Sequence or PLB
blocks. 

b.       Move the tar file (<cpLbug.tar>) to the on-line host and put it in
/opt/fox/ciocfg

c.       Extract the files (tar xvf <cpLbug>.tar)

d.       Start the ICC and perform an upload from the CP

6)       Use the CSA utilities to fix the CSA database if necessary.

 

Other techniques are possible given different starting points. Some of you
may have everything back documented with FoxCAE for example, but they all
boil down to this.

 



 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: