Re: [foxboro] INVALM issue on a CIN block -- solved
- From: "tjvandew@xxxxxxxxx" <tjvandew@xxxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Sat, 23 Aug 2008 09:07:39 -1000
Tom,
I strongly agree with your CIN solution below. In my past
experience at Dow Corning, and again on the project here in Hawaii we
decided that using IVO created too much confusion for field
troubleshooting activities as well as application programming
understanding. IMO it could have been more understandable if IVO meant
Invert Output instead of Invert Option. If the .CIN (output parameter)
was inverted instead of making the .IN parameter invert when using IVO
it would be better. We got bit here in Hawaii when using the CAPE
simulator because when IOMOPT is set to 0 for simulation, the block
functions differently then it does when getting it's .IN value from the
actual FBM when .IOMOPT is set to 1. When IOMOPT = 0 the block appears
to invert the output, (.CIN) based on the opposite value of the .IN
parameter.
Eliminating the use of .IVO and using .INVALM anytime you want to
alarm when a contact opens in field makes everything consistent across
the board. In that way SCTXT0 always describes the open field contact
state and SCTXT1 always describes the closed field contact state. Since
.NM1 is always the alarm state text and .NM0 is always the return to
normal state text the only decision left is whether to set .INVALM to 1,
(alarm on open contact) or 0, (alarm on closed contact).
Regards,
Tom VandeWater
Control Conversions Inc.
Badura, Tom wrote:
> 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: //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: //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
>
>
>
> _______________________________________________________________________
> 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
Other related posts:
