Re: [foxboro] INVALM issue on a CIN block -- solved

It sounds like you already have your question answered.  But for what it
is worth we also have a convention with CIN blocks for discrete devices
where the block always reflects the actual state of the device (IVO = 0)
and then use the INVALM option as necessary to generate an alarm in the
proper state.  As such SCTXT0 always describes the Off state, SCTXT1
always describes the On state, and NM1 is the In Alarm message and NM0
is the Return to Normal message.  Many discrete devices such as level,
pressure, flow switches are configured for failsafe operation and we
used to use the IVO option; however, our techs and electricians were
used to seeing these being On as normal.  Having the CIN block reflect
this actual state and just using INVALM to generate an alarm in the Off
state has eliminated much confusion. 

Tom Badura
Plastics Engineering Company
920-458-2121 x3366
tbadura@xxxxxxxxxx


-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Corey R Clingo
Sent: Thursday, August 21, 2008 5:16 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] INVALM issue on a CIN block -- solved

I do that some, too, but we have some conventions for configuring 
parameters like IV0 that vary by application.  These blocks are motor
run 
status, and one of our conventions (well, mine anyway :) is that the CIN

is ON when the motor is running.  In this case, the operations folks
want 
an alarm when the motor is stopped; hence the use of INVALM.

However, a rereading of the documentation has answered my question, and 
actually (after only 7 years or so :) clarified my understanding of what

SCTXT0/SCTXT1 vs. NM0/NM1 are really supposed to be used for.  In a 
nutshell, SCTXT0 and SCTXT1 are text definitions of the actual block 
states, whereas NM0 is the "return-to-normal" alarm message, and NM1 is 
the "in alarm" alarm message -- _regardless_  of how INVALM is set.  My 
apologies to the guy who built the CIN detail and faceplate displays for

using (what I thought were)  the "state change" parameters instead of 
(what I thought were) the "state name" parameters.  He had many
aspersions 
cast his way :)


I believe I just need to swap my NM0 and NM1 text and I think it will 
work.


Corey Clingo
BASF Corporation


P.S. while digging through the docs, I found a couple other potentially 
useful blocks.  Anyone ever used a DPIDA?  It looks cool for high-speed 
loops, if it will work in any 200-series FBMs.  Better for a handful of 
fast loops then making your entire CP 0.1 BPC.





"Illingsworth, John" <JIllings@xxxxxxxxxxxxx> 
Sent by: foxboro-bounce@xxxxxxxxxxxxx
08/21/2008 05:04 PM
Please respond to
foxboro@xxxxxxxxxxxxx


To
"'foxboro@xxxxxxxxxxxxx'" <foxboro@xxxxxxxxxxxxx>
cc

Subject
Re: [foxboro] INVALM issue on a CIN block






Corey
We use the IVO paramater to invert alarms in CIN blocks.

Regards
John Illingsworth
NRG Gladstone Power Station
Gladstone QLD 4680



-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]

On Behalf Of Corey R Clingo
Sent: Friday, 22 August 2008 7:57 AM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] INVALM issue on a CIN block


Hi list,

Yes, I'm fishing for a quick answer before I call TAC :)


We had to change some CIN blocks today such that the alarm state was the

OFF state on the blocks.  I set INVALM to 1 and the block detail display

looked fine -- the OFF state of the block caused the big red STATE to
come 
up, and the ON state caused the alarm to clear (well, STATE changed to 
UNACK).


However, when I look in the alarm history display, it appears that
INVALM 
is being ignored there.  The ON state of the CIN block generates the
alarm 
message, and the OFF state generates the return message -- exactly the 
opposite of what I'm seeing on the block detail.  The alarm "printer" 
(actually, a PC running Visual Alert) exhibits this same behavior.


I looked through the QFs for I/A version 6.5.3 but didn't find anything.

Anyone ever seen anything like this before?  I'll probably
delete/undelete 
all the changed CIN blocks next if I can't find some other remedy.
These 
blocks are in a CP40A.


Thanks,

Corey Clingo
BASF Corporation






_______________________________________________________________________
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


The contents of this electronic message and any attachments are intended

only for the addressee and may contain legally privileged, personal, 
sensitive or confidential information. If you are not the intended 
addressee, and have received this email, any transmission, distribution,

downloading, printing or photocopying of the contents of this message or

attachments is strictly prohibited. Any legal privilege or
confidentiality 
attached to this message and attachments is not waived, lost or
destroyed 
by reason of delivery to any person other than intended addressee. If
you 
have received this message and are not the intended addressee you should

notify the sender by return email and destroy all copies of the message 
and any attachments. Unless expressly attributed, the views expressed in

this email do not necessarily represent the views of the company.
 
 
_______________________________________________________________________
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: