If you wouldn't mind sharing the files in the following directories (folders) from the F: drive on an HMI:

F:\ [the root directory of F: drive]
F:\CONFIG
F:\UNIT1
F:\UNIT1\PROM

Sometimes there is an F:\DATA folder; it's usually either empty or full of data files created using the VIEW tools or other executables on the <I>. There shouldn't be anything of interest in that folder for this problem.

Also, sometimes, people put data files in F:\UNIT1 which swells the size of that folder greatly. If you can weed out files you KNOW are not configuration files (configuration ("unit-specific" files include CSP segment files; IO.ASG; UNITDATA.DAT; MSTR_SEQ.CFG; SEQ*.SRC; *.ASG; etc.).

One thing you haven't mentioned is other comm's, specifically MODBUS. Is there some external system communicating with the <I>s and the Mark* Vs?

How many Mark* V's does the TMOS HMI communicate with? How many Mark* V's are on the StageLink? With the TMOS HMI?

Is the TMOS HMI still disconnected?

 

Thank you for confirming the Vote ID. That was a long shot at being your problem, but it's easy to confirm.

Now you need to find the commonality of you voter mismatches in <T>. For example; Are they all digitals? Do they all go back to IO that lands on the DTBB?

The Mk V is called triple modular redundant, but its not really. I have a single switch in the field that comes back to the DTBB in <QD1>, so how do the three cores vote on it? The DTBB has three 50 pin ribbon cables; JRR, JRS, and JRT. As their names imply on carries the single field switch to <R>, on to <S>, and one to <T>. There are very few things in a Mk V that have three field devices. P2 pressure on a 7FA is actually three field pressure transmitters. So why does <T> voter mismatch on hypothetically all digital associated on hypothetically a single DTBB terminal board, probably because the ribbon cable JRT is lifted on either the DTBB or the TCDA in location 5.

I'll attach a sample case wiring diagram to help with this but you can also use Appendix D of GEH6195, the Signal Flow Diagram.

Next why are some in voter mismatch when the unit is off and others are in mismatch when the unit is on? This is a bit trickier. Suppose a signal in normally a 0 when the unit is running, but 1 when the unit is not running. Well if the unit is on all three cores would see a 0 and the vote would be correct (but for all the wrong reasons). <T> would see a 0 because of a lifted ribbon cable, <R> and <S> would see a 0 because of the field device.

This gets even trickier when you know that many things on a Mk V are wired or programmed in a fail safe manner, for example oil pumps and compartment blowers. Some of those things come on with a 0 signal. This inversion can be accomplish by selecting normally open or normally closed contact states in a field device, or they can be inverted in the IO Configurator. There is a software inverion selection in IOCFG called "Inv Mask", or Contact Mask Inversion.

Knowing the states of devices when the unit is running or not, how they are wired or programmed, and how the Mk gets all of those IO signals to its cores will lead back to an answer as to why you have so many voter mismatches.

Back to my previous statement that you have multiple problems cascading into unit trips. With <T> in voter mismatch already, then you lost <S>, well your two bad cores are now in agreement and your good core is voted out. You may have fixed <S> but now you need to fix <T> because on the next hiccup your two bad cores are going to have the vote again.

 

Here's part of the problem right here:



On the top-most row you can see <C> is saying that L4 in <T> is in disagreement with the other processors. As read downwards you can see that the three control processors <R>, <S> & <T> are saying that there is a disagreement with the two ETR (Emergency Trip Relays on the TCTG in Loc. 4 of <P>)--which is correct, <R> & <S>disagree with <T> and <T> disagrees with <R> & <S>. So, something is telling <T> the turbine should be tripped and <R> and <S> are saying the turbine should not be tripped. As you continue scrolling down you will see that PTR2 (Primary Trip Relay #2--probably the one for heavy fuel oil) is also in disagreement between all the control processors (probably because the machine was running on heavy fuel at the time).

ON the fourth and fifth photos (on 13 Aug) there are a LOT of discrete (contact) input voting mismatches, in addition to some analog signal voting mismatches. One of the possible indicators is that L4T1 in <T> is not in agreement with the other control processors, but without being able to see what the rung for L4T1 includes we can't make an educated guess. At least ONE of the discrete (contact) input voting mismatches, L86TGT, is almost always a trip--but NOT ALWAYS. One HAS to look at the L4 logic/rungs in the CSP to know for sure. L45FTX1 is often a trip signal, as well. To @White's point about one input being "fanned out" to all three control processors it's not ALL the discrete (contact) inputs to <T>, just a group--and if we had the IO.ASG file we could try to narrow it down to one or the other JRT cable.

There are also a LOT of power supply problems.... I think it's VERY possible that <T> also has some oxidized and/or corroded ribbon cable pins/sockets, AND as @White says one or more of the ribbon cables between either the DTBA (in Loc. 6) and/or the DTBB (in Loc. 7) of <QD1> are not fully seated or the ribbon cable connectors have been separated over time when replacing cards in <QD1> or the pins/sockets of the ribbon cables he mentioned are oxidized/corroded. I HIGHLY recommend obtaining some NyoGel 760G and cleaning EVERY ribbon cable and ribbon cable receptacle on every card and applying a thin film of the conductive grease. It certainly cannot hurt--especially since it seems to have helped tremendously with the problem of <S> randomly rebooting, and it might even help with the power supply alarms, too. It seems the measured power supply voltages are all within reasonable limits/ranges but for some reason the LCC and/or DCC is not reading them properly--and they would have to come via ribbon cables, right?

The Trip History/Trip Display doesn't, unfortunately, keep track of every Diagnostic Alarm--which might be very helpful in theis case. It appears the site does not acknowledge and reset Diagnostic Alarms prior to every start, which might also be helpful. The Mark* V (as has been said before on Control.com) is a HUGE alarm generator, with hundreds of possible Process Alarms and thousands of possible Diagnostic Alarms. I know operators believe dealing with alarms is below their pay grade and are someone else's responsibility--but operators see the alarms first (they should also HEAR them first--but that doesn't happen very often these days; operators don't like to be bothered with audible alarm indications even more than just acknowledging and resetting alarms before they issue a START). AND, they don't want to roll their chair out of the way--or, heaven forbid, get up out of the chair so--so someone else can have a look at what's happening or happened. Operators seem to be able to believe (because they have been allowed to believe) that all they have to do is click on START & EXECUTE and STOP & EXECUTE and change load (using Pre-Selected Load Control) and any alarms or issues that come up are either the I&C (Instrumentation & Control) or the Mechanical Departments problems. I KNOW (VERY WELL!) that most Mark* turbine control systems spit out tens or even hundreds of alarms a day. And so operators, and even their supervisors, just get to the point that they ignore alarms--until the unit trips, and then all hell breaks loose. And most operators can't even tell WHAT the alarm was that tripped the machine (often because there are SO MANY alarms on the display that are erroneous or haven't been reset), and when someone tells them they argue--without ANY actionable data to back up their position. Sad the way things have changed; that didn't use to be possible in a power plant control room.

EVERY ALARM MEANS SOMETHING. Full Stop. Period. If the same alarm keeps popping up on every start (like Cooling Water Fans Failed seems to be pretty common in some of the alarm lists...!) then the I&C and Mechanical Departments need to find out why (if they don't already know) and FIX THE PROBLEM so erroneous or nuisance alarms stop. This goes for Diagnostic Alarms, too. As has been pointed out: A single Diagnostic Alarm won't trip the machine, but there are combinations of Diagnostic Alarms that WILL result in a machine trip. So, the same attention should always be paid to Diagnostic Alarms. If someone needs help understanding Diagnostic Alarm messages, ask for help/guidance here. IT IS POSSIBLE TO START AND LOAD A MACHINE TO BASE LOAD, OPERATE, AND SHUT IT DOWN AND GO ON COOLDOWN WITHOUT ANY ALARMS--PROCESS OR DIAGNOSTIC!!! It's not easy, but really, working on the alarms one at a time it can be done--and has been done.

The Mark* V was designed and programmed to avoid the kind of problem @White is referring to--with one processor thinking the turbine should be tripped because of, say, low-low L.O. pressure, and another processor thinking the turbine should be tripped because of IGV position trouble. If the Mark* V is well maintained and in a proper environment that should NEVER happen because of SIFT (Software-Implemented Fault Tolerance). When there's a disagreement Diagnostic Alarms are annunciated to alert conscious operators and their supervisors of a problem--but the processor with the disagreement will use the voted value of signals (EVERY control processor votes using every other control processor's values). The ONLY time I've ever seen the ETRs or the PTRs for a particular fuel shut-off valve be in disagreement is when there's a problem with the communication cables to the TCEA and/or the TCTG or a problem with either the TCEA or the TCTG card(s). Two control processors can think or believe the machine should be tripped for two different reasons--but they should be using voted values and annunciating the voting mismatches BUT NOT trying to trip the machine by dropping out their PTR or ETR. Yes, there is two-out-of-three voting using the PTRs and ETRs, but the signals driving them should be the same because of SIFT.

I've seen individual TCEA cards think there's a problem with speed inputs to <P> and drop out the ETRs, but that was a rare case and solved by replacing the PTBA. There were ETRn voting mismatch Diagnostic Alarms and speed input voting mismatch Diagnostic Alarms, and a check of the ETRs on the TCTG found the ones related to one of the TCEA cards were, in fact, dropped out. We replaced the TCTG and that didn't solve the problem; we replaced the TCEA and that didn't solve the problem. And when replaced the PTBA that solved the problem.

Which makes me wonder because two signals, SVL and SFL2 are both in voting mismatch on the fourth Diagnostic Alarm photo, and the PTs from both the generator and the bus are connected to the PTBA and pass through the TCEB to the TCEAs.

There's just too many strange things happening here, and we already know that cleaning up the cable connections in <S> solved one very big part of the problem. And, why would that happen ONLY in one processor when every core (module) in the Mark* V uses ribbon cables. And, <S> is at the top of the panel on the left side of the panel; <T> is directly below it. And, <QD1> is at the bottom of the panel, and <P> is directly above it. There are components associated with <T> in <P> AND <QD1>. There are problems in multiple parts of the Mark* V panel--but they could all be related to the same condition.

By the way, is the TMOS HMI reconnected?

 

Agreed. My last post was a hypothetical common problem causing the mismatch.

In the case of L4, that is the output of other logic. Why is <T> not in agreement with <S> and <R> on L4?
Below example (not necessarily this unit in question) L4 requires L4S before it will latch itself in;


So why isn't L4S "master protective set" picking up? Bad speed detection perhaps?

Why do we also have mismatches on L4ETR1 and L4ETR2? That all makes me wonder if <Z> TCEA Loc 5 in <P> is acting up. Older versions of the TCEA were configured with berg jumpers whereas newer TCEA's are more configured with IO Configurator. Did someone replace that TCEA and not set the berg jumpers correctly? Is there a damaged overspeed probe in the field causing just that <Z> card to glitch out at a certain speed? Is TNH or TNH_OS (or TNL_OS) also in mismatch depending on this particular application? Somewhere down in the guts of this thing some bad IO, bad interpretation of IO, or poor communication between cores is causing a whole lot of mismatches.

I'm not trying to answer these questions directly. I'm trying to plant the seed for the original poster to understand how the Mk V works. Also as WTF has stated, every alarm matters. Disregarding large batches of voter mismatches is how you end up with tripped units. To put in in avionics terms; the pilot just spilled coffee in his lap, the co-pilot is looking at his phone instead of the instruments, and the navigator is in the washroom. Guess how the plane ends up in the side of a mountain?

 

Edit to previous;
The <T> core and its associated <P> and <QD1> may be operating just fine but the problem lies within the DENET VARC cable? In a previous post there was an alarm indicating that may be the problem. It is hard to tell without more information.

 

Thanks WTF? and White for your help which is very useful.

We have no other communications, in particular MODBUS. No external system communicating with <I> and Mark v.
The TMOS HMI communicates with three Mark V.
We have three Mark v on the stage link.
The TMOS HMI is still disconnected from the faulty turbine Mark v , and the turbine does not trip.
Once the turbine has stopped for enough time, we will proceed to check and clean the connectors of <T>, <QD1> and <P> as you advised. after I inform you of the result.
On Attached file you will find a table with signals whose vote is in disagreement.

Sincerely

 

WOW!!! That's just really insane--that list. <T> is just out there--and one of the <R> signals is, too (CPD; unless that's just a typo, it's really wild that <R> isn't seeing any CPD but <T> is when the unit's running). Also, two of the three of the Liquid Fuel Trip Oil Pressure Low switches are indicating low liquid fuel trip oil pressure. L63HL3L may be connected to <C> which is why it's not on the Pre-Vote Data Display.

Please send IO.ASG. With that we may be able to see if any of those discrete (contact) input signals that are disagreeing on <T> are on one specific cable between either the DTBA or the DTBB in <QD1> and <T>'s TCDA in Loc. 3. That may help, but still, I think you need to clean ALL of the cable connections in that Mark* V--because if you're only cleaning the ones causing a problem now the other ones are going to cause a problem sooner or later. And, just cleaning them isn't going to do much to prevent another occurrence--applying a thin film of that conductive grease will.

Anyway, it's simply wild what's going on. I don't know if the TMOS HMI is causing the problem, but ARCnet BNC connectors can ALSO become oxidized/corroded and cause intermittent problems. (AND, I've seen the wrong coaxial cable used which didn't cause problems for years, but then the nuisance intermittent problems started and got progressively worse. Replacing the cable stopped all of that. Yes; just replacing the cable (with good crimped-on BNC connectors). There are also Ethernet BNC connectors AND ARCnet BNC connectors, and termination resistors. But, if the TMOS HMI isn't having any problems communicating with the other two Mark* Vs that's probably not the source of the problem, but if reconnecting starts weird happenings again, well .... best check even the stuff that shouldn't be a problem to make sure it's not a problem.

Thanks for the info and the updates!

 

Hi there,
I confirm <R>'s vote for CPD, it's not a typing error.
We only have ARCNET BNC connectors that are already cleaned and checked with termination resistors.
Yesterday we had a trip identical to the previous ones (HMI TMOS was disconnected).
Attached is the IO.ASG file.

 

I compared the IO.ASG file against the list of voting mismatches. The discrete (contact) inputs come from both DTBA and DTBB.

Many of the other voting mismatches--related to inputs--come from the <P> core.

The common thing is the IONET that runs from <T> through the TCEA card in Loc. 5 of <P> and to the TCDA card in Loc. 3 of <QD1>. If there's any oxidation or corrosion on the connectors of that string of cabling it could be contributing to this problem.

That DOES NOT however work as an explanation for the <R> voting mismatch of CPD. We don't (as far as I remember) know how many CPD transducers this machine has--one or three. Be that as it may, I'm suggesting this particular voting mismatch signal MAY BE a problem with wire terminations of the CPD transmitter signal(s). OR, it could be problem with oxidation/corrosion on some part of the signal from the I/O terminal board on <R> to the I/O card which processes the CPD signal in <R>.

If it were me--my choice what to do next--I would clean every cable and apply NyoGel conductive grease to them all. That's just good housekeeping and proper Mark* V maintenance. (And I would also do the same to EVERY Mark* V on the site. If one is affected, then the other are or will be soon--unless there's something about the location of this particular Mark* V on the site that exposes it to some kind of atmosphere contamination that makes the cable connector issue worse than for the other machines on the site.)

I might also change the TCDA in Loc. 3 of <QD1>. BUT, like others have said on Control.com, I'm not a fan of shotgun troubleshooting, especially when it comes to swapping cards without other obvious evidence. I understand your desire--and need--to solve this problem sooner rather than later. AND, swapping cards, especially when done when there is a rush to get the machine back on line usually leads to problems with the way the ribbon cable connectors are handled leading to problems with the cables (like the 3PL cable)--mishandling or rough handling of cables can damage any connector, even ones with pull tabs.

I know the IONET cable IS not technically a ribbon cable--but the pins and sockets of the cable (all along its length) are still subject to oxidation and/or corrosion.

The discrete (contact) inputs to <QD1>'s <T> TCDA card are on just about every JT cable on the DTBA and DTBB. So, it doesn't seem like the problem is either the DTBA or the DTBB, but those are VERY difficult I/O termination cards to change without making mistakes (especially when being rushed to change even one of them).

Anyway, I hope this is useful in deciding what to do next. I can't offer anything more at this time; I'm convinced (based on the information provided in this thread) that the proper course of action is cleaning and greasing EVERY connector in that Mark* V panel.

Best of luck!

 

@White,



The L4 rung is about the simplest in the Mark*. Yes; it requires L4S (L4 Set) to pick up L4. And L4S isn't a logic "1" for very long after a START is initiated.

L4T is THE Mark* V CSP trip logic signal. Any one of many conditions can cause L4T to transition from a logic "0" to a logic "1"--and when it does while L4 is a logic "1" it will cause L4 to go to a logic "0" and trip the machine. L4T MUST BE A LOGIC "1" at the time L4S is a logic "1" to cause L4 to change to a logic "1".

IN ADDITION L94T (Shutdown "Trip" Logic) MUST BE A LOGIC "0" in order for L4 to change to a logic "1" when L4S is a logic "1" during STARTing. L94T is the logic signal that, during a normal fired shutdown, goes to a logic "1" when the fuel is to be shut off as the machine is coasting down. That's the only time L94T should ever be a logic "1"--when the machine reaches the speed at which fuel should be shut off during a normal fired shutdown.

SO, to pick up L4 during a START both L4T and L94T MUST BE logic "0" at the instant L4S goes to a logic "1" (which it does for a very short period of time, 1 second, I think--because when L4 goes to logic "1" L4Y will change to logic "0" 1 second after L4 goes to a logic "1".

Now, what makes L4S go to a logic "1"?



L4S will go to a logic "1" (for 1 second) when L4SX (L4 Set-Auxiliary) is a logic "1" AND L14HM is a logic "0" (when the machine is below minimum firing speed) AND L4Y is a logic "1". L4Y is a logic "1" when L4 IS NOT a logic "1" (or when L4 is a logic "0")--which it is during a normal START between when the operator initiates a START and before L.O. pressure is established at the generator non-drive end (collector end) (so after the Aux. L.O. pump has built up sufficient pressure at the collector end of the generator--the furthest point in the L.O. system from the L.O. pumps). And, during a start, whether the machine is at zero speed or even on cooldown, the machine speed should be less than TNK14HM1--which will make L14HM a logic "0".

I believe there are a couple of other permissives (conditions) which have to be satisfied in order for L4SX to be a logic "1" (the Start Checks all have to be satisfied (L3STCK must be a logic "1") is one, which is required to even allow a START to be initiated.

So, either something in <T> is causing it's L4T signal to be a logic "1" prior to a START when L4SX goes to a logic "1" in <T> (which we'll discuss a little more shortly) OR something is causing <T>'s L4T to go to a logic "1" AFTER <T>'s L4 has been set to a logic "1" during a START.

Without being able to see the CSP for the machine in question it's impossible to say if any of the Start Check permissives in <T> are not satisfied--but if one wasn't, then L4SX would never to go logic "1" in <T> during a START. So, that's one thing. I would expect if there was a trip condition "detected" in <T> that it would cause L4T to be and to remain a logic "1" prior to and during a START. And. L45FTX1 probably satisfies that--and it's listed as being in disagreement with <R> & <S> BOTH when the unit is stopped AND when it's running.

But, that really shouldn't make a difference--in my personal experience--because SIFT (Software Implemented Fault Tolerance) should tell <T> that <R>'s and <S>'s values of L45FTX1 are logic "0", so when <T> is voting inputs it should use the voted value of L45FTX1--which is logic "0"--in it's execution of the CSP.

So, something is really wrong if <T> isn't using it's voted input values when it's executing the CSP.

The only other thing I can think of is that this panel is an older "A" panel.?.?.? and probably has older PROMsets that newer panels, which could mean that there is/was a bug in the OS of this PROMset (not very likely, but not completely impossible, either.) Or, there's just enough oxidation/corrosion on cable connectors and receptacle sockets and pins that communications is REALLY messed up (my personal belief and choice).

But, we'll have to wait and hear from AHNIN. Hopefully soon.

The PTRs are associated with the Liquid Fuel Stop Valve solenoid--usually L20FL1X. The ETRs are associated with L4_XTP AND the firmware for speed detection in <P> (magnitude AND rate-of-change). This is really maddening--I just hope we get some good, believable feedback about the resolution to this (these) problem(s). It's so frustrating when all we hear is, "The problem has been solved--thanks for your help!" I mean, it's nice that the problem is solved, but no one who's reading the thread knows WHAT or HOW the problem was solved.

Anyway, it's late and I'm tired and need to just pick up the book I'm reading and turn a bunch of pages and get lost in the story for a couple of hours. Have dinner, spend some time with my wife and our friends with some good drinks and eat fresh fruit for dessert (it's that time of the year for good fresh fruit! (obviously I'm in the Northern hemisphere)). Enjoy, everyone!

 

Hi there,
I have to inform you that we have only one CPD transducer (96CD-1 connected to <R> TBQB Screw num 1- 2 -3 and 4).
We made the Mark V out of power supply and cleaned all the connectors (for all the Mark V). After restoring power to the Mark V, we had the following messages:
For <S>:
6 DCC errors
Missing IO Card
IO CFG failed
DCC IO reset
For <C> :
7 DCC errors
QST DPM Time Out
IO CFG BAD RESP
IO CFG failed
DCC IO reset
And for the <T> vote, unfortunately nothing has been changed.
<S> reach to A7 and after a few minutes we saw that it initialized itself.
We had the alarms attached.
Tomorrow i will scan the csp and share it.

 

You have written previously there are three turbines with Mark* V on the site.

1) Are all three Mark* Vs the same version (A)?

2) If yes, do you see the same error messages when a processor is re-booted?

There is a drawing of the TBQB CPD transmitter inputs in the Signal Flow Diagrams in Appendix D of the Mark V Maintenance Manual, GEH-5980. When only one CPD transmitter is used there are jumpers on the TBQB used to connect the single transmitter to all three control processors. There is a cable to each control processor from the TBQB. It seems either the jumpers for the <R> CPD input are incorrect, or the TBQB has a problem, or the cable between the TBQB and <R> has a problem or the card the cable connects to in <R> has a problem.

The next logical steps in fixing the <T> voter mismatches would be:

a) Replacing the TCDA in Loc. 3 of <QD1>
b) Reformatting the EEPROM of <T> (which effectively erases the EEPROM) followed immediately by re-booting <T> (it should not/will not return to A7), followed by downloading USER to <T> (<T> may jump to A7 after the download—but it’s a false A7!), followed by a hard reboot (using the switch in <PD>) at which time <T> will/should go to A7.
c) Replacing the TCQC of <T>
d) Replacing the LCC of <T>
e) Replacing the DCC of <T>
f) Replacing the TCEA in Loc. 5 of <P>

When replacing the DCC you should reformat the EEPROM (to be sure the EEPROM is erased AND to format the EEPROM to prepare it for the USER download), perform a hard re-boot of <T> (it should not/will not go to A7), download USER to the EEPROM and perform a hard re-boot of <T> which should return the processor to A7.

If all of that fails then there’s something seriously wrong with the DENET between the processors (all four of them).

I am assuming there are no control processor-specific download files on the HMI (with the possible exception of I/O Config files).

It would really help to know what the Pre-Vote Data for the L4T permissives are: L4PRE, L4POST, etc. Have a look at the L4T rung and tell us what the Pre-Vote Data values for each of the permissives are, at zero speed after a MASTER RESET and when running. If any of the permissives are indicating trip, then tell us what the reason is (by using the Pre-Vote Data Display).

On some versions of Mark* V <I>s it was possible to see the Pre-Vote Data values for control processors using the Dynamic Rung Display but not all <I>s had this capability and I can’t remember how to get to the capability (though it was using the “soft switches” at the bottom of the Dynamic Rung display).

Sometimes, the Pre-Vote Data Display doesn’t have all the software logic signals. In that case you can use the Logic Forcing Display to put the logic signals on the display and view the Pre-Vote values. As long as you don’t have any logic signals forced the turbine can’t be tripped doing this!

It’s a LOT of work, and when exchanging cards care must be used when unplugging ribbon cables—especially the 3PL cables—(that’s NOT a new panel, and those AREN’T new ribbon cables) AND when swapping PROMs to be sure the legs don’t get bent or damaged AND that they are properly and firmly inserted into the chip sockets.

I STRONGLY suggest as you do this you write down everything you do, note anything you find and the results of each step as you power-up and download and re-boot and check the Pre-Vote Data values.

I suggest doing each step individually—instead of trying everything all at once (the shotgun approach)—because if you do everything all at once and it’s successful you won’t know what the cause was. AND you will be left with several cards that ARE NOT known to be good or bad, and if they all get sent back to the warehouse/stores when they get pulled out next time there’s a problem one or more of those cards WILL BE bad/failed—causing more lost time and work in the future. So if it’s decided to use the shotgun approach be smart and replace all the cards so there aren’t problems in the future. It’s expensive replacing all those cards without knowing which one is bad (or which ones are bad!) but putting bad card(s) back in the warehouse/stores is a recipe for future problems and headaches.

 

If the other Mark* Vs have a single CPD transmitter then you can compare the TBQB jumpers on a working Mark* V with good CPD readings to the TBQB jumpers on the Mark* V with the CPD problem.
.
AND the pins and sockets of the jumpers can ALSO get oxidized and/or corroded...!!!

Just sayin'....

 

There should be a file named CSP.PRN and one named CSP_XREF.PRN in the F:/UNIT1 directory that was used to print the CSP. You could just post those to this thread if that’s easier (and you KNOW these were used to print the CSP & CSP Cross—Reference you would be scanning).

 

The jumpers of TBAB <R> are identical to those of other Mark V (Only BJ1; BJ2; BJ3 and BJ4 are done). I think that since the CPD signal connects to terminals 1,2,3 and 4 of TBQB and arrives at <S> and <T> the TBQB card is healthy and I must check beyond JHR.
The three Mark V are the same (type A).
After initialization of the <R>, <S> and <T> processors of the other Mark Vs, the same messages are displayed as those of <S> of the faulty Mark V.
I think the "logic forcing display" gives the values after the vote and not the pre-vote ones (TMOS HMI sends both for the signals defined at the pre-vote data). The signals L4T, L4PRET and L4POST are not defined in the "pre-vote data display", their values at the "logic forcing display" when turbine stoped are:

	C​	R​	S​	T​
L4T	1​	1​	1​	1​
L4PRET	1​	1​	1​	1​
L4POST	0​	0​	0​	0​

 

I’m not really interested in the Pre-Vite values of the L4 and related permissives. I’m more interested in what the voted values are—because that’s what is causing the L4PTR_FB and L4ETR_FB Diagnostic Alarms—and that’s what is leading to the “unannunciated” trips—in my personal opinion.

But none of this makes sense to me. It could be the DENET cable between <S> & <T> (as @White suggested) that’s causing problems, but while that doesn’t seem likely to me it is possible.

I am really interested right now in why L4PRET is a logic “1” and what is causing L4 to be a logic “1” in <T> when the unit is running. And why CPD is not reading in <R> and what effect that’s having on the fuel command of <R>.

 

From the CSP.PRN file, L4PRETX is driven by three signals, each in parallel: L4ACS (Aux. Check Servos), L27QEL (Emer. D.C. L.O. Pump Motor Undervoltate) and L3CP (Customer Permissive). It would be very helpful to know what the status of all three signals is when the unit is stopped and L4PRET is a logic "1" (because L4PRETX is a logic "1").

I'm going to work on a list of signals to be captured by VIEW2 so that we can try to see what's happening from zero speed (AFTER a MASTER RESET was performed and prior to initiating a START) all the way up to post-synchronization and some part-load condition. But I won't have any free time today until late in the evening.

I want to ask if the executable VIEWPV.EXE is in G:\EXEC?

 

I’m not really interested in the Pre-Vite values of the L4 and related permissives. I’m more interested in what the voted values are—because that’s what is causing the L4PTR_FB and L4ETR_FB Diagnostic Alarms—and that’s what is leading to the “unannunciated” trips—in my personal opinion.

But none of this makes sense to me. It could be the DENET cable between <S> & <T> (as @White suggested) that’s causing problems, but while that doesn’t seem likely to me it is possible.

I am really interested right now in why L4PRET is a logic “1” and what is causing L4 to be a logic “1” in <T> when the unit is running. And why CPD is not reading in <R> and what effect that’s having on the fuel command of <R>.

I don't have time to look up the jumper appendix of GEH-5980 right now, but just floating an idea. Does DENET have berg jumpers to apply terminal resistance in the same manner IONET does? In IONET terms, if the unit did not have a <QD2> and terminal resistance was not applied to a TCDA in <QD1>, the unit would misbehave. Does the TCQC in <T> automatically apply terminal resistance for CARC if there is no <D> and terminal resistance to VARC as its the last core in the DENET daisy chain, or is that set with jumpers?

DENET and IONET are ARCnet just in twisted pair format rather than coax, as such terminal resistance needs to be applied to the last in line. This particular problem original poster is having is pretty bizarre.

 

"This particular problem original poster is having is pretty bizarre."

THAT is an understatement, sir.

 

@White,

Your theory about the termination resistor on TCQC is certainly plausible. I don't have access to a Mark V Application Manual at this time, and I do recall something about termination resistors for CARC, I believe. If a TCQC was replaced it's possible that the jumpers didn't get set properly.

AHNIN, was the TCQC in <T> replaced recently? Perhaps more than once?

I will have to get another computer out to look at the Signal Flow Diagrams. And, I'm still working on the VIEWPV list and command line.