Re: [foxboro] Int30 Question

Brian,
There isn't much documentation on optimizing the gateways from 
Foxboro.  We've done a fair amount of testing in out lab and here is 
what I have seen.

As Chuck said in an earlier post, the bottleneck is almost always the 
serial communications speed.  I have never seen a gateway that was 
processor limited (although I'm sure it could be done).  Everyone 
that I have seen with problems is limited by the serial 
throughput.  As I understand it, the ABSCAN block is the only block 
that communicates directly with the PLC.  It issues read and write 
requests to the PLC and stores the data in a memory pool on the 
Gateway.  The various MCINs, CINs, AINs, etc reference the memory 
pool and do not really interface with the PLC.

Assuming you are using polled data, here is what we think is 
happening. This may be wildly inaccurate, full of myths, and 
superstitions, but it has worked for us.
(If you can find it documented, let me know.)

ABSCAN issues a read command for the data requested.
The data is placed in a PLC image memory pool on the Gateway.
*The PLC memory pool is copied to an I/A memory pool on the Gateway.
Control blocks access the data in the memory pool.
*Any writes are written back to the I/A memory pool.
*The two areas of memory are compared, and if they are different, I/A 
initiates a write to the PLC.

Repeat every period/phase in question

*(This is the easier of the two methods we think might be occurring 
to explain, the other involves any block that can write to the PLC.)

Now here's the interesting part.  A compound with nothing but writes 
will ALWAYS READ the PLC first before determining what to write.  If 
you have a compound that is full of only write type blocks AOUT, 
MCOUT, etc. but the data does not change, the communication loading 
will drop, because the gateway doesn't write the data if it is the 
same as the PLC image. Now we cannot tell if the write, writes back 
the entire memory pool of the ABSCAN block, or just the words that 
changed, but we are certain that communication loading is affected by 
the writes.

----------------------------------------------------------------------------

Reading data takes a constant amount of time.
Writing data only occurs if there is a difference to write back to the PLC.
So, If you can group items that need to write to the PLC often in a 
separate compound from ones that seldom update, and write everything 
as infrequently as possible, communication loading can be minimized.

Event driven data is different, works ok, but is very difficult to 
get a good handle on how much data will be transferred at any given 
time.  Therefore it is easy to have a gateway that appears lightly 
loaded, but overruns when a lot of activity is taking place.

This has been my experience.

Regards,
David Johnson



 
 
_______________________________________________________________________
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:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: