Re: [foxboro] GDEV freezing problem

 Rick,

A 'two pence' worth ..
I have not seen this as a problem.  However, I can say that the load_all
procedure for initialising blocks is not a "normal" operation for a live
plant and will at times show a different block initialisation to that of
rebooting a CP (still it shouldn't lockup for sure).  This difference comes
down to the fact that no checkpoint file references exist for the loaded
compound when they initially burst into life.  And so at the point of the
block first scan the block input parameters, if not available from I/O or
peer-peer lists,  will come from the only known source "the loadall" not a
checkpointfile.  Was the MANSW=1 in the workfile (load_all)? etc

The only good point of all this is that the initialisation path experienced
by the load_all will never be repeated once a checkpoint file exists and the
CP for example reboots.


Regards,

Justin Fletcher
Solutions Architect


Invensys Process Systems UK Limited, Manor Royal, Crawley, W Sussex, RH10
2SJ
E-Mail:  justin.fletcher@xxxxxxxxxxxxxxxx
Tel:    +44 (0)1293 526000 (switchboard)  ext 472
Fax:    +44 (0)1293 408461



-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Rick Rys
Sent: Tuesday, December 14, 2004 6:33 PM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] GDEV freezing problem


List:

I have a GDEV block with the following configuration:

MA=3D         :XVMYGDEV.MA.1
MANSW=3D      : 0
AUTSW=3D      :PATTERN:APP_MCIN.CIN_11

The intent is for the GDEV to be locked in ATUO mode.  The AUTSW = parameter
was merely used to store a Boolean in order to use a single overlay for
multiple valves.  There are a number of other GDEV configuration details
that may or may not be relevant.

After a recent LOADALL, and more recently for no apparent reason, a = large
number of GDEV blocks with similar configuration went into a frozen = MANUAL
state.  When the blocks were in this state the output was frozen and the
block could not be switched back to Auto nor could the output be = adjusted
via the MANDSR that you would expect to function in Manual.  Delete and
Undelete reinstalls the block and block function returns to normal, i.e.
returns to AUTO mode etc.  The MANSW would override the MA =3D 1, but no =
known application was setting it, and besides, the block outputs where
frozen.
They previously operated for 2 years without a problem and no =
configuration changes were intentionally made.

I suggested:
ADD CMPND:BOOL_0_1 (or something similar)
STEP01 =3D SET BO01     ;SOLID 1 USED FOR ALL GDEV MA
STEP02 =3D CLR BO02     ;SOLID 0 USED FOR ALL GDEV MANSW
END

And configure:
MA=3D         CMPND:BOOL_0_1:BO01
MANSW=3D      CMPND:BOOL_0_1:BO02
AUTSW=3D      PATTERN:APP_MCIN.CIN_11

As we don't understand why, or if, the original configuration caused the
GDEV to go into a "locked up" state, it is not clear that these changes =
will be effective.  Anyone seen a similar problem?

Thanks,

Rick Rys P.E.
www.R2Controls.com
508-369-5186 Cell
508-339-6633 Home Office
=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
 
 
 
_______________________________________________________________________
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: