Re: [foxboro] CPU loading Accuracy in STATION block (was CP Load )
- From: "Wetton, Richard J" <WettonRJ@xxxxxxxxxx>
- To: "'foxboro@xxxxxxxxxxxxx'" <foxboro@xxxxxxxxxxxxx>
- Date: Mon, 30 Jun 2003 08:54:21 +1000
Alex,
Thanks for the reply. Sorry, I meant divide, (shorter DT). I tried this on
a couple of different CP40B's and got the same result, so I didn't expect
any overruns to show in both cases. (with DTIME blocks).
Richard Wetton.....
-----Original Message-----
From: Johnson, Alex (Foxboro) [mailto:ajohnson@xxxxxxxxxxx]
Sent: Friday, 27 June 2003 11:53 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] CPU loading Accuracy in STATION block (was CP
Load )
Hmmm...
I should have rechecked the documentation on the ACCUM:
PCNTOP
Pulse Count Option is a short integer. The four values are used to adjust
the block algorithm to different types of measurement input as follows
0 = Pulse rate per block period
1 = Pulse count per block period
2 = Pulse rate per minute.
3 = Pulse count per minute
Sigh...
Anyway, it might still apply to the DTIME block.
Regards,
Alex Johnson
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77043
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
ajohnson@xxxxxxxxxxx
For the latest information on ArchestrA, go to
www.invensys.com/Archestra.html.
-----Original Message-----
From: Johnson, Alex (Foxboro) [mailto:ajohnson@xxxxxxxxxxx]
Sent: Friday, June 27, 2003 7:17 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] CPU loading Accuracy in STATION block (was CP
Load )
I'm a little confused by your comment. In one spot, you shorten the DT to
get it right. Later, you say you lengthen it.
One possible source of errors in the ACCUM block probably applies to the DT
block too.
If the CP overruns, the ACCUM block does not accumulate during the "missed"
BPC, i.e., the algorithm is based on block executions not the actual clock.
Thus, each CP overrun makes the ACCUM skip an addition. You can see it by
setting the block to run every 0.5s, set the measurement to a fixed value
(say 1), start it up, and induce overruns.
Regards,
Alex Johnson
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77043
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
ajohnson@xxxxxxxxxxx
For the latest information on ArchestrA, go to
www.invensys.com/Archestra.html.
-----Original Message-----
From: Wetton, Richard J [mailto:WettonRJ@xxxxxxxxxx]
Sent: Thursday, June 26, 2003 10:18 PM
To: 'foxboro@xxxxxxxxxxxxx'
Subject: Re: [foxboro] CPU loading Accuracy in STATION block (was CP
Load )
Alex,
While talking about clock errors, could this have anything to do with DTIME
blocks not timing very well over large dead times?
E.G. Using a DTIME block to collect average data, over 240 minutes I would
normally set the DT to 240. However, to get an actual dead time of 240 I
have to enter 228 as the DT. (about 5% error) I now set the DT to (DT *
1.0526) when using large deadtimes.
Richard Wetton.....
-----Original Message-----
From: Johnson, Alex (Foxboro) [mailto:ajohnson@xxxxxxxxxxx]
Sent: Thursday, 26 June 2003 8:26 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] CPU loading Accuracy in STATION block (was CP
Load )
Two different issues, Corey.
The clock isn't wobbling. It's just that the granularity on loading
measurements is the granularity of the clock. We can't tell if the machine
is busy for those 20ms or idle hence the error.
The clock runs on schedule, the BPCs are predictable, but the STATION block
cannot see how full a 20ms interval is.
In 500ms system, a 20ms interval is only 4% error, but it is 10% of a 200ms
interval and that is a big difference.
Make sense?
Alex Johnson
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77043
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
ajohnson@xxxxxxxxxxx
For the latest information on ArchestrA, go to
www.invensys.com/Archestra.html.
-----Original Message-----
From: Corey R Clingo [mailto:clingoc@xxxxxxxxxxxxx]
Sent: Wednesday, June 25, 2003 2:04 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] CPU loading Accuracy in STATION block (was CP
Load )
Yes, but it raises an interesting point: does control block processing also
have a 20 ms jitter (20%) when the BPC is 0.1 s? Or is the control timing
done by a different mechanism?
Corey Clingo
BASF Corp.
|---------+---------------------------->
| | "Johnson, Alex |
| | (Foxboro)" |
| | <ajohnson@Foxboro|
| | .com> |
| | Sent by: |
| | foxboro-bounce@fr|
| | eelists.org |
| | |
| | |
| | 06/25/2003 12:23 |
| | PM |
| | Please respond to|
| | foxboro |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------
---------------------------------------------------|
|
|
| To: foxboro
|
| cc:
|
| Subject: Re: [foxboro] CPU loading Accuracy in STATION block (was
CP Load ) |
>---------------------------------------------------------------------------
---------------------------------------------------|
All,
I have learned from a highly placed source inside the company that due to
the resolution of the real-time clock (20 ms), the accuracy of each loading
calculation is as follows:
BPC Max. Error Usefulness
0.1 s 20.0 % not very
0.2 s 10.0 % marginal
0.5 s 4.0 % OK
1.0 s 2.0 % OK
2.0 s 1.0 % OK
Thus, it is not that the STATION block does not work at faster BPCs, but
that the measurement accuracy degrades substantially when the BPC is less
than 0.5s (500ms).
Does this make sense?
Regards
Alex Johnson
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77043
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
ajohnson@xxxxxxxxxxx
For the latest information on ArchestrA, go to
www.invensys.com/Archestra.html.
_______________________________________________________________________
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:
