Re: [foxboro] Does compound reload still == block init?

  • From: Maks Wilde <mwilde@xxxxxxxx>
  • To: foxboro@xxxxxxxxxxxxx
  • Date: Wed, 19 Oct 2011 11:17:55 -0400

Corey,
I have recently done this on a CP where I was particularly concerned about
initialization.
I built a test compound with a test CALCA block to check if a particular
change to a compound would initialize it.
CALCA looks like this:

STEP01 BII 7 ; Branch if Initializing
STEP02 RCL BI01 ; This is the input that I use to reset my "block has
initialized" flag after a test
STEP03 BIF 5
STEP04 CLR BO01 ; Clear flag
STEP05 EXIT
STEP06
STEP07 SET BO01 ; Set flag
STEP08 END

You can test this by turning the compound on/off, and see the flag come up.
When I made changes to the compound's alarm parameters, the block did not
initialize.

Hope this helps,

Maks Wilde




On Sun, Oct 9, 2011 at 12:30 PM, Kevin Fitzgerrell <fitzgerrell@xxxxxxxxx>wrote:

> Corey,
> I've also modified compound alarm parameters without seeing block
> initialization of the blocks within the compounds.
>
> Regards,
>
> Kevin
>
> On Sun, Oct 9, 2011 at 8:33 AM, Corey R Clingo <corey.clingo@xxxxxxxx
> >wrote:
>
> > While one of my plants is down for a turnaround, I went ahead and ran a
> > few icc scripts through the system to set the alarm destinations (GRmDVn)
> > in the compounds appropriately. I waited for an outage to do this because
> > I had tried something similar once before and had a trip in one section
> of
> > the plant -- though, in hindsight, I assumed that TIMINI would be set to
> 3
> > on all the CALCish blocks, and it wasn't in most cases, and I think that
> > was the cause of the trip (we all know what happens when you assume :).
> >
> > Because of that experience, I had waited until a turnaround to run these
> > scripts. I am currently under the presumption that modifying a parameter
> > in a compound and reloading the compound definition would cause all the
> > compound's blocks to initialize. However, I watched several blocks while
> > running these scripts and never saw any momentary smurfing. I know that's
> > not a good test, you don't always see the insta-smurf, but I was just
> > wondering if the whole compound reload == block init thing is still true.
> > I'm at IA version 6.5.3
> >
> >
> > If it is still true, I may consider switching to station alarming. I
> > didn't want to really, as that means the *GP parameter will need to be
> > changed on every block. But we will likely be making further changes to
> > our alarm destinations as we move forward with alarm management, and we
> > only have turnarounds every 4-5 years :)
> >
> >
> > Thanks,
> > Corey Clingo
> > BASF
> >
> >
> >
> > _______________________________________________________________________
> > 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
>
>


-- 
Confidentiality Warning: This message and any attachments are intended only
for the use of the intended recipient(s), are confidential, and may be
privileged. If you are not the intended recipient, you are hereby notified
that any review, retransmission, conversion to hard copy, copying,
circulation or other use of this message and any attachments is strictly
prohibited. If you are not the intended recipient, please notify the sender
immediately by return e-mail, and delete this message and any attachments
from your system.


 
 
_______________________________________________________________________
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: