Re: [foxboro] GDEV mismatch alarm in one direction only
- From: "Horn, Christian" <Christian.Horn@xxxxxxxxxxxx>
- To: "foxboro@xxxxxxxxxxxxx" <foxboro@xxxxxxxxxxxxx>
- Date: Wed, 11 Sep 2013 23:21:11 -0400
Yes an "interesting" feature!
I thought the way the IGNLM1&2 worked was when one is set the GDEV block will
simulate the limit switch contact and avoid the mismatch... But it's been a
long, long time since I played with one.
Christian Horn
---------------------------------------------------------------
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Quay B. Finefrock
Sent: 12 September 2013 11:03
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] GDEV mismatch alarm in one direction only
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
*** 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
Other related posts:
