Re: [foxboro] GDEV configuration
- From: "Joseph M. Riccardi" <Joe@xxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Fri, 18 May 2012 13:23:34 -0400
Tim,
I see Doug chimed in on the DSR_RB parameter which is what you will want to
connect to the final command to the MCC if you want mismatch alarming. So
the question is are you even bringing this signal back into the control
system. Ditto for feedback from the hand switch (HOA?) if it is not in the
Auto position. The GDEV should know that it is not in control so it can
track the hand switch (HOA?).
DSR_RB
Desired State Request Readback is a boolean input. When connected to a
downstream block, DSR_RB provides the desired state feedback. This feedback
prevents false mismatch alarms when other conditions, not controlled
by the GDEV block, also determine the On/Off state of the device. For
example, when using ladder logic Ñ that is, a Programmable Logic Block (PLB)
Ñ between the GDEV block outputs (COUT_1 and COUT_2) and a motor starter
relay, connect DSR_RB to the output of the ladder logic. The GDEV block
detects this connection and compares the limit switch inputs to DSR_RB to
detect a device state mismatch. In this case, DSR_RB indicates the true
desired state of the motor, which can differ from the desired state
indicated by DSRIND. If a signal is not connected to DSR_RB, the GDEV block
compares the limit switch inputs to the desired state request to detect
state mismatches. If DSR_RB is true, the desired state feedback is Open/Run.
If DSR_RB is false, the desired state feedback is Close/Stop.
Joseph M. Riccardi
386-441-0250 Office
386-451-7607 Cell
Joe@xxxxxxxxxxxxx
"To give real service you must add something that cannot be bought or
measured with money; and that is sincerity and integrity." - Donald A. Adams
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Lowell, Timothy
Sent: Friday, May 18, 2012 12:38 PM
To: 'foxboro@xxxxxxxxxxxxx'
Subject: Re: [foxboro] GDEV configuration
Joseph,
There is a hand switch between the GDEV and the MCC. I'm sorry if I didn't
make that clear. What do you typically do in this situation? It looks like I
have some other ideas from Rick and Corey.
Thanks all,
Tim Lowell
Tesoro Corporation | 54741 Tesoro Rd, Kenai, AK 99611 | 907-776-3526 (work)
| 210-439-5914 (cell)
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Joseph M. Riccardi
Sent: Friday, May 18, 2012 8:38 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] GDEV configuration
Tim,
"All of the #2s should not be connected or set to the opposite condition."
Could you elaborate on this statement? What do you mean by #2's?
Oops, I meant 1s; DEVLM1, IGNLM1, AVLLM1. The GDEV is also used for Valves
where you may have 2 limit switches (DEVLM1 & 2) as open/closed feedback.
As long as there is no other device between the GDEV and the MCC that could
bypass the GDEV command, nothing else should be required to get what you
want.
Joseph M. Riccardi
386-441-0250 Office
386-451-7607 Cell
Joe@xxxxxxxxxxxxx
"To give real service you must add something that cannot be bought or
measured with money; and that is sincerity and integrity." - Donald A. Adams
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Lowell, Timothy
Sent: Friday, May 18, 2012 12:21 PM
To: 'foxboro@xxxxxxxxxxxxx'
Subject: Re: [foxboro] GDEV configuration
Joseph,
Thanks for the reply.
"All of the #2s should not be connected or set to the opposite condition."
Could you elaborate on this statement? What do you mean by #2's?
The device between the GDEV and the MCC is an Eaton C441 Monitoring Relay.
Basically, you connect it to a switch that is also connected to the FDSI
FBM, and it can monitor the device statuses and turn things on and off. It's
pretty simple with no logic solver in it.
Thanks,
Tim Lowell
Tesoro Corporation | 54741 Tesoro Rd, Kenai, AK 99611 | 907-776-3526 (work)
| 210-439-5914 (cell)
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Joseph M. Riccardi
Sent: Friday, May 18, 2012 8:12 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] GDEV configuration
Tim,
You have lots of options but the basic connection for the motor Run feedback
is DEVLM2. DEVLM2 Device Limit Switch 2 is a boolean input for reading the
Opened/Running limit switch. When DEVLM2 is true, the device is
Opened/Running.
Make sure it is not ignored; IGNLM2 = 0. And it is configured as available;
AVLLM2 = 1.
All of the #2s should not be connected or set to the opposite condition.
The big question is, do you have anything between the GDEV and the MCC;
i.e., a PLC, HOA, etc.
Joseph M. Riccardi
386-441-0250 Office
386-451-7607 Cell
Joe@xxxxxxxxxxxxx
"To give real service you must add something that cannot be bought or
measured with money; and that is sincerity and integrity." - Donald A. Adams
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Lowell, Timothy
Sent: Friday, May 18, 2012 11:33 AM
To: 'foxboro@xxxxxxxxxxxxx'
Subject: [foxboro] GDEV configuration
List,
This one should be easy for the list. We are upgrading our Motor Control
Centers, and we have some fancy new MCC buckets that can talk over Ethernet
to an FDSI block. Someone decided it would be a good idea to allow the board
operator to turn the pumps and exchanger fin fan motors on and off from the
DCS, as well as being able to operate them locally as they always had done
in the past. Previously, if we needed a pump or fin fan motor started, the
only option was to send an operator out to do it. In most cases, we didn't
even have feedback status for the pump or fin fan motor, but now we do.
Since this project was run by an Electrical Engineer who can barely spell
I/A, he didn't put much consideration into the graphics or DCS configuration
until very late in the game, and he ended up farming the job out to Invensys
at the last minute. The Invensys engineer he hired was already on site
helping us with a cutover, and he had to throw something together in his
"spare" time. He did a very thorough and complete job with the information
he was given and with the time constraints he had, but unfortunately, he had
to leave and go to another job, and now what we have isn't quite right.
The Invensys Engineer used GDEV blocks on the graphic to start and stop the
field devices. What we are seeing is that the feedback from the status bits
is not configured correctly. The GDEV currently does not know what the
status of the device is. If you call up the Detail Display of one of the
GDEV blocks, it is in whatever position it was left at by the graphic, even
if someone has started or stopped the device locally with a field switch.
My question is, how do you properly configure a GDEV for ON/OFF status
feedback? There are all these options, and the block book is not
particularly helpful in deciphering which to use or not use. We basically
want the GDEV block to know what the status of its device is, so that when
we click on the device, it knows whether to prompt us to start it if it is
off, or to stop it if it is on. Right now, the GDEV is assuming that
whatever the last command we sent to it is the status of the device, which
isn't necessarily true. The device status comes back to the DCS via the
first bit of an FDSI PAKIN block, but I haven't had any luck figuring out
which parameter on the GDEV to connect it to. There is only a RUNNING bit,
and no OFF bit; that is, you can only tell the device is OFF if the RUNNING
bit is zero.
If I could get Invensys to work on this, I would, but it's not easy
traveling to Alaska, and I think this should be an easy fix.
Thanks,
Tim Lowell
Tesoro Corporation | 54741 Tesoro Rd, Kenai, AK 99611 | 907-776-3526 (work)
| 210-439-5914 (cell)
_______________________________________________________________________
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:
