Re: [foxboro] Station block parameters - OMSCAN I/A 8.7-ZCP270

  • From: "Pulas, Philip" <Philip.G.Pulas@xxxxxxxxxxx>
  • To: "foxboro@xxxxxxxxxxxxx" <foxboro@xxxxxxxxxxxxx>
  • Date: Mon, 16 Feb 2015 17:23:28 +0000

Dirk,

For #1, I've found that after you set the inactive button to active, 
checkpointing from System Manger or SMDH keeps this option active from then on.

Have you tried rsom to see how lists you have open to your station?  It will 
give you the PID for any AW's involved and then you can cross-reference that on 
the AW to find what programs are making the connections to your ZCP's.  I'd 
look for any with lots of lists open to one AW.  That's helped me out when 
checkpointing would lead to OMSCAN spikes that would "smurf" all points from a 
CP.

Thanks,
Philip Pulas
Lead Engineer, Process Systems
Tesoro Golden Eagle Refinery
Ph: (925) 372-3043
Email: philip.g.pulas@xxxxxxxxxxx

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On 
Behalf Of Dirk Pauwels
Sent: Friday, February 13, 2015 2:02 AM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] Station block parameters - OMSCAN I/A 8.7-ZCP270

Hi list,
2 questions:


1.       We're monitoring the station block parameters for one of our ZCP270's, 
because the total memory is low (1100000) and the OMSCAN is high (12%). (see 2.)
Doing this I noticed that both in DCS and (off course) in PI these station 
block values were stale for longer periods. If I check the foxselect station 
block display and click the inactive button to active, the values start 
updating. Yet if you check the display again later the updating is back to 
inactive. Why doesn't it remain active, and do we get a correct trend this way? 
It looks like the trends are not reliable because of this active/inactive 
behavior?


2.        We're experiencing problems with MAXMEM dropping below the CSIZE so 
we cannot compile certain sequences anymore. (CP reboot solves this very 
temporarily, but we're restricted to plant maintenance shutdowns to do this.)  
Also sometimes sequences fail (handled by exception handlers) on external 
links. I know the use of external links is discouraged, but in the other CP's 
it works fine and it's not easy to correct this on +- 1000IND's. The sequence 
then generates a sys error > 3000. Normally we're supposed to exit the sequence 
in that case, but because it happens regularly we're adjusting the exception 
handlers to allow some retries, also in case of this type of error.



We've had this problem for the last 2 years, all this time we were told it was 
due to CSPACE/CSIZE problems and we needed to correct the CSPACE settings. 
Preventive maintenance twice a year never reveiled anything out of the 
ordinary. Although OMSCAN was high, it was never mentioned this could be a 
problem.  It's clear now that CSPACE/CSIZE is not the cause.

What's been done so far:

                Adjust all of the CPACE sizes, checked by Invensys and approved.

                Installed latest CP images. 90035

                Rebooted CP's (both simultaneously, primary and shadow)

                Slowed down scan rate for OSISOFT PI to 2 seconds and cdtlay 
from 50 to 200.

                Stopped foxray and other 3rd party services  to see if it made 
any difference .

                Removed restore_index.dat, and rebooted the boothost.



None of these actions showed any difference in OMSCAN load.



During our last maintenance shutdown I monitored the OMSCAN and although there 
was no production and none of the sequences were active the OMSCAN was still 
high, the only difference was that in normal operation the OMSCAN varies a lot, 
and during shutdown it was more or less stable.



According to Invensys OMSCAN is the cause of our problems and we need to find 
the reason why OMSCAN is too high. Anyone have any idea's?


Thanks & Rgds,
Dirk
 
 
_______________________________________________________________________
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:

  1. Home
  2. foxboro
  3. Archive
  4. 02-2015