Re: [foxboro] Calculations IND block
- From: "Johnson, Alex (Foxboro)" <ajohnson@xxxxxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Tue, 7 May 2002 11:56:49 -0400
Re: (from Doug Lloyd) about how many local one-shot references would it take
to use up an entire BPC in a CP-60? in a CP-40?
The CP Sizing Spreadsheet is the master reference for this stuff, but as I
remember it one "generic" line of HLBL required about the same amount of
time as an AIN block.
It was not uncommon to see CP-10s having overruns when BPCSTM was set high
and the logic had nothing to cause a suspension.
Re: (from Doug Lloyd) I haven't noticed any block processor overruns because
of local one-shot references
You might not. If the code, has any thing that causes a suspension (ext ref,
wait, sendmsg/sendconf, low BPCSTM, etc), you might never notice.
However, as I mentioned above, one can do it.
Re: (from James Murphy) IMPORT table size
It is important to note that the IMPORT table holds "top level names" and
their network address.
So, what is a "top level name"?
There are two forms of OM name:
1) The triplet form of C:B.P (control blocks) or A:O.A (application objects)
2) The unary form used by Shared Variables, Program Names, and Device Names;
1AW51CDMCMD or LP01 are examples.
In the case of the triplet form, the C (or A) is stored in the IMPORT table.
This means that you can address as many block parameters as you wish in your
code within the same compound and the IMPORT table will increase only by
one.
However, in the case of the unary form, each referenced SV is stored in the
table. That means if you do a lot of SV references you could fill the table
up.
Also, it should be noted that other tasks use the IMPORT table. For example,
the address of the alarm destinations is stored in that table. That can
consume a large number of entries.
Station block - 16 names
Each compound could have 24 more different names
It's pretty easy to run out of space in the IMPORT table without even
realizing the problem might exist.
Hope this helps.
Regards,
Alex Johnson
System Products - Invensys Systems, Inc.
10707 Haddington
Houston, TX 77043
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
ajohnson@xxxxxxxxxxx <mailto:ajohnson@xxxxxxxxxxx>
Come to the Invensys Showcase: http://www.invensysshowcase.com/
<http://www.invensysshowcase.com/>
-----Original Message-----
From: MURPHY_JAMES_D@xxxxxxxxx [SMTP:MURPHY_JAMES_D@xxxxxxxxx]
Sent: Tuesday, May 07, 2002 10:29 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Calculations IND block
One other item to note: The IMPORT Table size can also
be an issue. Currently the table can hold 50
Compound/Station entries.
=======================================================
CUSTOMER ACTION REQUEST (CAR #: 1002093)
Issue : The Import Table size should be increased.
The "Import Table" in every station allows the station
to remember the mac address of an object it wants to
find again, thus avoiding a broadcast to find it.
This feature can significantly improve system
performance. In a CP, compound names in full-path-name
references are stored in this table. As FPNs are done,
the table fills. Certain applications fill the table
rapidly. The only way to clean the table is a reboot.
If the name is NOT in the import table, a statement like
WAIT UNTIL :C:B.P > 50.0;
can cause two network broadcasts per second which must
be processed by every station on the network.
If the name is in the table, this becomes two messages
sent directly to the station containing compound C.
The size of the Import Table in a CP, INT30, etc. has
not changed from 50 since the days of the CP10.
This is a request to increase the size of the table in
CP40, CP60, and future products. If there is space, the
change should also be made to CP30s, INT30s, etc.
Response:
4/9/02 - Response from SD&E (WJG)
The fix to expand the import list to 100 entrys in CP30
and later has been completed. Import table size of 100
verified.
The fix will be released with the 6.4 release.
This CAR 1002093 is closed.
CAR #: 1002093 Version : 6.2 Status : CLOSED
"Johnson, Alex (Foxboro)" <ajohnson@xxxxxxxxxxx>
Sent by: foxboro-bounce@xxxxxxxxxxxxx
05/06/02 09:37 AM
Please respond to foxboro
To: foxboro@xxxxxxxxxxxxx
cc:
Subject: Re: [foxboro] Calculations IND block
Please note, the core of Bram's answer is correct.
* External references do generate a network message
for
each such
reference
* External references to top level names that are not
in
the same
station do suspend the sequence block
I just want to point out that the traffic is not always a broadcast
message
and that not all external references suspend the block.
Regards,
Alex Johnson
System Products - Invensys Systems, Inc.
10707 Haddington
Houston, TX 77043
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
ajohnson@xxxxxxxxxxx <mailto:ajohnson@xxxxxxxxxxx>
Come to the Invensys Showcase: http://www.invensysshowcase.com/
<http://www.invensysshowcase.com/>
-----Original Message-----
From: Johnson, Alex (Foxboro)
[SMTP:ajohnson@xxxxxxxxxxx]
Sent: Monday, May 06, 2002 9:04 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Calculations
IND
block
Re: Another issue is that external references
increase
network load
because
each external reference to another CP causes a
broadcast.
Not necessarily so.
Before the OM issues a broadcast as a result of an
external
reference, it
checks the IMPORT table for the top level name in
the
external
reference
(compound name or SV name).
If the top level name is in the IMPORT table, the
associated station
address
is used to eliminate the need for a broadcast.
If the top level name is not found in the IMPORT
table, a
broadcast
is
issued. Once the station holding the target is
known, the
top leve
name is
added to the IMPORT table along with its station's
address so that
subsequent access of that top level name do not
require a
broadcast.
For those that use the OM API, the external
reference is
implemented
as a
getval() call with the IMPORT flag set.
Re: Another interesting point about Sequence Block
external
references
If the external reference is to a compound in the
same
station with
the
sequence block, the sequence block does not
suspend.
However, the
operation
is quite slow.
Regards,
Alex Johnson
System Products - Invensys Systems, Inc.
10707 Haddington
Houston, TX 77043
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
ajohnson@xxxxxxxxxxx <mailto:ajohnson@xxxxxxxxxxx>
Come to the Invensys Showcase:
http://www.invensysshowcase.com/
<http://www.invensysshowcase.com/>
-----Original Message-----
From: Marsman, Bram
[SMTP:bmarsman@xxxxxxxxxxx]
Sent: Monday, May 06,
2002 4:25
AM
To:
'foxboro@xxxxxxxxxxxxx'
Subject: Re:
[foxboro]
Calculations IND block
Hi,
The fact that you are using
include-files
has no influence
on the
time it
takes to finish your calculation.
What
you probably mean is
that you
are
using external references. (C:B.P)
Each time you assign a value in
your
sequence from a block
in
another CP via
external reference, the sequence
code
will suspend 1 period
of the
block.
So if your sequenceblock runs at 2
seconds, getting 5
variables
takes 10
seconds!
Another issue is that external
references
increase
networkload
because each
external reference to another CP
causes a
broadcast.
Especially in
the case
of continuous calculations with
multiple
values from
different CPs,
the
external reference should be
avoided.
The solution is to connect your
variables
to the RI00xx
parameters
of the
sequenceblock and use user-labels
in your
code.
Your calculation will speed up and
you
network load will
decrease.
Bram Marsman.
-----Original Message-----
From: jdesaeve@xxxxxxxxxxx
[mailto:jdesaeve@xxxxxxxxxxx]
Sent: maandag 6 mei 2002 10:56
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] Calculations IND
block
Hi,
I am writing sequence logic in IND
blocks
and using lots of
datapoints from
other stations.
Using " include files" rather than
using
direct links to
datapoints
in
other stations, it takes a lot of
time
before calucations
are done.
All blocks (for that specific
project)
have a period of 2
seconds
but
calculations are not finished at
all
during that time period
!
I would like to group all my blocks
in
one compound for that
project .
How to speed up the calculations ?
Regards,
Jef Desaever
Du Pont Protein Technologies
Zwaanhofweg 1
8900 Ieper-Belgium
_______________________________________________________________________
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
_______________________________________________________________________
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:
