This has been a great thread with some very informative responses. Thanks for getting the ball rolling Tim. If I may I would like to re-iterate what I have gleaned so far and then add a few more thoughts for possible discussion. 1. External read/write from sequence code to C:B:P in the same (local) CP - No broadcast is made on the mesh/nodebus network - The request is processed locally but still may (or does?) suspend sequence block processing 2. External read/write from sequence code to C:B:P in external CP - The initial request is broadcast on the network and every other CP must process the request - After the first request the local CP retains the location and subsequent requests are directly to the target CP - Sequence block processing will suspend for at least on block period for every external read/write One thing I have always wondered about is when to use connections to Seq block I/O vs. external reads/writes from sequence code. What mechanisms are used for local vs. external (peer to peer) connections? Are there inherent advantages in speed and/or system resource efficiency in different scenarios? My assumption (and we all know what that means) is that the I/O connections are updated every BPC prior to (or after) the seq code is run , and that the code can access these values immediately and keep on running. External reads/writes require the seq code to pause at that point for at least one BPC while the request is processed (whether in the same CP or not). 1. C:B:P in local CP - Is a direct connection inherently faster and more efficient than an external read or write? i.e. Can a Seq block process much more code in a single BPC if it is working with its own I/O points vs. stopping to make external reads and writes? - Is there any implication on system resources? i.e. If you have many I/O connections but only need to look at a few during any given BPC would there be a resource savings using external reads and writes? 2. C:B:P in external CP - Does a Seq block (or any block) need to update all peer-to-peer connections every BPC or is the peer-to-peer om list mechanism change driven? - Does the peer-to-peer om mechanism update connections even if a block is inactive (or in manual)? i.e. Could you be generating a lot of unnecessary network traffic with peer-to-peer connections vs. just making external reads/writes when needed? - Is an entry in the local CPs Import Table for external read/writes retained forever or just while the specific Seq block is executing? i.e. Does the CP need to re-issue the same broadcast every time the Sequence block is toggled back to active? OK, this maybe more than I need (or want) to know, but since the subject came up.... Bottom line is we make every effort to keep all unit components and normal control functions within the same CP and keep external peer-to-peer connections to a minimum. The exceptions are when units need to request the services of other units or control modules. We generally use external read/writes to provide the necessary interface, and they are only processed while the connection to the external unit is required. I do see the delays that David described, and they do seem longer when working with a different CP, but are usually not an issue. We do have some permanent external peer-to-peer connections where necessary to provide low level interlocking, etc. I have never noticed any loading problems with our ZCP270s or experienced any network problems but then we have a very small system. Thanks again for all the great info guys. (and I know what you mean about getting confused while proof reading, David) Tom Badura Plastics Engineering Company tbadura@xxxxxxxxxx -----Original Message----- Tim, Setting .MA false and not using the If Then construct will work. Setting MA false if it is already false is ok. As for OM resources it depends on whether the COMP:BLOCK.MA is in the same CP as the sequence block. When an external read/write is initiated by the code, a check is first made to see if the C:B.P is in the local CP. If it is in the local CP then the call is not broadcast on the nodebus/mesh network and the code processes the request. If the C:B.P is not in the local CP then a broadcast is made on the network and all CPs, gateways, etc will have to search their local block databases to see if they have the requested C:B.P. This is sometimes called a "dumb" call since it does not use the peer-to-peer om list mechanism as with a secured connection between 2 CP parameters, i.e. you type in a connection to an input parameter and the source block is in another CP. So if you do a lot of external reads/writes to other CPs in sequence code you will introduce some additional OM tasks on those CPs. Another thing to note is that the sequence code will suspend one block period for each external read/write command (minimum 1 second) to resolve a call to another CP on the network. So if your sequence block period is 2 seconds and you are using the IF Then with the COMP:BLOCK.MA in another CP it will take 4 seconds to read the COMP:BLOCK.MA twice. If the sequence code does a lot of external reads/writes to other CPs and runs those steps constantly as in a loop that runs continuously you are better off making connections to the sequence block input parameters for reads and using block output parameters and peer-to-peer connections for writes. If you don't have input parameters available on the sequence block you can build a "dummy" block in the same CP as the sequence block to make the peer-to-peer connections then do reads from the sequence code to the dummy block input parameters to prevent the "dumb" calls from reaching the network. Hope this is not too confusing, I was getting a bit confused as I was proof reading this. ________________________________________ Re: :COMP:BLOCK:MA := FALSE; Our understanding is that this results in a broadcast across the system even if :COMP:BLOCK is in the same station. This is incorrect unless you are addressing a very large number of compounds outside the CP running the statement. For these calls, the CP adds the compound name to its IMPORT table. So, only the first reference to a block in that compound will result in a multicast. All subsequent accesses will go directly to the target station. That is, this reference works like omsetimp. Re: Mr. Johnsons reply indicates that if the :COMP:BLOCK is in the same station no broadcast is made and no load is put on the system outside the CP. Is my interpretation of Alexes response correct? No multicast is issued if the target compound is in the CP executing the statement. It's a local lookup. It's not particularly fast, esp. in older CPs, but it does not add load outside of the CP executing the command. _______________________________________________________________________ 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