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

Other related posts: