Re: [foxboro] PIDA block weirdness

Tim,
        We have seen something like this and I think Kevin is on target with
his question about .INHALM and .INHSTA.  You mention a custom overlay that
didn't show the block was inhibited.  Is the connection on the custom
overlay connected to the .INHIB parameter?  If so the .INHIB parameter will
not be true if only one of the PIDA's alarms are inhibited such as HIABS.
The .HIABS can be individually inhibited from the PIDA block detail display
through the use of .INHALM but .INHIB will still stay FALSE.  .INHSTA is a
status parameter that indicates which of the blocks alarms are currently
inhibited.  Here is an example table for .INHALM that can inhibit individual
alarms:
When .INHALM equals
0x0------------------->No Alarms Inhibited
0x1------------------->LOABS Inhibited
0x2------------------->HIABS Inhibited
0x3------------------->LOABS & HIABS Inhibited
etc.

        If the HIABS was inadvertently inhibited from the PIDA block detail
display by selecting HIABS and then clicking the TOGGLE button on the ALARM
overlay, .INHALM would = 0x2 but .INHIB would still be = 0.  If you went
into the ICC and looked at .INHALM it might still show 0x0 unless you upload
the block.  Since dbvu runs on the checkpoint file, it too, might return 0x0
if the CP had not yet been checkpointed.  Before deleting and undeleting the
block, I feel confident you did an upload which would have saved the .INHALM
value of 0x2 to rebuild the block in memory.  When you deleted the PIDA and
rebuilt it from scratch the default value was 0x0 for .INHALM so that
cleared your .HIABS inhibit and solved your problem.  This is only a theory
but that happened to us several times before we figured it out.  The .INHALM
parameter was introduced in Ver4.0 or 4.1 software release.  Before that,
alarms were inhibited "ALL or NONE" based on the .INHIB parameter which can
still do the "ALL or NONE" but isn't aware if alarms are inhibited by
.INHALM.  BTW, the "ALARM" button on the PIDA block detail display is
connected to .INHSTA and will turn from "WHITE" text to "GRAY" text if any
of the blocks alarms are inhibited.

Hope this helps.

Tom VandeWater
Control Systems Developer/Analyst
Dow Corning Corp.
Carrollton, KY   USA

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx]On Behalf Of Kevin FitzGerrell
Sent: Monday, January 24, 2005 4:35 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] PIDA block weirdness


Tim,

Did you check the .INHSTA and .INHALM values?

Do you still have a copy of the checkpoint file from before you fixed the
problem (maybe the BBlbug.UC)?  I find it helpful to use dbvu to look at the
block parameters as stored in the CP for troubleshooting problems like this.

Regards,

Kevin FitzGerrell
Systems Engineer
Foxboro New Zealand
------------------------------------
Tel:  +64 (9) 573 7690
Fax:  +64 (9) 573 7691

Quoting "Lowell, Tim:" <Tim.C.Lowell@xxxxxxxxxxxxxxxxxx>:

> List,
>  
> 
> We had a weird one today, and I was wondering if anybody had ever
> witnessed similar behavior.
> 
>  
> 
> One of our console guys was trying to inhibit the alarms on a PIDA
> block
> from a custom PIDA faceplate, and it wouldn't inhibit. Then he tried to
> force the block into a MEASHI alarm by changing the MEASHI alarm
> setting, and it would no longer go into alarm. We looked at it, and the
> block really was inhibited, but the custom faceplate didn't show it,
> nor
> did the standard PIDA detail display. Then we uninhibited it from the
> engineering station in a cmdtool window using omgetimp on the .INHIB
> parameter. We verified that the .INHIB parameter was FALSE, and that
> the .CINHIB parameter for the compound was FALSE. We then tried to
> force it into alarm again, and it still wouldn't go into alarm. So next
> we tried to hit "enter" in ICC on some parameters and hit "DONE". No
> change. Then we deleted/undeleted the block. Still nothing.
> 
>  
> 
> Finally, we completely deleted the block, checkpointed, and then
> rebuilt
> the block from scratch. Now it works fine. Has anyone ever seen such a
> thing? I'm a little concerned that we have other blocks in the same
> state and don't even know it. The danger is that any blocks in this
> state could go into an alarm condition, and no alarm would sound. The
> last time anybody might have edited this block was maybe 2 years ago.
> It's a fuel gas flow to a furnace, so it's not something that we would
> want to modify very often under any circumstances. If you've ever seen
> anything like this, please let me know.
> 
>  
> 
> Thanks,
> 
>  
> 
> Tim Lowell
> 
> Control Systems Engineer
> 
> ConocoPhillips Trainer Refinery
> 
> (610) 364-8362
> 
> tim.c.lowell@xxxxxxxxxxxxxxxxxx
> 
>  
> 
> 
>  
>  
> ______________________________________________________________________
> _
> 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
>  
>  

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