Re: [foxboro] GDEV configuration
- From: Dirk Pauwels <dirk.pauwels@xxxxxxxxxx>
- To: "foxboro@xxxxxxxxxxxxx" <foxboro@xxxxxxxxxxxxx>
- Date: Mon, 21 May 2012 08:33:12 +0000
Tim,
We use gdev's all the time, for valves (devlm1 and 2) and for motors(devlm2
only)
Sounds like you need to get feedback from the local motor control to show
status correctly, aside from the motor feedback and GDEV.
We have a large number of pumps that have both GDEV control and local manual
switch control, and running feedback, but without feedback from the local
control switch, like you for the moment I guess.
We handle this by using STAIND. Each status gets a color
1 is stopped (grey)
2 is running (green)
3 is travelling close (yellow)
4 is travelling open (yellow)
Everything > 5 is mismatch
But motor opened by local control will result in staind 6 (motor running, GDEV
desired state is 0), so you could make 6 a blinking green, to indicate to the
operator motor (possibly )running on local control.
Rgds,
Dirk
>
> -----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
Other related posts:
