Re: [foxboro] Motor Start/Stop Logic

This topic, although it sounds simple, has it's complexity.

Brad Wilson said:
I must be missing something in all this.  Don't you all use the
auxiliary
contacts built into the motor starter to hold in the starter?

Yes, Brad, you missed something:
The Remote DCS Start Contact is not sealed/latched at the motor starter
with an auxiliary contact because, on many of our motors we send only
one contact to the field that does both Remote Start and Remote Stop.
If we sealed that contact in the motor starter with an auxiliary contact
the DCS could never STOP the motor.  Check it out below using your
example with the DCS Stop contact removed.

  local        local   motor
   stop        start    coil
---|/|-------|--| |--|--(M)--|---
             |       |       |
             |  DCS  |  run  |
             |srt/stp|  ind  |
             |--| |--|--(X)--|
             |       |
             | motor |
             |  aux  |
             |--| |--|

We are looking for a "One-Size-Fits-All" solution for all of our various
motor wiring schemes.  Yes, we have some motors that have separate DCS
Start and Stop contacts wired in the way Brad showed, and yes that is
very simple as he shows below:

  local DCS    local   motor
   stop stop   start    coil
---|/|--|/|--|--| |--|--(M)--|---
             |       |       |
             |  DCS  |  run  |
             | start |  ind  |
             |--| |--|--(X)--|
             |       |
             | motor |
             |  aux  |
             |--| |--|

But we also have many situations as shown below in a simplified motor
elementary.  When the selector is in Hand the local start is in play and
the DCS can neither stop nor start the motor.  When in Auto the local
stop can stop the motor and the DCS can start or stop it.  It is in this
situation that we need the MOTOR or GDEV block to latch in it's .COUT_1
if, (and only if), it gets feedback from the motor run indicator. =20

  local     hand/    local                      motor
   stop     auto     start                       coil
---|/|---|---\/----|--| |--|---------------------(M)--
              |    |       |    |                    |
              |    | motor |    |    run             |
              |    |  aux  |    |    ind             |
              |    |--| |--|    |----(x)-------------|
              |                 |
              |       DCS       |
              |     strt/stp    |
              |-------| |-------|

Mark Blunier's information about the MOTOR blocks' .RSMMOP parameter was
very interesting and we immediately put it to the test in the field.
His solution would work for the condition shown above, (hand/auto), with
single DCS output, but not when the DCS has separate contacts for Start,
(.COUT_1), and Stop, (.COUT2). At first I thought it was going to meet
our needs exactly but there are a few fatal flaws in the way a MOTOR
block works, (or doesn't work), with RSMMOP set to one. =20

RSMMOP - Reset Mismatch Option is used to specify that the DSR input be
reset when a mismatch alarm occurs in The MTR block.
ZERO equals No reset action.
ONE equals  Reset DSR inputs if mismatch alarm occurs

        This is potentially a very useful parameter because it does what
many of you said you would like the GDEV/MOTOR block to do, (It is only
available in the MOTOR block)
When RSMMOP is true and a mismatch occurs, a mismatch alarm is
immediately sent, and simultaneously the Desired State Requests,
(.MANRUN or .AUTRUN in the MOTOR block), follow the current status of
the motor, (.MSTAT).  In other words, if the motor stops running while
MANRUN is TRUE the block will do the following:

- sense the mismatch and send an alarm
- set MANRUN to FALSE
- hold the mismatch alarm TRUE until the block is Acknowledged, (this
feature is unusual but useful to insure that operations is notified that
a running motor has stopped running.  Normally the mismatch would clear
when the DSR state matched the motor status.  With RSMMOP equal ONE the
Mismatch holds until Ack'ed!)

RSMMOP sounded too good to be true, and for us, it was.  It only
functions the way we need it to when the MOTOR block is in two-wire
mode, (Maintained Contact Output).  In the MOTOR block the Stop contact
is only in play in the three-wire mode and(.COUT_2)is normally
OPEN/FALSE. it can be inverted to be CLOSED/TRUE within the block if it
is in the 3-wire mode, (Pulsed Contact Outputs).  In three-wire mode
.COUT_1 is ALWAYS pulsed and goes away after the pulse time regardless
of whether RSMMOP is TRUE or not and is NEVER latched by the motor run
status. =20
        It seems like it would be a trivial matter to make the .COUT_1
pulse, latch .COUT_1 whenever feedback from the motor run status is
active and drop it when the run status fails in much the same way as is
done in the field motor wiring.  If a GDEV or MOTOR block had that
option it would satisfy all of the different motor wiring schemes that
have been discussed here, without requiring another block such as Ladder
Logic, CALC, or LOGIC to intercede.  In addition, the RSMMOP option
would generate the alarm, switch the desired state to STOP, hold the
alarm until acknowledged, and allow an immediate start request to be
pulsed again without having to first tell the already stopped motor to
stop via a manual action before it could pulse the run again.  Sounds
simple and sweet to me. =20

Cheers,
Tom VandeWater

 
 
_______________________________________________________________________
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: