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