[foxboro] Secured Linkages

Hi,

Doug wrote:
> Also, a related interesting tidbit ... if two stations try to=20
> write to the same unsecured parameter in a third station at=20
> the same instant, it is possible to see a similar Op Error. =20
> Apparently, writes to unsecured parameters temporarily secure=20
> the parameter, write the value, then un-secure it.  Just FYI=20
> in case anyone has experienced intermittent, tough to=20
> reproduce Op Error 3s.

That's the reason, why in the BLOCK_EXCEPTION TO_SYS_ERROR a precise
differentiation should take place what to do on which OP_ERR. A clever
routine increments an error counter on OP_ERR 3's and retries =
afterwards.
Only after three tries you should quit and generate an error message. =
Of
course you have to take care to properly reset that counter after the =
error
and make it accessible to all routines in the Sequence block (e.g. make =
it a
global variable) and initialise it properly on sequence starts.

Block Exceptioning can save lives, if you do it properly. ;-)

Best regards -

Marcel Sieling
Systems Technologies

Invensys Systems GmbH
Heerdter Lohweg 53 - 55
40549 Duesseldorf
Germany
Tel.:  +49 (0)211 5966-171
Fax:  +49-(0)172-50-2673077
Mobile:  +49-(0)172-2673077
Email: msieling@xxxxxxxxxxx=20
Homepage: http://www.invensys-process-systems.de=20
Visit my private (german) homepage: http://www.powerslider.de=20

Wir m=F6chten auf unsere Veranstaltung hinweisen:=20
Invensys PLS 80E Anwender Symposium 14. und 15. Oktober 2003
in Stuttgart, Kurhaus Bad Cannstatt
http://www.foxboro-deutschland.de/pls80e-as2003/index.htm


> -----Urspr=FCngliche Nachricht-----
> Von: Douglas G. Lloyd [mailto:DGLControls@xxxxxxxxxxx]=20
> Gesendet: Samstag, 13. September 2003 20:35
> An: foxboro@xxxxxxxxxxxxx
> Betreff: Re: [foxboro] Secured Linkages
>=20
>=20
> Chuck,
>=20
> Not to nitpick, but the SPT parameter isn't always unsecured=20
> even if nothing is connected to it.  If the block is in=20
> remote setpoint mode, the SPT parameter becomes a secured=20
> output.  HLBL writing to the SPT of a block in remote will=20
> generate Op Errors (3, I think).
>=20
> Also, a related interesting tidbit ... if two stations try to=20
> write to the same unsecured parameter in a third station at=20
> the same instant, it is possible to see a similar Op Error. =20
> Apparently, writes to unsecured parameters temporarily secure=20
> the parameter, write the value, then un-secure it.  Just FYI=20
> in case anyone has experienced intermittent, tough to=20
> reproduce Op Error 3s.
>=20
> Regards,
>=20
> Doug Lloyd
> DGL Controls
>=20
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx=20
> [mailto:foxboro-bounce@xxxxxxxxxxxxx]On
> Behalf Of Jones, Charles R. (Chuck)
> Sent: Saturday, September 13, 2003 11:55 AM
> To: 'foxboro@xxxxxxxxxxxxx'
> Subject: Re: [foxboro] Secured Linkages
>=20
> To quote from B0193AW - Rev.F (Integrated Control Software=20
> Concepts) page
> 35:
> "If the parameter has an established linkage, it is=20
> automatically secured. If there is no linkage (connection),=20
> it is available to all users until someone secures it."
>=20
> In the ICC, when a  block input parameter has nothing written=20
> in it (no linkage), the parameter may have values written to=20
> it while it is running (from Display Manager, FoxView, or=20
> from custom-made programs). This condition is "unsecured". =20
> If, in the ICC, there is a linkage (connection) written into=20
> a block input parameter, then the only values that may be=20
> written to that parameter come in via the link (usually to an=20
> output parameter of another block)  This condition is=20
> "secured".  HLBL code written to change a secured parameter=20
> will surely fail.  (Trust me, I know. ;) Typical examples=20
> taken from a PID block:
>  - A PID.MEAS parameter is linked to an AIN.PNT parameter. =20
> Nothing else may write a value to PID.MEAS except the AIN=20
> block.  This PID.MEAS parameter is secured.
>  - A PID.SPT parameter is left unlinked.  Since there is no=20
> linkage, the operators my change the setpoint via a display=20
> that is designed for them to do so.  (Or, I could write HLBL=20
> code in an DEP block that would change this
> value.)  This PID.SPT parameter is unsecured.
>=20
> When you have dbvu report the blocks with secured linkages=20
> (Is that the '-l'
> option?) I suppose it prints out a list of blocks that are=20
> linked to other blocks.  Does it also show the linkages? =20
> I've never tried it.  I usually use dbvu to resolve CP=20
> overruns using '-s' option (to find heavily used
> phases) and '-u' option (to find unresolved linkages that=20
> cause linkages to timeout).
>=20
>=20
> Chuck Jones
> Refinery Automation Technologist
> Tate & Lyle North America -- Lafayette South Plant
> 765.477.5324 - Office  | 877.536.9219 - Pager
>=20
>=20
>=20
> -----Original Message-----
> From: Ajay.Tathgir@xxxxxxx [mailto:Ajay.Tathgir@xxxxxxx]
> Sent: Saturday, September 13, 2003 1:34 AM
> To: foxboro@xxxxxxxxxxxxx
> Subject: [foxboro] Secured Linkages
>=20
>=20
> Hi! All
>=20
> When we run a dbvu on a checkpoint file, it gives a list of=20
> blocks with secured linkages.
>=20
> My query - what is secured linkage & what does it mean ?
>=20
>=20
> Thanks & Regards
>=20
> Ajay Tathgir
>=20
> Reliance Industries Limited
> Mumbai - India
>=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: