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