Lube Oil Header Temperature Trip

7fa unit, we are getting a trip from the lube oil header high temp logic (alarm P55). I have pulled the temp switches (26QT-1A & 1B), (26QA-1). they were spot on. also checked the analog temp element (LT-TH-1A & 1B) did not find anything wrong. So we moved to the Mark6, changed the card & cables on 1I1 card which has the alarm & one of the trip switches. The logic calls for the alarm and 1 high temp switch or both high temp switches to trip. We never see any alarm or high temp switch and the analog temp indication never wavers from 130F (alarm @ 165 trip @175) the trip has shut the unit down. the trip also comes in while the unit is not running.

Any help will be greatly appreciated

Jerry, just a little background about the information you are providing. It is difficult for us in the community to know exactly what you have in logic since there is not an easy way to share your logic file or screen shots etc. I have reviewed two 7FA MKVI controlled .m6b files I have and each is slightly different. One machine looks like what I am assuming you have, using two 26qt temperature switches and one 26qa alarm temp switch. The second unit is not using temperature switches but instead using 3 redundant thermocouples in the lube oil header. So just letting you know my comments are based on assumptions of what you have.

The alarm number you posted, P55, refers to a process alarm number. Unfortunately this alarm number will typically be different for each unit since this number is assigned by the system when it is commissioned. If you post the signal name, like L26QT_ALM there is better chance we can trace this in logic, but there are plenty of sites I have seen where the signal name is not consistent either.

So I would suggest a couple things to look at. I would set up a trend, either live or triggered and monitor all the switches, l26qt1a, l26qt1b, and l26qa. Make sure you have the trend configured to run at 40ms.

I would also suggest looking at the software configuration of each of these inputs at the card level. For digital input points it is possible to enable Sequence of Events reporting that reports at a very high rate of speed, like around the 10ms time frame. This would be very helpful in watching the status of each switch and having them report in the alarm and event report from TCI.

I would look very closely at the wiring for these switches at the junction boxes and terminal strips. Since the contacts for any of these switches should be inverted, it means that an open wire or loss of feed from circuit 107, which is the positive 125vdc feed will result in a logic 1 which is the trip.

In the logic I am looking at I noticed that the alarms L26QA_ALM and L26QT_ALM are "masked" until the unit is above speed level 14HM, but the trip is always enabled. This may be why your are not seeing alarms.

Please write back and provide any further information you may have, or if you have any other questions.

Jerry,

When did this problem start? Was a download to the Mark VI done just before this started occurring? If so, what was the nature of the download--why was a download performed? Was it because of a Control Constant change which was being made permanent? Or because of some other issue which seemed to require a "download" to resolve?

What UCVx card is being used in the Mark VI?

Can you look at the application code and see if the High L.O. Header Temp trip is blocked or permitted below 14HS? (Some units block a high L.O. Header Temp Trip below 14hs (95% speed), and others do not.)

Were any modifications to CIMPLICITY projects been performed prior to the start of this problem?

What Diagnostic Alarms are present on the Mark VI? Specifically, the UCVx and VCMI cards?

Thank you for your input. you are correct in assuming we use the L26QT_ALM & L26QT_1a & 1b switches. we did set up a trend to monitor the trip switches and alarm switch also the analog temp to verify actual temp. We did captured one temp trip sw. l26qt_1a activate (switch opened; N/C), but I was working on the S processor VCMI coax connection (powered down). I do not see how this would cause it to activate. The trend timed out at 23:23. no other activity during the night, restarted it this morning. Also on the alarm sequence history the switch will toggle back an forth 0,1,0,1.. it could be a few times other times it goes on an on for a few seconds. I will report more as we go along.

Jerryy/MIKEVI,

What about enabling the SOE change-of-state on the three switches--it logs to the Alarm Window changes of state of discrete (contact) inputs with a 1 ms degree of accuracy.

Or is the already enabled for these three switches?

My apology for the late response (I am the only tech. here w/ 2 by 1 w/HRSG`s & 3 aux. boilers & water plant) any-who. The problem started after a short outage. no programing was done to Mark VI or CIMPLICITY

UPDATE

We found <S> processor had a bad backplane, which we think may have been a factor . After changing it and powering it back up it would not communicate, then we lost all of our information on the HMI and to TOOLBOX (no updates all zero`s).

We brought some Mark VI guru's in (I'm not). They did several downloads <R>, <T> were communicating then they quit. 2 1/2 days later they found that the program was corrupted and missing some info. They rebuilt the files from some backups and finally were able to reestablish all 3 processors. Seem to have gotten this problem fixed.

Well as we were doing some tuning everything was going along fine then <R> decides to reboot (we think we had 125 vdc hard ground), so now we are trending all the voltages on each processors.

Jerry123,

Thanks for the information!