Mark Vie PPDA IO Pack Fault


Thread Starter


Hello Everyone,

I hope you enjoyed your Easter.
My machine is a frame 9E, running on liquid fuel and the control system is Mark VIe.

After a normal shutdown, the following alarms were observed and still active:

DC Power Supply undervoltage
IO pack communication fault
PPDA Pbus (R) source fault
PPDA Pbus (S) source fault
PPDA Pbus (T) source fault
PPDA Bus (S) not Regulating
PPDA Bus (T) not Regulating
Battery 125Vdc ground
PPDA 125Vdc Pbus feed fault
PPDA/JPDD 125Vdc power feed fault

The following diagnostic alarms were also present and still active in ToolBoxST :

PPDA (PackR) Total communication failure between PackR (JA1) and controller, Fault number : Error.

PPDA (PackR) (JA1) I/O communication failure between PackR and controller, Fault number : Error.

All LEDs except communication LEDs on the PPDA pack were found blinking faintly at about 1/4 of a second.

These alarms have enunciated and cleared within seconds on few occasions whiles the unit was running.

The communication LEDs on the R and S IONet switches were off.

28Vdc on the PDM board were maesured and was ok
125vdc on the JPDF board was measured and was ok
125Vdc battery source on JPDF board was measured and was ok with voltage on Positive leg exactly equal to voltage on the negative leg.

Dc Power on all JPDD cards are ok
All I/O packs and Boards are working ok
All network switches are working ok
Controller states are in controlling and all are equal.

JPDM and JPDF are simplex.

With the above information, I have concluded that the PPDA I/O pack is faulty and need to be replaced,am I right?

Since we don't have a spare of the PPDA card at the moment,can we start and run the unit with the IO start-up permissive forced without the PPDA card monitoring and giving voltage levels feedback to the controller?

What could be the possible consequences to run the turbine without a functional PPDA I/O Pack.

Your views would be very much cherished.

Many thanks.

Your diagnosis would seem to be correct based on the information provided. My hesitation stems from the fear of just replacing the PPDA and having the new one fail because the printed circuit card it's mounted is bad, or some issue with the power supply (voltages spikes/dips). I say this because you say there were other alarms which were annunciated intermittently while the unit was running and without understanding the operating conditions when that happened it's difficult to know why--other than perhaps it was a possible early indication of some failure or either the PPDA or some other issue/component.

Without being able to see the application code running in the Mark VIe at your site, it's difficult to impossible to say for sure what the consequences of forcing the permissive to start and running the machine without a functioning PPDA would be. Unless there is some logic in the application code which alarms or trips on low voltage levels or ground indications it would seem to be okay--but that's just a scientific wild-arsed guess without being able to actually see the application code and configuration.

Have you tried powering down the Mark VIe (in an orderly fashion) and then cycling the DC and AC power inputs to the PDM off and then on (after about 30 seconds) to see if that would get the PPDA communicating again? (I absolutely do NOT recommend trying to remove the PPDA while AC and DC power is on the PDM--it's possible, nay, likely--that some voltages could be inadvertently shorted and/or grounded by doing so, not to mention arcing which might occur as the PPDA connector is pulled away from and then pushed into the connector on the card. (Though you may have seen others simply open the DC main breaker to the Mark VIe and then re-close it to cycle power, that is <b>NOT</b> the proper method to power down, or to cycle the processors of, a Mark VIe. Poor practices by others should not be perpetuated.)

It's also possible that some kind of voltage spike(s) or dip(s) may have caused a failure of the board the PPDA is mounted on, or there may be a problem with the cables connecting all the components of the PDM together (possibly as simple as firmly seating the cables--do NOT unplug the cables with power on the PDM! but you could press the connectors to ensure they are all firmly seated, using appropriate personal protective equipment (gloves) while doing so).

We would like <i>very much</i> to hear back how this problem is resolved. (We don't usually hear back from you about how other issues you've asked for help with have been resolved.)
Dear CSA,

Thanks a lot for your response.
Though I have made a purchase request for both PDM board and PPDA pack. I concluded on the PPDA because:

1. I powered the PPDA pack unplugged from the the PDM board and the power LED on the pack was still faintly blinking at about 1/4 of a second which how it behaves when plugged on the PDM board.

2. As i said the voltages on all the DC distribution cards,all IO packs/cards are ok.

3. The same set of alarms have occurred before and cleared within seconds whiles the unit was running without any trips. I asked the operator on one occasion to quickly check the status of the LEDs on the PPDA pack and when he checked, the pack LEDs were behaving in the same manner as I explained earlier.

For the application code i haven't seen any logic yet that will alarm or trip the turbine without the PPDA card when there is a voltage spike/dip or low voltage levels or ground fault.I will check the code thoroughly and get back to you.

> Have you tried powering down the Mark VIe (in an orderly fashion) and then
> cycling the DC and AC power inputs to the PDM off and then on (after about 30
> seconds) to see if that would get the PPDA communicating again?

I planned powering down the Mark VIe and also cycle power on the PDM and JPDF boards this morning.
I have written down the following sequence for powering down/cycle the power to the controllers:

1. Switch all GT drives, motors to off mode.

2. On the PDM power down:
R switch
S switch
T switch in that order

3. On the PDM power down:
X switch
Y switch
Z switch

4. Power down 125vdc battery DC input breaker on the JPDF board.

In restoring the power back:

1. Power up 125vdc battery DC input breaker on the JPDF board.

2. On the PDM power up:
Z switch
Y switch
X switch

3. On the PDM power up:
T switch
S switch
R switch in that order

(Wait for at least 3 to 4 mins after power up one controller before power the next.)

Any suggestions or advice?

I have also decided to Remove the PDM and JPDF cards for cleaning with a dry non-metallic brush and check soldering joints and connectors closely before fixing them back.

what do you suggest?

> (We don't usually hear back from you about how other issues you've asked for help with have been resolved.)

On my other posts which I have not given any feedback,(White thick smoke from GT exhaust during start-up and Alarm Silence Button). the GT has been running continuously since then but we have just started Combustion inspection and we would use the opportunity to troubleshoot the smoking problem. However a few observations have been made after the removal of the fuel nozzles:

1.A dark and thick waxy substance was found at the tip of most of the fuel nozzles.

2. Atomizing air pre-cooler was found seriously leaking and its being replaced(possible cause)

I will give a complete feedback after start-up.

For the Alarm silence,the problem still persists because the "alarm.horn" signal toggles to true when there is an alarm and still remains true even if the alarm is cleared and i couldn't find the "alarm.hornSilence" signal to be used for the silence button.

Best regards.

About the only change I would make to your procedure would be to switch off the protective processors first before the control processors, and when powering the panel up again, switch the protective processors on first then the control processors. I have had much better luck with establishing succesful IONET communications on power-up with this order. (It doesn't seem it should make any difference what order the processors are powered-down, but it does seem to for some odd reason--or maybe it's just on the versions of firmware I've worked with. It certainly also seems to help that when the control processors are looking for their associated protective processors that if the protective processors are already powered-up and waiting to establish communications. Again, it just may have been the versions of firmware that I was working with, but it seemed to definitely prevent multiple re-boots to re-establish IONET communications.)

As for the alarm silence issue, you are making this too difficult. Look at a working HMI to see what signal the Alarm Silence target is writing to. (I think that's what has been suggested before.) Also, don't be too literal in your search of the control signal database. Look for alarm management functions in the application code and you should probably find what you're looking for.

Let us know how this turns out for you.
Dear CSA,

I was able to reboot (cycle power) to the whole panel and disconnected the JPDF and PDM Boards respectively for cleaning and visual inspection yesterday but the PPDA pack still behaved the same manner.

Luckily, the PPDA pack we ordered arrived this afternoon and I installed it on the existing PDM board.

I reconfigured the IO pack, downloaded boot loader, baseload, firmware and parameters into the pack successfully with ToolBoxST and now the problem is solved.

Thanks so so much for taking your time to respond to my threads. I really do appreciate it a lot.