[foxboro] Sequence Block Exceptions

Hi to all sequence hacking programmers reading this great list,

Sascha wrote:
> After that, it gave an error but since it was forced=20
> to AUTO and ACTIVE it directly tried again.

NEVER EVER force sequence blocks to AUTO and ACTIVE to deal with =
operational
errors. Use properly configured Standard Block Exception Handlers =
instead.
Read B0400DF Chapter "Useful Hints on SBX Programming" and following =
for
more information or visit a qualified HLBL training course to learn =
more
about this.=20

This is important. Wrong configured sequence programs can really cause
problems in your CPs.

Best regards -

Marcel Sieling
Systems Technologies

Invensys Systems GmbH
Emanuel-Leutze-Str. 11
40547 Duesseldorf
Germany
Tel.:      +49-211-5966-302
Fax:      +49-163-99-5966302=20
Mobile:  +49-163-5966302
Email: mailto:marcel.sieling@xxxxxxxxxxxxxxxx
Homepage: http://www.foxboro-deutschland.de


> -----Urspr=FCngliche Nachricht-----
> Von: foxboro-bounce@xxxxxxxxxxxxx=20
> [mailto:foxboro-bounce@xxxxxxxxxxxxx] Im Auftrag von Sascha Wildner
> Gesendet: Donnerstag, 18. November 2004 15:38
> An: foxboro@xxxxxxxxxxxxx
> Betreff: Re: [foxboro] Setting Application Objects from IND blocks
>=20
>=20
> Johnson, Alex (Foxboro) wrote:
>=20
> > 2) The BPCSTM parameter will limit the number of statements per =
BPC.
>=20
> Well, a coworker and I had an argument about this a while=20
> ago, so we did=20
> some tests. Just for the record: It seemed to me that the BPCSTM=20
> parameter - despite its name - rather limits statements per=20
> period. If I=20
> remember correctly it was on a CP with a BPC of 0.1 sec. But it could =

> well be that we misinterpreted our results.
>=20
> > 4) External references like yours (:A:O.A :=3D 2) will suspend the=20
> > block's execution.
>=20
> Not only the execution of the block containing the reference,=20
> it seems.=20
> In a project I recently did there was a typo in an external=20
> reference.=20
> This causes the IND block to pause until searching for the=20
> reference had=20
> timed out. After that, it gave an error but since it was=20
> forced to AUTO=20
> and ACTIVE it directly tried again. So far, so good. The, um,=20
> "interesting" side effect was: This typo not only caused the=20
> IND block=20
> containing it to pause until timeout, but rather _ALL_ IND blocks=20
> running in that CP stopped resolving external references=20
> until the time=20
> out of the misspelled one was over. This decreased performance of our =

> sequence blocks dramatically and it took us a while until we=20
> figured it=20
> out. We even exchanged the CP before. :|
>=20
> --=20
> Gru=DF,
>=20
> Sascha Wildner
> erpicon Software Development GmbH
> Neusser Str. 724-726
> 50737 K=F6ln
> Germany
>=20
> Phone: +49 221 9746069
> Fax:   +49 221 9746099
> eMail: swildner@xxxxxxxxxx
>=20
> =20
> =20
> ______________________________________________________________
> _________
> This mailing list is neither sponsored nor endorsed by=20
> Invensys Process Systems (formerly The Foxboro Company). Use=20
> the info you obtain here at your own risks. Read=20
> http://www.thecassandraproject.org/disclaimer.html
> =20
> foxboro=20
> mailing list:             http://www.freelists.org/list/foxboro
> to subscribe:        =20
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
> to=20
> unsubscribe:      =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
> =20
>=20
 
 
_______________________________________________________________________
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: