Dear Everyone,

Our site is a GE 6FA 1x1 with a GE Fitchburg Steam Turbine. The CT uses a DLN 2.0 combustion system. We use a MKV and HMI for controls and interface.

We have had 4 separate runs this summer. The first 2 were successful with little issues. The latter 2 have both resulted in a very similar trip during shutdown for L30SPT High Exhaust Temperature Spread Trip. In the trip alarm summary from our recent trip it appears we received an L30SPA Combustion Trouble alarm 6 seconds prior to the Trip. We have examined the usual things including gas valves, IGVs, fuel pressure, thermocouples and flame detectors and have yet come up short. The SMEs we have submitted our trends and trip summaries to from the previous trip to this one seem to agree the cause was a flameout. I suspect the SMEs upon investigation of this trip will say the same. As yet the root cause has not been identified.

Below is a link to a drop box with the alarm summaries from the MKV HMI. Also below are screenshots of the trip timestamp and a few trends from the trip. If someone could look over this data and offer any advice it would be very much appreciated. Also if any further data may be helpful please request and I will try to obtain as needed.

https://secure.eu.internxt.com/sh/f...49cc0a42de7c7e3e7695477d6ae23031d41721da536ea

 

I haven't been at a computer to look at the compressed data file, but it's very difficult for me to make out what's happening from the charts. They're pretty and all, but they lack and scaling information and without the ability to scroll through the data it's hard to understand what's going on--at least with the exhaust T/Cs.

You say this happened during a shutdown. Was this a normal, operator-initiated STOP where the machine was unloaded automatically by the Mark* V? Or, was an operator slowly lowering load, stopping to pause occasionally? From the bottom chart it looks like the DWATT signal had dropped then for some reason it started decreasing slowly, then started increasing then leveled off for some reason right before the trip. It also looks like several of the exhaust T/Cs decreased temperature fairly quickly and that may have been because of a loss of flame for some reason in one or more combustors.

The combustion monitor function has been covered before on Control.com, many times. It doesn't just look for high differential between exhaust T/Cs it also looks for the adjacency of the signals that have a high differential. It sorts the exhaust T/Cs by magnitude (value) AND by number, and then looks at both the magnitude and the location of the differentials. You can see this by looking at the L30SPA and L30SPT rungs and the combustion monitor algorithm. (It looks difficult, but it really isn't--it just takes some time to see what is being done. The two sorts (magnitude and location) are arrays and the values of the arrays can be observed and even recorded; see the names in the combustion monitor algorithm. Again; it's all been covered before.)

But it's really completely unclear what's happening in the first pretty graph; it doesn't look like any unloading is occuring, just probably the "normal" bobble of Pre-Selected Load Control, and then the trip occurs and DWATT drops like a rock. In the second pretty graph without any scaling it's even more difficult to understand what's happening. How was the unit being shut down? By selecting STOP? Or by an operator clicking on LOWER frequently, or by clicking on LOWER once or thrice and then pausing for some (what?) period of time before clicking on LOWER again?

It's possible that the "pausing" during a combustion mode transfer caused some kind of issue which lead to the loss of flame in one or more combustors which didn't have a flame detector (seems unlikely since 6FAs only have six combustors--but it's possible). It could be a problem with one of the gas valves sticking--but one would think there would be some kind of Diagnostic Alarm to indicate a problem with the LVDT feedback (valve position) not following the reference.

But, what's really strange to me, in the bottom pretty graph, is that the load decreased, then started increasing again and then leveled off before the trip occurred.

If the data comes from some data archival and retrieval system like PI it's not really fast enough to see what's happening. If you have GE WorkstationST HMIs you should have access to Trend Recorder--that is the best way to capture and analyze data. It can even be configured to trigger on some event (like L30SPA) and capture one or two minutes of data BEFORE the trigger as well as some amount of time post trigger. It's an extremely powerful--and rarely used--tool. For high-speed data captures it's the best tool available (from GE).

If you want more assistance please describe HOW the machine was being shutdown, and try to provide data with some means of scaling (if you provide it in pretty graphical format)--but it would be better (for me) to have the data in csv or xlsx format from the graph (often times the data from a graph can be exported to csv or xlsx format--with timestamps--and then we can see "more" of what's happening). But, if the data comes from PI and if PI gets the data at once-per-second or if the data points being trended have some kind of "range" during which the trend line doesn't move then the data for this kind of troubleshooting is pretty useless. (I once was given data from a newly installed PI-based GE Historian where the speed signal TNH wouldn't display the value unless it went past 110% speed (3300 RPM for a 50 Hz machine) so from zero speed to rated speed the speed line was at 0%, and this was the GE factory configuration. Closer examination revealed many signals with extremely "wide" windows.... Brilliant. NOT.)

Anyway, again, I have't been able to download the compressed file to try to have a look. (Can you please tell us what was the source of the information in the compressed file? The GE Mark* HMI (possibly a WorkstationST HMI?)? Or some other historical data archival and retrieval system? Do you know what the data capture rate of the system is and how it gets the data from the GE Mark* V HMI (MODBUS or GSM or ???)?

Better data; possibly better help.

 

I haven't been at a computer to look at the compressed data file, but it's very difficult for me to make out what's happening from the charts. They're pretty and all, but they lack and scaling information and without the ability to scroll through the data it's hard to understand what's going on--at least with the exhaust T/Cs.

Apologies. I failed to grab the scale. See better pretty pictures below. I enhanced the resolution a bit also..

What other variables would you suggest viewing the moment of the trip?





You say this happened during a shutdown. Was this a normal, operator-initiated STOP where the machine was unloaded automatically by the Mark* V? Or, was an operator slowly lowering load, stopping to pause occasionally? From the bottom chart it looks like the DWATT signal had dropped then for some reason it started decreasing slowly, then started increasing then leveled off for some reason right before the trip. It also looks like several of the exhaust T/Cs decreased temperature fairly quickly and that may have been because of a loss of flame for some reason in one or more combustors.

This happened during a normal shutdown where the combustion turbine (under normal circumstances) unloaded from base load to a pre-select load of 5MW while other shutdown functions are performed, steam turbine, etc.

The combustion monitor function has been covered before on Control.com, many times. It doesn't just look for high differential between exhaust T/Cs it also looks for the adjacency of the signals that have a high differential. It sorts the exhaust T/Cs by magnitude (value) AND by number, and then looks at both the magnitude and the location of the differentials. You can see this by looking at the L30SPA and L30SPT rungs and the combustion monitor algorithm. (It looks difficult, but it really isn't--it just takes some time to see what is being done. The two sorts (magnitude and location) are arrays and the values of the arrays can be observed and even recorded; see the names in the combustion monitor algorithm. Again; it's all been covered before.)

But it's really completely unclear what's happening in the first pretty graph; it doesn't look like any unloading is occuring, just probably the "normal" bobble of Pre-Selected Load Control, and then the trip occurs and DWATT drops like a rock. In the second pretty graph without any scaling it's even more difficult to understand what's happening. How was the unit being shut down? By selecting STOP? Or by an operator clicking on LOWER frequently, or by clicking on LOWER once or thrice and then pausing for some (what?) period of time before clicking on LOWER again?

The CT is taken from base load to preselect 5MW during the controlled shutdown. Below is another pretty graph with the 3 spreads..



Also another including, TTRF, IGV reference and feedback..



It's possible that the "pausing" during a combustion mode transfer caused some kind of issue which lead to the loss of flame in one or more combustors which didn't have a flame detector (seems unlikely since 6FAs only have six combustors--but it's possible). It could be a problem with one of the gas valves sticking--but one would think there would be some kind of Diagnostic Alarm to indicate a problem with the LVDT feedback (valve position) not following the reference.

Sticking valves has been tossed around. Wouldn't this be apparent during other times in the run besides shutdown? The gas valves have been stroked offline while monitoring servo currents and feedback and nothing indicating an issue was observed.

But, what's really strange to me, in the bottom pretty graph, is that the load decreased, then started increasing again and then leveled off before the trip occurred.

Agreed. What other variables would you suggest analyzing during this timeframe?

If the data comes from some data archival and retrieval system like PI it's not really fast enough to see what's happening. If you have GE WorkstationST HMIs you should have access to Trend Recorder--that is the best way to capture and analyze data. It can even be configured to trigger on some event (like L30SPA) and capture one or two minutes of data BEFORE the trigger as well as some amount of time post trigger. It's an extremely powerful--and rarely used--tool. For high-speed data captures it's the best tool available (from GE).

Agreed. On our next run we will run the trend recorder. We should have done this on this occasion but we failed. The data in the drop box is the Unfiltered Alarm History and the Summary (digitals) from the HMI in spreadsheet format.

If you want more assistance please describe HOW the machine was being shutdown, and try to provide data with some means of scaling (if you provide it in pretty graphical format)--but it would be better (for me) to have the data in csv or xlsx format from the graph (often times the data from a graph can be exported to csv or xlsx format--with timestamps--and then we can see "more" of what's happening). But, if the data comes from PI and if PI gets the data at once-per-second or if the data points being trended have some kind of "range" during which the trend line doesn't move then the data for this kind of troubleshooting is pretty useless. (I once was given data from a newly installed PI-based GE Historian where the speed signal TNH wouldn't display the value unless it went past 110% speed (3300 RPM for a 50 Hz machine) so from zero speed to rated speed the speed line was at 0%, and this was the GE factory configuration. Closer examination revealed many signals with extremely "wide" windows.... Brilliant. NOT.)

PI export..

https://share.eu.internxt.com/sh/fo...4b8e13b6719304f592a18da788d8645d4b1ece29c1c7f

Anyway, again, I have't been able to download the compressed file to try to have a look. (Can you please tell us what was the source of the information in the compressed file? The GE Mark* HMI (possibly a WorkstationST HMI?)? Or some other historical data archival and retrieval system? Do you know what the data capture rate of the system is and how it gets the data from the GE Mark* V HMI (MODBUS or GSM or ???)?

The data in the drop box is the Unfiltered Alarm History and the Summary (digitals) from the HMI in spreadsheet format.

Better data; possibly better help.

Thank you for your assistance. Please ask more questions or request more data...

 

Copied and pasted from my first response….

What was the source of the information in the compressed file? The GE Mark* HMI (possibly a WorkstationST HMI?)?
Or some other historical data archival and retrieval system? [Perhaps a PI Historian provided by GE?]

Do you know what the data capture rate of the system is and how it gets the data from the GE Mark* V HMI (MODBUS or GSM or [PDH]???)?

Was this a normal, operator-initiated STOP where the machine was unloaded automatically by the Mark* V? Or, was an operator slowly lowering load, stopping to pause occasionally? [Possibly pausing at a combustion mode transfer point?]

Please describe HOW the machine was being shutdown, and try to provide data with some means of scaling (if you provide it in pretty graphical format)--but it would be better (for me) to have the data in csv or xlsx format from the graph (often times the data from a graph can be exported to csv or xlsx format--with timestamps--and then we can see "more" of what's happening).

 

Copied and pasted from my first response….

What was the source of the information in the compressed file? The GE Mark* HMI (possibly a WorkstationST HMI?)?
Or some other historical data archival and retrieval system? [Perhaps a PI Historian provided by GE?]

Do you know what the data capture rate of the system is and how it gets the data from the GE Mark* V HMI (MODBUS or GSM or [PDH]???)?

Was this a normal, operator-initiated STOP where the machine was unloaded automatically by the Mark* V? Or, was an operator slowly lowering load, stopping to pause occasionally? [Possibly pausing at a combustion mode transfer point?]

Please describe HOW the machine was being shutdown, and try to provide data with some means of scaling (if you provide it in pretty graphical format)--but it would be better (for me) to have the data in csv or xlsx format from the graph (often times the data from a graph can be exported to csv or xlsx format--with timestamps--and then we can see "more" of what's happening).

See my initial response.

As to the MKV data capture rate, I am not certain how that is configured in the MKV HMI. I can look at this tomorrow and try to determine the rate. Not everything observed in the MKV HMI Alarm History/Summary is available in PI. The PI data comes via Modbus from the MKV HMI to a DCS then on to PI.

 

This is not what GE classified as a shutdown. A shutdown is when the operator clicks on STOP and affirms the selection and the Mark* V starts reducing TNR which will reduce load, opening the generator breaker on reverse power and the then goes into a fired shutdown reducing fuel to reduce speed, finally shutting off the fuel and coasting down to COOLDOWN. What happened here was the operator put in a Pre-Selected Load Reference of 5 MW and the Mark* V unloaded the machine (by reducing TNR) until the load reached approximately 5 MW and then what probably happens is the load drops to 4 MW and the Mark* V increases the load; sometimes it bounces around between 4 & 5 MW. What you described is the site’s shutdown routine, not what GE considers a shutdown. (Sorry to be a stickler about this, and thank you for explaining your shutdown procedure—but if you’re talking to GE you need to either explain your shutdown procedure in better detail or use GE’s words and terms, I’m just saying….)

I’ve seen many sticking valves—and IGVs—that worked very well when stroking them off-line when there was no pressure—or air flow—but START the machine again and they don’t work well at all. The problem is usually a mechanical problem with the valve or the actuator (including a broken spring) or a problem with the servo (caused by dirty oil). But, again there is usually a Diagnostic Alarm about a disagreement between the reference and the LVDT feedback (position)—and that’s not in your alarm snippet.
It seems you have a WorkstationST HMI; does that mean you have none of those Mark* V Life Extension things where replace Mark* V cards with Mark* VIe-compatible cards? (Not that it makes a difference; I’m just curious.)

I hope to get some time in the next couple of days to open the compressed file to look at the contents. But I am still thinking flame was lost in one or more fuel nozzles in one combustor (probably one without a flame detector). If the same exhaust T/Cs decreased in temperature prior to both trips then you should be able to use a swirl angle chart or app to troubleshoot the problem. If you don’t have either, I would start by looking at the fuel nozzles in one of the combustors without a flame detector that is about half way around the machine from the cold spot. But, based on the information I have been able to look at it doesn’t appear to be a problem with the Mark* V. The data may prove otherwise when I can review it.

Was there any maintenance done on the machine in the past couple of months? Fuel nozzle replacement? Combustor cap replacement?

Was an off-line water wash performed in the last couple of months?

Again, is there a combustion mode transfer around 5 MW during unloading? If so, what mode to what mode?

Is there a possible problem with gas fuel supply pressure or flow at approximately 5 MW? The snippets you have sent does show the load dropped and then increased before it stabilized just prior to the trip. Could a gas fuel supply problem coupled with a combustion mode change be causing this? If there’s a gas compressor on the site does the gas compressor shut down around 5 MW or so, in conjunction with a combustion mode change? (Gas fuel supply issues can cause problems for DLN combustion systems at low loads. I was at one site that had to increase the gas fuel supply pressure by almost 20 psig to get through the combustion mode transfer just before FSNL. A similar situation could occur during unloading when there’s a combustion mode change.)

That’s all I got for now.

 

I’ve seen many sticking valves—and IGVs—that worked very well when stroking them off-line when there was no pressure—or air flow—but START the machine again and they don’t work well at all. The problem is usually a mechanical problem with the valve or the actuator (including a broken spring) or a problem with the servo (caused by dirty oil). But, again there is usually a Diagnostic Alarm about a disagreement between the reference and the LVDT feedback (position)—and that’s not in your alarm snippet.
It seems you have a WorkstationST HMI; does that mean you have none of those Mark* V Life Extension things where replace Mark* V cards with Mark* VIe-compatible cards? (Not that it makes a difference; I’m just curious.)

Just had a conversation with one of the lifers on site who witnessed a period way back yon when hydraulic oil varnishing was plaguing the unit. From his recollection the symptoms he witnessed were generally issues with sticking valves during valve checkout prior to start and/or during starts. That said, he said the sticking valve issues sometimes did and sometimes did not manifest while the hydraulic oil varnishing challenges were ongoing. He did not remember issues with sticking valves during the site's shutdown.

The HMI could very well be correctly referred to as a "WorkstationST HMI". I've heard ours referred to simply as HMI or Cimplicity HMI. The electronic Operator & Application manuals we have for the HMI are GEH-6126A Vols 1 & II.

I am not familiar with "Life Extension things where Mark* V cards with Mark* VIe-compatible cards". I have only ever replaced MKV cards with like kind MKV cards. I wouldn't think we would be able to retrofit a next generation MK card into our current chassis, that is if I take your statement in that meaning.

I hope to get some time in the next couple of days to open the compressed file to look at the contents. But I am still thinking flame was lost in one or more fuel nozzles in one combustor (probably one without a flame detector). If the same exhaust T/Cs decreased in temperature prior to both trips then you should be able to use a swirl angle chart or app to troubleshoot the problem. If you don’t have either, I would start by looking at the fuel nozzles in one of the combustors without a flame detector that is about half way around the machine from the cold spot. But, based on the information I have been able to look at it doesn’t appear to be a problem with the Mark* V. The data may prove otherwise when I can review it.

We have a Swirl Chart App. Unfortunately I'm not sure how to use it or if it would be usable with our machine as it does not have

Was there any maintenance done on the machine in the past couple of months? Fuel nozzle replacement? Combustor cap replacement?

A Combustion Inspection was performed in Fall 2022. Nothing in the past couple of months.

Was an off-line water wash performed in the last couple of months?

The last off-line water wash was directly following the Fall 2022 CI.

Again, is there a combustion mode transfer around 5 MW during unloading? If so, what mode to what mode?

Trends from previous successful shutdowns show transfer to lean-lean around 15.5MW through flame out.

Is there a possible problem with gas fuel supply pressure or flow at approximately 5 MW? The snippets you have sent does show the load dropped and then increased before it stabilized just prior to the trip. Could a gas fuel supply problem coupled with a combustion mode change be causing this? If there’s a gas compressor on the site does the gas compressor shut down around 5 MW or so, in conjunction with a combustion mode change? (Gas fuel supply issues can cause problems for DLN combustion systems at low loads. I was at one site that had to increase the gas fuel supply pressure by almost 20 psig to get through the combustion mode transfer just before FSNL. A similar situation could occur during unloading when there’s a combustion mode change.)

No gas fuel compressor on site.

There has been no indication of fuel gas pressure anomalies. It is a good suggestion however. Will add to the item watch list for next shutdown.

That’s all I got for now.

 

Okay; I'm reviewing the two files in the compressed folder. And, I have one question that is unrelated to the trip (sort of).

I'm NOT judging anyone; I'm just trying to understand somelthing.

Why do operators and supervisors tolerate dithering alarms (L71QL_ALM, for example; and a HOST of steam turbine-related alarms which MUST occur during EVERY steam turbine start-up and shutdown)--because of poor programming and configuration practices which can be fixed?

Dithering alarms and nuisance, erroneous alarms just fill the alarm history with garbage making it difficult, near impossible, to quickly and easily review the alarm history. The ALARM LOCK/UNLOCK feature would prevent a LOT of this (not so much the steam turbine-related alarms--because that's the result of NOT using hysteresis/deadband on signals which annunciate "alarm" conditions (many of which normally occur during operation, particularly start-up and shutdown). In addition to making it nigh impossible to review alarm histories in a timely fashion it makes operators, and their management, numb to just about every alarm--until they hear the compressor bleed valves open and see the MW drop to zero, and maybe hear some steam safeties popping off.

I think I know why, actually; and it's a sad rationalization--the saddest. Because commissioning personnel, who are inexperienced and harried during commissioning and initial plant operation, tell everyone, "Oh--that's normal!" Just because these alarms happen on every turbine DOES NOT MEAN they are normal. Alarms should alert an operator to a dangerous or worrisome condition--not just waste printer paper and fill screens and alarm history queues. IT IS NOT NORMAL; IT IS BECAUSE OF POOR PROGRAMMING PRACTICES AND PURE LAZINESS.

This one thing is most everything that's wrong with GE turbine controls. How are operators supposed to determine what's real and what's not with this number of alarms? (Okay; the lack of documentation and procedures is also pretty bad, but this, this is fixable.)

Anyway, these dithering alarms (L71QL_ALM, for example) can be fixed, or locked out to prevent nuisance alarms--and if it's the result of low L.O. level add some damn L.O., or fix the friggin' switch. In the case of the steam turbine alarms, get someone in who can properly configure the CSP to add some hysteresis/deadband to these abominable steam turbine "alarms"; it won't take that long and it would certainly help the operators and technicians. Yes; we know that during every start-up and shutdown the steam bowl metal temperatures are going to change. It's when they DON'T CHANGE that the operators need to know that, or when they are truly outside of operating parameters. Change the alarm setpoint(s) and/or add some hysteresis. A LOT of these "alarms" are the result of how digital analog signals change by 1 or 2 deg F when stationary and because there's no deadband/hysteresis (to say the value must change by even 3 or 4 deg F before the alarm clears). It's unconscionable, and one reason why GE has lost so much stature in the turbine business. People will continue to buy the equipment--but they detest it, from an operational standpoint. AND the commissioning personnel--and the factory programmers (who should know better!)--are immune to the problems and the complaints, because no site refuses to accept such a mess of programming which would force some review and fixes, simple fixes!

Okay. But, I still want to know why sites put up with this? For decades.

Seriously.

It's NOT NORMAL. A proper control system should only alert on true alarm conditions; if the alarm setpoints are incorrect or there needs to be some deadband/hysteresis added to the logic, then do it. But to KEEP tolerating this is the definition of insanity--which is: Doing the same thing over and over again and expecting different results. (EXACTLY like electing the same people for decades and hoping they will implement real solutions and change.)

We now return to our regularly scheduled programming.

 

Okay; I'm reviewing the two files in the compressed folder. And, I have one question that is unrelated to the trip (sort of).

I'm NOT judging anyone; I'm just trying to understand somelthing.

Why do operators and supervisors tolerate dithering alarms (L71QL_ALM, for example; and a HOST of steam turbine-related alarms which MUST occur during EVERY steam turbine start-up and shutdown)--because of poor programming and configuration practices which can be fixed?

L71QL_ALM actually isn't a nuisance alarm, unfortunately.

The others related to ST have been tolerated for years. I own it.

Dithering alarms and nuisance, erroneous alarms just fill the alarm history with garbage making it difficult, near impossible, to quickly and easily review the alarm history. The ALARM LOCK/UNLOCK feature would prevent a LOT of this (not so much the steam turbine-related alarms--because that's the result of NOT using hysteresis/deadband on signals which annunciate "alarm" conditions (many of which normally occur during operation, particularly start-up and shutdown). In addition to making it nigh impossible to review alarm histories in a timely fashion it makes operators, and their management, numb to just about every alarm--until they hear the compressor bleed valves open and see the MW drop to zero, and maybe hear some steam safeties popping off.

Agreed. I have much work to do.

I think I know why, actually; and it's a sad rationalization--the saddest. Because commissioning personnel, who are inexperienced and harried during commissioning and initial plant operation, tell everyone, "Oh--that's normal!" Just because these alarms happen on every turbine DOES NOT MEAN they are normal. Alarms should alert an operator to a dangerous or worrisome condition--not just waste printer paper and fill screens and alarm history queues. IT IS NOT NORMAL; IT IS BECAUSE OF POOR PROGRAMMING PRACTICES AND PURE LAZINESS.

This one thing is most everything that's wrong with GE turbine controls. How are operators supposed to determine what's real and what's not with this number of alarms? (Okay; the lack of documentation and procedures is also pretty bad, but this, this is fixable.)

Anyway, these dithering alarms (L71QL_ALM, for example) can be fixed, or locked out to prevent nuisance alarms--and if it's the result of low L.O. level add some damn L.O., or fix the friggin' switch. In the case of the steam turbine alarms, get someone in who can properly configure the CSP to add some hysteresis/deadband to these abominable steam turbine "alarms"; it won't take that long and it would certainly help the operators and technicians. Yes; we know that during every start-up and shutdown the steam bowl metal temperatures are going to change. It's when they DON'T CHANGE that the operators need to know that, or when they are truly outside of operating parameters. Change the alarm setpoint(s) and/or add some hysteresis. A LOT of these "alarms" are the result of how digital analog signals change by 1 or 2 deg F when stationary and because there's no deadband/hysteresis (to say the value must change by even 3 or 4 deg F before the alarm clears). It's unconscionable, and one reason why GE has lost so much stature in the turbine business. People will continue to buy the equipment--but they detest it, from an operational standpoint. AND the commissioning personnel--and the factory programmers (who should know better!)--are immune to the problems and the complaints, because no site refuses to accept such a mess of programming which would force some review and fixes, simple fixes!

Adding LO obviously is the correct answer. Unfortunately factors outside of my control with the site make this difficult if not impossible at this particular moment in time. It certainly is an issue on the radar.

I don't have the history on the issue of site nuisance alarms, unfortunately. I'm not going to blame anyone (although at this time it belongs to me) and while you are correct, again this is likely an issue that our site is not going to invest in at this particular moment in time due to factors outside of my control. Site control upgrades are in our future and this nonsense will certainly be reviewed to correct going forward.

Okay. But, I still want to know why sites put up with this? For decades.

Seriously.

It's NOT NORMAL. A proper control system should only alert on true alarm conditions; if the alarm setpoints are incorrect or there needs to be some deadband/hysteresis added to the logic, then do it. But to KEEP tolerating this is the definition of insanity--which is: Doing the same thing over and over again and expecting different results. (EXACTLY like electing the same people for decades and hoping they will implement real solutions and change.)

Agreed. This site can and will tighten up.

We now return to our regularly scheduled programming.