Re: [foxboro] "GDEV" or "VLV,MOVLV,MTR" or "CALC" - Discrete control engineering advice ?

Chuck,

Another work around is to drive PLB ladder logic as follows.

  GDEV Start
  Request (COUT_1)
--||-------------------------------------------------(TON) 7s

  Running           GDEV Start
  Feedback          Request (COUT_1)
--||------.---------||-------------------------------(Start Motor)
          |
 Timer DN |
--|/|-----.


If a motor trips, the (Start Motor) contact will drop out and the mismatch
on the GDEV will indicate an alarm. The advantage is that the alarm remains
active until cleared by the operator. The operator must stop the motor
before it can be re-started.

mk



> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx
> [mailto:foxboro-bounce@xxxxxxxxxxxxx]On Behalf Of Jones, Charles R.
> (Chuck)
> Sent: Wednesday, August 01, 2007 5:01 PM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] "GDEV" or "VLV,MOVLV,MTR" or "CALC" - Discrete
> control engineering advice ?
>
>
> As previously stated, the GDEV block is very versatile and useful.  We
> use GDEV blocks at every opportunity for all of the reasons mentioned in
> earlier posts.  However, I remember a glaring weakness in an otherwise
> ideal block.  Unlike a hardwired motor (or ladder logic), the GDEV will
> not remove the power request to the motor if the motor loses its
> feedback (auxiliary contacts). =20
>
> I have worked around this by tying the MMAIND (Mismatch Alarm Indicator)
> into the INTLCK parameter, thus forcing the GDEV into its Interlock mode
> (and over-riding either Manual or Auto modes) to drive the GDEV off.  I
> tie the INTDSR (Interlock Desired State) back onto itself (so that its
> state cannot be changed) and give it the default value of OFF.  Once the
> GDEV output is OFF, the desired state matches the feedback state so the
> GDEV is no longer in Mismatch Alarm and the GDEV passes out of the
> Interlock mode and back into the Manual mode in the OFF state.
>
> The additional connections are as follows:
> INTLCK =3D :Blockname.MMAIND
> INTDSR =3D :Blockname.INTDSR.0
>
> This solution assumes a few things, such as the assumption that the
> INTLCK parameter was otherwise not going to be used.  The same
> assumption is made for the desired state of the Interlock, INTDSR.  The
> most difficult consequence for us to live with is that the GDEV is left
> in the Manual mode.  Most of the time, it has not been a problem.
>
> As always, "your mileage may vary".  I am going from memory here, so
> will wish to verify my statements, test the results for yourself, etc.
>
> Chuck Jones
> Automation Technologist
> Tate & Lyle -- Lafayette Plant
> Office 765.477.5324 | Cell 765.586.5290
>
>
>
>
> ******************************************************************
> *********=
> **************************
> This email and any files transmitted with it are confidential and
> intended =
> solely for the=20
> use of the individual or entity to whom they are addressed. If
> you are not =
> the intended=20
> recipient or the person responsible for delivering the email to
> the intende=
> d recipient, be=20
> advised that you have received this email in error that any use,
> disseminat=
> ion,=20
> forwarding, printing, or copying of this email is strictly
> prohibited.  If =
> you have received=20
> this email in error please notify the sender immediately. Please
> note that =
> we reserve=20
> the right to monitor and read any emails sent and received by the
> Company i=
> n=20
> accordance with and to the extent permitted by applicable legal rules.
> ******************************************************************
> *********=
> **************************
>
>
> _______________________________________________________________________
> 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: