Re: [foxboro] GDEV configuration
- From: "Lowell, Timothy" <Timothy.Lowell@xxxxxxxxxxx>
- To: "foxboro@xxxxxxxxxxxxx" <foxboro@xxxxxxxxxxxxx>
- Date: Fri, 18 May 2012 13:18:15 -0500
The HOA status is not available to the DCS.
The GDEV actually uses COUT_1 to start the device (connected to one BOUT block)
and COUT_2 to stop it (connected at a different BOUT).
I am in contact with the Invensys engineer who built this. Thanks to all for
your replies.
Tim Lowell
Tesoro | 210-439-5914 (cell)
On May 18, 2012, at 10:06 AM, "Rick Mol" <Rick.mol@xxxxxxxxxxxxxxx> wrote:
> Tim,
>
> It sounds like you have a good handle on the basic config, the rest of this
> discussion is about handling field starts and alarming.
>
> The NOT Auto switch refers to the state of the field HOA switch if that is
> brought into the DCS. (sometimes the Auto contact is brought into the DCS).
> It may be available via the link or may be a discrete input.
>
> The suggestion was to use that signal, if available, to inhibit alarming
> (along with INHOPT) on field start.
>
> It depends on how the HOA switch control is setup, can the DCS stop the
> motor after a field start or not. If so, use of the DSR_RB is a better way
> to go, otherwise the operators may want to know that the motor is in hand
> and running from the field.
>
>
> Regards,
> Rick Mol
> Coyote Technologies
> 231.750.6348
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
> Behalf Of Lowell, Timothy
> Sent: Friday, May 18, 2012 12:18 PM
> To: 'foxboro@xxxxxxxxxxxxx'
> Subject: Re: [foxboro] GDEV configuration
>
> Doug et al,
>
> Let me see if I understand what you all are saying.
>
> The actual driving block is a BOUT on the FDSI. You are saying that DSR_RB
> should be connected to its output (.BOUT, I think).
>
> DEVLM2 should be the feedback from .B1 of the device PAKIN block.
>
> AVLIM2 = 1 tells the GDEV to use DEVLM2.
>
> Does that sound right?
>
> I'm still not clear what to do about the hand switch. These GDEVs are locked
> in Manual. Nothing should be starting or stopping the device but a board
> operator using the GDEV on a graphic or an outside operator using the
> outside hand switch. Using AUTDSR therefore is not an option, if I am
> reading the block book correctly. Rick said something about the NOT Auto
> switch. I'm not sure what that means.
>
> 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 Douglas G. Lloyd
> Sent: Friday, May 18, 2012 9:05 AM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] GDEV configuration
>
> Tim,
>
> The DSR_RB parameter should be connected to whatever final signal you have
> available that is actually driving the device. Limit switch checking is
> based on the DSR_RB status if it is connected. Otherwise, it's based on the
> DSRIND (i.e. the block drive request from AUTDSR, MANDSR, INTDSR, HLDDSR,
> etc). The detail display colors need some interpretation if DSR_RB is
> different than DSRIND, but it's not too tough once your operators understand
> the patterns...
>
> If you have no status connection available from whatever is actually driving
> the device, you'll lose limit switch versus output verifications. But, you
> can still configure the block to display the actual status (i.e. connect
> DSR_RB to the actual device state)...
>
> Regards,
> Doug
>
> -----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
>
_______________________________________________________________________
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:
