Re: [foxboro] Sequencecode and block behaviour

Hi Andreas,

first of all, there is no such thing as a "the best" solution.

Secondly, you have to address the overrun issue first.
What I found on one of the systems I inherited some time ago was that the
number of statements per BPC for all sequence code was left at the default
100. During the start up phase 10 years ago there was this incredible number
of overruns on all stations with a significant number of SEQ blocks.
The engineering solution back then was to slow down the SEQ blocks by
dropping the scan time and they went as far as 10sec. scan time with
appropriate phasing. This didn't solve the overrun problem at all. It only
made the process behave exceptionally sluggish. The reaction of production
people was that the newly installed Foxboro was a heap of excrement.(very PC
and not the language they used) 
I've made a bit of a study on this problem.

Assuming that there is no I/O in the 100 statements the station will try to
run the 100 statements in the seq block in the 0.5 sec station scan time
every 10 seconds. If time is up before it finished the 100 statements it
will generate an overrun. This will also happen with small (say under 10
statements) SEQ blocks that are running with an indefinite WHILE (TRUE) DO
loop and no WAIT statement or I/O somewhere in the loop.

That might be the problem you have.

A solution to this is to reduce the number of statements per BPC and at the
same time make the block scan time faster which will solve two issues in one
hit.

Setting the block scan time to 1 second and the statements per BPC to 10 or
even 5 will make the block process lots faster and at the same time
eliminate the overrun issue. The CP is able to process this small number of
statements, no sweat.
Give it small bites it can chew more often!!!

On SEQ code with the WHILE (TRUE) DO loop structure, put a "WAIT 0.1;" just
before the ENDWHILE which will force the block to loop only once per process
period.

You know that it is perfectly okay to connect a point to itself with a
default value?
Like in a sequence block, 'ACTIVE' could be connected like
:BLOCKNAME.ACTIVE.1
This will make it a secure connection fixed to 1. No one can turn it off.

Anyway, enough of my ramblings.
I hope you solve the overrun problem soon.

Regards,
Frits Schouten.
BHP-NZSteel.

-----Original Message-----
From: Weiss, Andreas [mailto:Andreas.Weiss@xxxxxxxxx]
Sent: Wednesday, 14 May 2003 20:39
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] Sequencecode and block behaviour



Hi List,

sometimes do I run into problems with my sequencecode.

The Independent-Block goes into manuell mode due to the fact that =
another C:B.P isn't reachable (OM-overruns).

What is the "best" solution?

The best would be, to buy a faster Control Processor but what can I do =
up to that time.

a) Build an observer-Block who checks the ::IND.MA state and puts the =
IND-Block regularly into automatic mode

b) Link the ::IND.MA to the ::IND.ACTIVE parameter


Solution a) is realized at this time but I think that it costs =
unnecessarily Control Processor power.


Regards,

Andreas
 
 
_______________________________________________________________________
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
 

EOM 

NOTICE - This message and any attached files may contain information that is
confidential and/or subject of legal privilege intended only for use by the
intended recipient. If you are not the intended recipient or the person
responsible for delivering the message to the intended recipient, be advised
that you have received this message in error and that any dissemination,
copying or use of this message or attachment is strictly forbidden, as is
the disclosure of the information therein.  If you have received this
message in error please notify the sender immediately and delete the
message.


 
 
_______________________________________________________________________
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: