Re: [foxboro] Control Blocks missing in ICC Configuration
- From: "Schouten, Frits JF" <Frits.Schouten@xxxxxxxxxxxx>
- To: "'foxboro@xxxxxxxxxxxxx'" <foxboro@xxxxxxxxxxxxx>
- Date: Fri, 11 Apr 2003 07:37:18 +1000
Why is Foxboro not giving these tools out as a matter of course?
Is there some protectionism going on here or what.
There are plenty of sites with Foxboro equipment that employ engineers with
more that half a brain, you know!!
Cheers,
Frits.
-----Original Message-----
From: Stear, Bo [mailto:stear@xxxxxxx]
Sent: Friday, 11 April 2003 06:23
To: 'foxboro@xxxxxxxxxxxxx'
Subject: Re: [foxboro] Control Blocks missing in ICC Configuration
If you are fortunate enough to have the tools
(/opt/fox/bin/tools/check_sync), you can check the synchronization of the
CP, workfile and CSA using 'check_db_sync' <CPLBUG>. If you don't have
them, you should get them and use them regularly to catch problems before
they become too severe.
If you are then fortunate enough to find that only CSA is out of sync, there
is a helpful hint to resync CSA.
If your workfile is not in sync with your CP, then it is impossible to make
the workfile match the CP image without an initialize --> reboot --> reload.
-----Original Message-----
From: pedersen.em@xxxxxx [mailto:pedersen.em@xxxxxx]
Sent: Thursday, April 10, 2003 1:16 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Control Blocks missing in ICC Configuration
I have experienced this a few times and have always done a LoadAll in o=
rder to
fix it. That is the official fix according to Foxboro. There is a hel=
pful hint
that describes a different fix but I have never tried it . The quick f=
ix is
pasted below.
Eric Pedersen
Procter & Gamble Paper Products Company
Oxnard Plant
HH#: HH980
IA INFO: aec0102
File: CSA
Release: 4.3/6.x
Date: Oct 31, 2001
Subject: Fixing Control database mismatches (Missing control blocks)
Source: Personal experience
PROBLEM:
Some Control Blocks are running in the CP, show in Select, but not in I=
CC.
Case 1: CSA host is different from CP's host.
Case 2: CSA host is the same station that hosts the CP.
The official solution to this problem is to Initialize-Reboot-Loadall,
to have all control databases in sync again, but sometimes you can not
afford to reboot the CP. This procedure will allow you to rebuild those=
missing blocks. (I have not tried to fix whole compounds).
CAUTION: If the blocks to be "fixed" are control blocks (AOUT, PID, etc=
)
take the required measures to manually operate those valves! During th=
ese
procedure those blocks will be removed from the CP temporarily.
(To identify the CSA host and the CP's host see instructions at the end=
).
REFERENCE INFORMATION:
There are 3 databases that need to be in sync.
CSA: List of all compounds/blocks in the system.
The files are on the CSA host.
Initial ICC display lists compounds from CSA.
Workfile: What "ICC" looks at in "Edit Station".
The files are on the CP's host AP/AW.
The "Edit Station" display lists compounds from these files.
CP: Compound/Blocks running in the CP. What "Select" looks at.
Checkpoint file saves this info.
To identify any mismatch in those 3 databases use either the check_db_s=
ync
utility or compare the results of: csa_stn_save, iccprt, getpars, dbvu
that examine CSA, ICC Workfiles, CP or Checkpoint respectively.
PROBLEM 1:
Some Control Blocks are running in the CP, show in Select, but not in I=
CC.
CSA host is DIFFERENT from CP's host.
The typical scenario:
The hard drive of "AW0001", host of "CP0001", failed.
The CP's host hard drive is restored from backup tapes 2 months old.
The CSA host "AW0002", a different station, is ok.
The CP keeps running and controlling the process.
Now, there are 3 'ghost' blocks that show on Select but not in ICC.
We need to edit those blocks but they don't exist in ICC.
We can not add them back in ICC because we get a message: Block alread=
y exist.
What can I do?
This is what happened:
The backup tape was made when all the control databases were in sync.
Some time later 3 more control blocks were added to COMPND101 in CP000=
1.
The ICC (workfile) and Checkpoint files on AW0001, the CP's host,
were modified accordingly.
On the CSA host (AW0002): the CSA database was also updated.
On the CP (CP0001): the 3 blocks were added and now they are running.
When the restore was made to AW0001, the ICC workfile and Checkpoint
did not have the 3 new blocks.
The CSA database on AW0002 still has those 3 blocks in the database.
The CP still has those 3 blocks running.
Now, you can NOT add those 3 blocks with ICC because the CSA Server do=
esn't
allow to have duplicate names.
You can still make a checkpoint to update the checkpoint file
(recommended, in case the CP needs to be rebooted) but you can NOT cre=
ate
blocks in ICC from what is running on the CP.
THE SOLUTION:
Goal: DELETE those 3 new blocks from CSA and the CP, to be able to add=
them back manually with ICC. At the end, all control databases should b=
e
in sync again.
PROCEDURE:
Be sure you have a list of all the parameters for those blocks.
You will need them to rebuild the blocks in ICC.
Use either Select display or dbvu to get that information.
To use dbvu make a Checkpoint first, then go to the CP's host and type:=
cd /usr/fox/sp/files
/opt/fox/bin/tools/dbvu -t -CDBcplbug.UC -MOS1CXX.map -IOS1CXX > /opt/t=
mp/cplbug.txt
Replace OS1CXX with:
OS1C30 for CP30, OS1C40 for CP40, OS1C3B for CP30B, OS1C4B for CP40B
You might need to uncompress the map file: uncompress OS1CXX.map.Z
The file /opt/tmp/cplbug.txt will have all the parameters of all blocks=
in the CP.
A) Delete blocks from CSA:
Summary:
Create an ascii db file from CSA for that CP,
Edit the file and delete the extra blocks,
Clear CSA db for that CP,
Add the modified ascii-file db to CSA using CSA_Merge.
Detailed Steps:
Go to the CSA Host (e.g. AW0002)
If /opt/tmp does not exist, create it: mkdir /opt/tmp
cd /opt/fox/csa
tar cvf /opt/tmp/csa_tar . (Optional: Backup of all CSA files)
mkdir /opt/tmp/new
/usr/fox/csa/csa_stn_save CP0001 > /opt/tmp/new/CP0001
This saves the CP0001 CSA database into ascii file CP0001
vi /opt/tmp/new/CP0001
Delete the 3 lines for those extra 3 Blocks BLK1,2,3
cd /usr/fox/csa
sh
csa_fn reset CP0001 (prompt will return quickly)
This will remove all CSA entries for CP0001 from master CSA db
ls -lrt /opt/fox/csa (Optional: to check dates:
STN_INDEX.*,CMPD_INDEX.*, CP0001)
CSA_Merge /opt/tmp/new (prompt will return after a few seconds)
This will add the modified csa-db for CP0001 to the master CSA dat=
abase
B) Delete blocks from CP/Add blocks to ICC:
Summary:
The blocks will be deleted from the CP the first time you try to add th=
em
back. The second time the blocks will be added succesfully.
Detailed Steps:
Go to ICC, select CP0001, compound CMPND101 (the one with the extra 3
blocks)
Click on: Insert New Block, and type name: BLK1
This message will come up:
"CMPD00X:BLK1, E40 - COMPOUND OR BLOCK ALREADY EXIST, FAILED,
Select CONTINUE to Proceed"
Two seconds after click on CONTINUE, the block goes to Cyan (seen
from Select), and at this moment is deleted from CP Memory.
Again, click on Insert New Block and type name: BLK1
This time the command will be accepted. Continue editing parameters.
Follow the same procedure for BLK2, and BLK3.
The control databases are in sync now.
PROBLEM 2:
Some Control Blocks are running in the CP, show in Select, but not in I=
CC.
CSA host is the SAME station that hosts the CP.
If the station that hosts the CP is also the CSA Server, to fix the pro=
blem
just follow Part B of the procedure above for Problem 1.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
TO IDENTIFY THE CP HOST:
On any AP/AW type: grep CPLBUG /usr/fox/sp/sldb
The CP host is the second word of the result.
Example:
4APB01# grep 4CP3B1 /usr/fox/sp/sldb
4CP3B1 4APB01 4APB01 SYMN4A
^^^ ^^
CP CP_Host
TO IDENTIFY THE CSA HOST:
On any AP/AW type: grep ACSA /usr/fox/sp/IIF.pkg
The CSA host is the first word of the result.
Example:
3AWE01# grep ACSA /usr/fox/sp/IIF.pkg
4APB01 4APB01 4APB01 ACSA6 AP51 NOTYET e295 00 00 0000 00000
^^^
CSA_Host
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
HH980
From: "Control y Automatizacion (Rodolfo Piedra)" <rpiedra@xxxxxxxxxxx>=
on
04/10/2003 10:24 AM GMT
=
=20
"Control y To: foxboro@xxxxxxxxxxxxx =
=20
Automatizacion Cc: (bcc: Eric Pedersen-EM/PGI) =
=20
(Rodolfo Piedra)" Subject: [foxboro] Control Blocks missing=
in =20
<rpiedra@xxxxxxxxxxx> ICC Configuration =
=20
=
=20
=
=20
04/10/2003 03:24 AM =
=20
Please respond to =
=20
foxboro@xxxxxxxxxxxxx =
=20
=
=20
=
We are experiencing a problem in one of our CP where some new blocks ar=
e
actually running and showed in FoxSelect but they are not present in th=
e ICC
configuration.
We can not delete them, because they are running OK, but need to back u=
p
properly because we feel they will be lost if we reboot the CP.
Any ideas?
Thanks in advance,
Rodolfo Piedra
Control y Automatizaci=F3n SA
_______________________________________________________________________=
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: //www.freelists.org/list/foxboro=
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djo=
in
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dlea=
ve
=
_______________________________________________________________________
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: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
_______________________________________________________________________
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: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
EOM
NOTICE - This message and any attached files may contain information that is
confidential and/or subject of legal privilege intended only for use by the
intended recipient. If you are not the intended recipient or the person
responsible for delivering the message to the intended recipient, be advised
that you have received this message in error and that any dissemination,
copying or use of this message or attachment is strictly forbidden, as is
the disclosure of the information therein. If you have received this
message in error please notify the sender immediately and delete the
message.
_______________________________________________________________________
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: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
