Re: [foxboro] Operator interface question
- From: Corey R Clingo <clingoc@xxxxxxxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Wed, 29 May 2002 10:06:36 -0500
Our I/O Scan load is 150-200% of BPC. I changed the BPC to 0.5 (from 1.0)
on the advice of this list, in order to have more phases to work with, and
phased out the scanning, but it didn't help. Interestingly, before we
changed the BPC, the I/O load was still in the 150-200% range. We have 5
PLCs, 370-odd blocks in the gateway, but are scanning well under the 350
bytes/sec the specs claim is possible for an Integrator 30.
We also tried setting the baud rate to 19.2K (from 9600), but scan load did
not change, and we got intermittent failures on one - only one - of the 5
PLCs on the highway.
And a couple new twists appeared during our recent shutdown. Displays
gathering data from the gateway were intermittently smurfing for no
apparent reason. Even the station block smurfed about half of the times we
called it up. Naturally, nothing showed up in system management (PLEASE,
Foxboro, make that a more useful tool. It's such a pain to wait 15-30
seconds for that to call up only to find nothing of value in it). We
finally discovered that one of our AWs had some "ghost" connections to it
(40, to be exact). Rebooting the AW cleared it up.
The next day, we had several of the values from one of the PLCs just quit
updating. Not smurfed, ABSCAN blocks show good, but data does not change.
RSLinx data monitor clearly showed the data to be changing. After a lot of
trial and error, we finally turn off all the compounds getting data from
that PLC, reload the ECB15, and turn them back on. Seems to have fixed it.
Needless to say, these took up several hours of precious shutdown time.
I guess I am used to my Honeywell days, where you configured the PLC
gateway and forgot it. It ran and ran. When you had a problem, the
diagnostics told you (and came up in less than 5 seconds to boot). I
complained because the point-building interface was that of their
older-generation system, rather than something more current, but I'd gladly
take that now.
Corey Clingo
Sr. Engineer
BASF Corp.
|---------+---------------------------->
| | Brian Long |
| | <blong@xxxxxxx> |
| | Sent by: |
| | foxboro-bounce@fr|
| | eelists.org |
| | |
| | |
| | 05/16/2002 09:09 |
| | AM |
| | Please respond to|
| | foxboro |
| | |
|---------+---------------------------->
>-------------------------------------------------------------------------------------------------------------------------------|
|
|
|
|
|o
|
| To: foxboro
|
|
|
|
|
|
|
| cc:
|
| Subject: Re: [foxboro] Operator
interface question |
>-------------------------------------------------------------------------------------------------------------------------------|
What kind of thruput problems are you having? Some of the issues I've had
I
been able to clean up.
Brian Long
Green Bay Packaging
Arkansas Kraft Division
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx]On Behalf Of Corey R Clingo
Sent: Wednesday, May 15, 2002 5:38 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Operator interface question
If the PLC logic is overwriting the value you are
incrementing/decrementing, then nothing will happen; the PLC ladder will do
this much faster than the I/A can. But if the PLC logic is only reading
the value you are incrementing/decrementing, it should work as expected.
We have some gateway analog outputs like this, and the ramp keys do work,
but it can sometimes take a long time to see the results of your actions.
However, we do have throughput problems on our gateways, which I have not
been able to get to the bottom of yet. If your gateway throughput is good,
it should work.
Corey Clingo
Sr. Engineer
BASF Corp.
stan <stanb@xxxxxxxx>@freelists.org on 05/14/2002 09:41:47 AM
Please respond to foxboro@xxxxxxxxxxxxx
Sent by: foxboro-bounce@xxxxxxxxxxxxx
To: foxboro
cc:
Subject: Re: [foxboro] Operator interface question
On Tue, May 14, 2002 at 08:43:44AM -0500, Corey R Clingo wrote:
>
>
> One characteristic of most DCS PLC gateways is that the output values are
> silently read back behind the scenes so the operator is able to see
exactly
> what is in that PLC. This causes confusion sometimes (i.e., when
operator
> actions have no effect because the PLC logic obliterated their change),
but
> is a reflection of the real world, and helps in situations like this. I
> believe the Integrator 30 at least behaves in this manner.
>
I think I'm begning to gat a picture of how this should work.
However I still have a rather basic question. How can I read a value from
the PLC, and increment/decrement this value to write it back? If the AIN in
the gateway is in auto, I can't change the value in the DCS, right? If
instead, i make a copy, modify it, and write that back to the PLC, which
then detects the new data, and sends it back to the AIN, that I am
modifying, don't I have a timing race?
--
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety."
-- Benjamin Franklin
_______________________________________________________________________
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:
