Our <I> network inter connecting the MARK V stations got idle with last screen with “invalid data entry“ in red color on top. The alarm list was having many alarms related to a specific unit, and has "IO COMMUNICATION LOSS" alarm also. On initial checking, That specific unit's MARK <C> core was having >9500 DCC errors accumulated and was not showing anything else. Accessed the keypad -186 monitor- of <C> of that unit and cleared the faults. But still DCC error has increased @ 400 per hour...

Rebooted soft and hard, and observed, A7 is not coming due to TCCA, TCCB card in slot 1, 2 giving **** signals in I/O states. Additionally “3PL missing” and “QST DPM TIMEOUT” message was also being displayed in the <C> core...

After taking out 3PLcable, reinserting, and rebooted. Now everything went well. A7 arrived, but this time DCC error increased at a very low rate of 25 per hour...after one or two clear fault exercise, it got steady and no more DCC error was coming further...

However after three days on a random check. It was observed that the increasing DCC error trend has resurfaced @ 300-400 per hour rate. On checking history, we found that two months back this unit had a buffer full message like "DCC unable to get DPM buffer for transmit” in diagnostic alarm and then has affected only one < i> at that time.... which was removed after rebooting <C>.

(i) What could be the reason for “ DCC ERROR “ message like “250 DCC ERROR FOUND”?

(ii) What could be the reason for “QST DPM TIME OUT” message, which we observed in many cores of many units?

(iii) What could be the reason for the buffer full message "DCC unable to get DPM buffer for transmit"

- Kindly give your suggestions....

 

> (iii) What could be the reason for the buffer full message "DCC unable to get
> DPM buffer for transmit"

Hi,

In UNIT1 folder there are two files: HELP_QD.dat and HELP_BD.dat where are some explanations to the message you received together with recommended action.

The possible cause of the message "DCC unable to get DPM buffer for transmit" is excessive communication traffic.

It can be too many view2 files opened, too many logic forcing screens opened, too many <Is> communicating with one MKV (GE declares: no more than two). Check remote communication media for creating excessive data request: modbus, GSM, Historian, OSM, exciter EX2000 - if you have them.

All your examples (i, ii, iii) could have origin in this excessive data traffic.

Another option to consider is: disturbance of communication on the ARCNET due to bad electrical connection or missing end of line resistor - anyhow this should affect all turbines.

By issuing DOS command: 'ARCWHO' from any <I> you receive the list of nodes seen by this <I> but also the number of the network reconfigurations seen by this node. Re-issuing 'ARCWHO' command from the same <I> after a period of time you can monitor stability of the net: on unstable net, number of reconfigurations increases. By rebooting the <I> you reset the counter.

I am not sure if this option (i.e. display of number of reconfigurations on ARCNET by issuing: Arcwho) is valid for older IDP software.

Regards

 

We have checked, and no such communication issue was observed, but we cannot rule out as all the units are connected to all <I> in multi-unit configuration. We tried to reboot <C> again and again and each time it responded differently. Once observed that 3PL MISSING, DPM BAD PROTOCOL messages were coming with the increasing DCC ERROR. Second time along with that TCCB card in slot 3 was not identified...IO OBJECT#1 RESET message was also displayed. Third time both TCCA, TCCB cards were not identified. We suspect the cvable 3PL....

After trial with the connector reaffirmation by "pressing" and after multiple softstart.. it became okay..with all cards showing A7 status..

Any chance 3PL could be the problem.. we may be trying by replacing this...

 

Dear RP,

I would suggest when the unit is down that you remove and reseat all connectors on "C" core. There have been issues of corrosion accumulating on the connectors of boards that can cause some strange symptoms due to voltage fluctuations. Removing and reseating the connectors as well as applying a small amount of special conductive grease that GE supplies with new cards may repair this issue.

Do a search using the search feature at the right side of the screen, search +3PL+ and see what articles it returns.

Let us know how things go as you continue to diagnose and hopefully repair the issue.

 

At present the unit is not to be touched, as per instruction from above, as no error is coming after another bout of rebooting and resetting errors.. I feel it may come again, and we will be checking the 3PL ribbon first...

Thanks to all... I will update this section on any further changes...