Re: [foxboro] GDEV mismatch alarm in one direction only
- From: "Quay B. Finefrock" <qbfinefrock@xxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Thu, 12 Sep 2013 11:02:44 +0800
Christian,
That is what I was originally hoping to make use of. But I believe that
these only determine which limit switch inputs are utilized to generate the
mismatch alarm and not to determine whether or not the mismatch alarm will
be generated in a given direction.
I made an interesting note when I was testing the IGNLMx functionality but I
haven't had time to go back and check it. It appeared to me that if you set
both IGNLM1 and IGNLM2, the block ceases to function (i.e. the outputs are
not set when DSR is changed). If it is true, that is really a nice feature
:-)
Regards,
Quay
Quay B. Finefrock
Email: qbfinefrock@xxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Horn, Christian
Sent: Thursday, September 12, 2013 10:56 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] GDEV mismatch alarm in one direction only
Quay,
How about the IGNLM1 & IGNLM2 parameters, these are settable and when true
they ignore the limit switch inputs and disable the mismatch alarm for
DEVLMx inputs?
Regards,
Christian Horn
---------------------------------------------------------------
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Quay B. Finefrock
Sent: 12 September 2013 09:18
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] GDEV mismatch alarm in one direction only
Doug,
I agree that it is better not to write user logic if there is a standard
block that provides the desired function. That is why I was looking for a
way to do this within the GDEV block.
The real problem is that the HOA (RCU) signals are not available in the DCS.
If they were, then we could use the field command for the DSR_RB.
The users give the manual stop command via a button on the operator display.
The block needs to stay in Manual so connecting something to the AUTDSR is
not useful in this case and there is no transfer. I am using MANDSR for the
manual stop and INTLCK for the interlock.
Quay B. Finefrock
Email: qbfinefrock@xxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Douglas G. Lloyd
Sent: Thursday, September 12, 2013 7:58 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] GDEV mismatch alarm in one direction only
Quay,
The GDEV block was designed for exactly how you want to use it and the
DSR_RB parameter is specifically to Read Back the Desired state from
downstream logic for feedback comparisons. By connecting the AUTDSR from
the Run Feedback as suggested, you also get a bumpless transfer into Manual.
All that plus timed monitoring of the feedbacks, INTLCK function, Hold
function, etc. IMHO, it's always better to make use of standard product
features before leaping off into CALCAs and rolling your own...
Regards,
Doug
DGL Controls
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Quay B. Finefrock
Sent: Wednesday, September 11, 2013 6:23 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] GDEV mismatch alarm in one direction only
Thank you for the input William & Doug. I don't think it is difficult to
write some user logic external to the GDEV block to accomplish what I want.
I was hoping for a way to do what I want within the GDEV function block
itself. I guess that is not possible. Maybe in this case there is no real
reason to use the GDEV block. I could just use a CALCA block, CIN's and
COUT's for the pump and skip the GDEV block altogether.
Regards,
Quay
Quay B. Finefrock
Email: qbfinefrock@xxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Douglas G. Lloyd
Sent: Wednesday, September 11, 2013 10:09 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] GDEV mismatch alarm in one direction only
Quay,
As Mr. Ricker started to explain, the DSR_RB parameter is what is used to
compare against the device feedbacks if it is connected. So, if you build
some logic to AND the combination of the run feedback with NOT INTLCK and
(MA OR MANDSR) and connect it to DSR_RB, you should be all set. You could
also connect the Run Feedback to AUTDSR see when the device is driven from
the default display and elsewhere.
Run Feedback
AND
NOT INTLCK
AND
(MA OR MANDSR)
I think that this is right. Check the details, but you get the idea...
Regards,
Doug
DGL Controls
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of William C Ricker
Sent: Tuesday, September 10, 2013 5:46 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] GDEV mismatch alarm in one direction only
Memory is fuzzy, but I seem to remember doing that on a paper machine
somewhere with a couple of hundred motors around it. I think we fed
something into the DSR_RB parameter to defeat the alarm when we didn't want
it.
WCR
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Quay B. Finefrock
Sent: Thursday, September 05, 2013 9:59 PM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] GDEV mismatch alarm in one direction only
Good day all,
I am using GDEV blocks to drive pumps from the DCS. In some cases, the pump
may be started locally from the HOA (RCU) and only stopped from the DCS.
For these pumps, I want a mismatch alarm if the operator attempts to
manually stop the pump (via GDEV.MANDSR) or if the pump is interlocked (via
GDEV.INTLCK) and the pump state does not change to STOPPED. But I don't
want to get a mismatch alarm when the operator starts the pump from the HOA.
Unfortunately, the signal from the HOA is not available in the DCS. Is
there any way that I can configure the GDEV to yield a mismatch alarm in one
direction but not in the other?
Also, I don't see any way to disable the mismatch alarm other than
inhibiting it. Is that the only way?
Regards,
Quay
Quay B. Finefrock
Singapore Phone: +65 9 327 2923
Brunei Phone: +673 883 1480
Philippines Phone: +63 921 400 2886
Malaysia Phone: +60 17 820 6900
Email: qbfinefrock@xxxxxxxxx
_______________________________________________________________________
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 Notice: This e-mail, including any associated or
attached files, is intended solely for the individual or entity to which it
is addressed. This e-mail is confidential and may well also be legally
privileged. If you have received it in error, you are on notice of its
status. Please notify the sender immediately by reply e-mail and then delete
this message from your system. Please do not copy it or use it for any
purposes, or disclose its contents to any other person. This email comes
from a division of the Invensys Group, owned by Invensys plc, which is a
company registered in England and Wales with its registered office at 3rd
Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023). For
a list of European legal entities within the Invensys Group, please select
the Legal Entities link at invensys.com.
You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail
reception@xxxxxxxxxxxx. This e-mail and any attachments thereto may be
subject to the terms of any agreements between Invensys (and/or its
subsidiaries and affiliates) and the recipient (and/or its subsidiaries and
affiliates).
_______________________________________________________________________
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:
