Re: [foxboro] HLBL question
- From: "Douglas G. Lloyd" <doug@xxxxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Fri, 22 Jan 2010 12:53:16 -0500
Hi All,
Just a quick tidbit which I think I've previously mentioned on the list:
Data written to sequence block parameters from inside the same sequence
block are NOT available to downstream blocks until the next BPC. Strange,
but true (last confirmed a few years ago on a CP60). So, if you've got a
need for tightly synchronized data to be passed from block to block in a
single CP execution phase, don't use sequence blocks (i.e. CALC family
blocks running an equivalent algorithm don't have this issue).
Regards,
Doug
DGL Controls
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Badura, Tom
Sent: Friday, January 22, 2010 12:27 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] HLBL question
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
Other related posts:
