Re: [foxboro] system error in sequences
- From: tjvandew@xxxxxxxxx
- To: foxboro@xxxxxxxxxxxxx
- Date: Wed, 25 Aug 2010 12:13:45 +0000
Dirk,
You didn't say what the error number is that you are receiving. If it is
3 then the sequence is failing while trying to write a secured variable and
this indicates it is having trouble executing the line after the one you
suspect is causing your error. AUTDSR cannot be written if either of the
following parameters are set. MANSW or AUTSW. This may not be your problem
but if the error you get is error # "3" I would be willing to bet that it is.
If it is a different error then I would agree with Gabriel. Any direct read or
write to a C:P:B pararameter from sequence code essentially causes a wait while
the sequence pauses for the response to its request. By linking to a BI or RI
parameter the sequence gets the value before it executes the code and doesn't
have to wait for a response to an OM call.
If there are other sequences that use MANSW or AUTSW or if operators
have the ability to set those parameters it could be what is causing your error
as it tries to write AUTDSR.
Either way, please let us know if/when you identify a solution.
Cheers,
Tom Vandewater
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: dirk.pauwels@xxxxxxxxxx
Sender: foxboro-bounce@xxxxxxxxxxxxx
Date: Wed, 25 Aug 2010 10:03:39
To: <foxboro@xxxxxxxxxxxxx>
Reply-To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] system error in sequences
Gents,
Question to the HLBL experts outthere...
We noticed some of our sequences (only a few of the 900+ we have)
sometimes (very, very rarely, but it does happen) go into sys_error. In
most of my sequences I've build in some exception handlers which send the
error to SN000x, so I can see which line caused the sys error. Usually it
's a line containing a C:B:P reference. It's as if the system doesn't
recognize this adress for a short period, causing a sys error, which sends
the sequence into manual mode.
I did some testing, writing a sequence which contained a non-existing
adress, and noticed the same behaviour.
I then changed the exception to manual handler to retry 3 times with a
time interval of 5 secs. This way if a sequence goes into sys error - and
therefore manual mode- on an adress temporarely unavailable (for reasons
I wouldn't know), it has time to restore itself by retrying. This has
solved this problem in most cases, but it hasn't completely cured it.
I know I'm not supposed to write any executing code in the exception to
sys error, but I think I can get away with this type of code in the
exception to manual handler wright?
This morning we noticed that a smal sequence was in manual mode after a
sys error for no apparent reason, sys error seemed to be caused by the
"IF (:PRESS_CP4:PT_HOPPERR1.PNT - :LOGIC_PRESS:R1_PRESS.RO01)......."
line. There was nothing wrong with both of the adresses by the time I
checked them. We put the sequence in auto again and it started executing
with no problem at all
the code is very basic: (could be a bit scrambled)
IF BI0001 = TRUE THEN
REPEAT
IF (:PRESS_CP4:PT_HOPPERR1.PNT -
:LOGIC_PRESS:R1_PRESS.RO01) < RI0002 AND :PRESS_CP4:PT_HOPPERR1.PNT < 5
THEN
:NITRO_R:R1_V_H60AC.AUTDSR := TRUE;
ELSE :NITRO_R:R1_V_H60AC.AUTDSR := FALSE;
ENDIF;
UNTIL :POWDER_R:FILL_HOPPER.BI0001 = TRUE OR BI0001 = FALSE;
GOTO stop;
ELSE GOTO stop;
ENDIF;
<<stop>>
:NITRO_R:R1_V_H60AC.AUTDSR := FALSE;
:POWDER_R:R1_V_071AC.AUTDSR := FALSE;
ENDSEQUENCE
I do know I'm offending some HLBL rules, like the sequence is not in the
same CP as some of the adresses it refers to and I use the C:B.P in the
code rather then using user labels. (this can very easily be corrected in
this case, but in most cases I do not have enough Reals or booleans to use
user labels), but could this be the reason for the occasional "misfire"?
If this communication "hickup"cannot be avoided what would be the
preffered workaround? Should i give it more time to retry in the exception
to manual handler?
Another strange thing is that allthough the sequence doesn't seem to
recognize the adress, there are no comm alarms, smurfed data, failed OSI
PI tags or anything of the sort. We do not have problems with other
sequences running at the same time which use C:B.P from the same CP or
compound. The problem seems to confined to the sequence (not always the
same sequence)
We're on 8.4.2 and CP270's, no overruns detected. Most sequences are at
BPCSTM 100
thanks for the help!
Dirk
_______________________________________________________________________
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:
