Mark V DCC error

A

Thread Starter

anonymous

Dear All,

Need help here, I got this following error on my DCC display at <C> core;

201 DCC error, No BMS memory buffs and UDM no memory. How do I clear it
Thanks in advance
 
http://www.control.com/thread/1026224836#1026224887

There are instructions there for resetting "local" Diagnostic Alarms on the LCC/SLCC display.

As for what causes the alarms, well, many things can cause the alarms. Using CARD_ID.EXE can cause the alarms. Improperly formed MODBUS or GSM communications requests; improperly configured CIMPLICITY projects on GE Mark V HMIs; too many GE Mark V HMI Servers configured to communicate with a single Mark V panel. And just a plain old communications error can cause them (they do happen from time to time). High-powered walkie-talkies can also cause the alarms. Too many Logic Forcing displays or Pre-Vote Data displays can cause these alarms.

In general, anything that causes rapid, repeated requests for data and data that doesn't exist (bad pointnames in MODBUS or GSM) or anything that interrupts communication can cause the problem. Even rebooting a processor can sometimes cause these alarms, but not normally.
 
Dear CSA

thanks for the reply but can someone help me email the instruction procedure on how to resetting the LCC display. I already go through the maintenance, user and application manual more than 3 times but cannot find the procedure. Please email it to me at
william.chong1983 [at] gmail.com

thanks
 
>>Have you tried resetting the System Errors on the <C> core using the LCC Display keypad? (Press the LCC key in the upper left-most corner of the keypad; the display should indicate "--i86 MONITOR--". Press the INC button at the bottom of the display keypad three times until the display shows "3) CLEAR SYS ERRORS", then press "ENTER" on the display keypad. The number of errors being reset, or cleared, should be displayed. Press INC three times again to show "3) CLEAR SYS ERRORS" and if the error count should show zero; if not, and new errors have occurred then the problem(s) has(have) not been reset.<<

isn't the above pretty clear?

 
Yes Mr.CSA

It's well clear we followed the same when we had the error message on the processor.

Hope CSA answer could have solved the problem for who had raised this question.

Thanks
G.Rajesh
 
Dear CSA,

thanks for the procedure. I already reset the LCC by using your procedure and all the error cleared. but after that how do I go back to normal page now it showing --i86 MONITOR--

thanks again
 
Thanks for the feedback!

There should be a button on the LCC/SLCC keypad called 'NORM' (for NORMal) or something like that.

Try pressing that button to return to the normal display.
 
how to change the DS200DCC Card ID to read <S> instead of <R>. I am not sure what keypad functions we should use to change the <S> core address from <R> to <S>. Pleae advice.
 
Dear CSA,

About these DCC errors on the LCD core display, it only shows how many errors occured. My question, is there any way to find out what is the detail of each DCC errors listed on the LCD display?
Thank you.

Best regards
Ali.
 
Ali Sadikin,

The second paragraph of the first reply (after the link to the thread with the instructions for resetting the alarm messages on the LCS/SLCC display) lists the most common causes of these alarms, especially if the numbers of the alarms are increasing with each scan of the display.

Have you used the procedure for resetting the LCC/SLCC display Diag. Alarms? If so, what happened? Did the alarms reappear and start increasing again?

Which processor (or which processors) are indicating Diagnostic Alarms on the LCC/SLCC displays?

What Diagnostic Alarms are active on the operator interface (<I> or HMI)?

What have done to try to resolve these LCC/SLCC Diagnostic Alarms and, MOST IMPORTANTLY: What were the results? (Other than, the alarms reappeared.)

What, if any, other difficulties are occurring?

Have you used the 186 MONitor function to check the status of all of the processor's associated cards?

What is the I/O State of the processor(s) with the Diagnostic Alarms?

Did these alarms appear after replacing a card in the processor? If so, which card?

Did these alarms appear after some change was made to the operator interface?

Did these alarms appear after a download to the one or more of the processors? If so, what was downloaded and to which processors?

Does the operator interface (<I> or HMI) use MODBUS or GSM to communicate with a DCS or other control system?

Does the site have a <G> or GE-provided Historian?

The more information you can provide in your original post, the better our responses will be. There was already a pretty complete list of the most common causes of these alarms in the first reply to the original post (maybe not in tabular format, but in a paragraph, separated by colons). So, if you are having issues you have tried to resolve but can't, please tell us what you've done, and--MOST IMPORTANTLY--what the results were. And, any other information, such as the list provided above.

And we can try to help.
 
CSA,

Thank you for the quick reply. First I need to give information about our site. We operate 1 block combine cycle power plant with 3 GT and 1 ST. All use Mark V with TMR type. For GT we only have core C for communication and for ST we have core C and D. For each GT we also have additional simplicity HMI (added because we modified the turbine to be able to operate with 3 fuel mode HSD, Gas and MFO). We also replaced <I> PC for mark V with better spec for all GT and CCR. But for ST we still keep the old <I> PC for local HMI.
Previously we use Bailey infi 90 for the DCS, now we have retrofit to GE OC6000E.

DCC error happens in core C of our STG. When DCC error accumulated it causing <I> become blank not able to communicate with MKV. We have to continuously clear the errors otherwise it become blank and when it blank there's no other way but to reboot core C. Sometime we have trip conditions but sometimes not. So we have solution for that which is removing communication from (CTBA) C to D. And after that C is safe with no accumulated DCC errors, but core D now having the same DCC errors issue. We keep clear the errors for every 2 hours (local operator did this job)

At first my suspect is OC6000E causing this DCC errors but fortunately in GT we don't have this issue. I have read other thread about DCS retrofit causing error in communication because its requesting much faster data from mark V than the old DCS and causing bottleneck. And that lead to create errors in C core. But once again our GT is safe with no errors, only in STG we have this.

Have you used the procedure for resetting the LCC/SLCC display Diag. Alarms? If so, what happened? Did the alarms reappear and start increasing again? Yes we have. Errors is cleared and start increasing again.

Which processor (or which processors) are indicating Diagnostic Alarms on the LCC/SLCC displays? Now core D

What Diagnostic Alarms are active on the operator interface (<I> or HMI)? Here I sent you some latest diag alarms

What have done to try to resolve these LCC/SLCC Diagnostic Alarms and, MOST IMPORTANTLY: What were the results? (Other than, the alarms reappeared.) We remove communication from C to D and errors appeared in D now.

What, if any, other difficulties are occurring?

Have you used the 186 MONitor function to check the status of all of the processor's associated cards?
Yes all status are A7

What is the I/O State of the processor(s) with the Diagnostic Alarms? All IO states A7

Did these alarms appear after replacing a card in the processor? If so, which card? No

Did these alarms appear after some change was made to the operator interface? No

Did these alarms appear after a download to the one or more of the processors? If so, what was downloaded and to which processors? We have try to re-download to core D but DCC error are still the same

Does the operator interface (<I> or HMI) use MODBUS or GSM to communicate with a DCS or other control system? Yes all <I> local PC connect to OC6000E with modbus protocol.

Does the site have a <G> or GE-provided Historian? We dont have this.

I have read your explanations about what might causing the errors but my question actually is there any way to know what are all these DCC errors. Just like we have diagnostic alarm we can see what are the alarms that still active so we know what to do to eliminate it. Maybe if we know what is the detail of each DCC error that exist we might know how to solve it.

Best regardsWhatsApp Image 2021-05-17 at 13.37.47 (1).jpegWhatsApp Image 2021-05-17 at 13.37.47.jpeg

WhatsApp Image 2021-05-17 at 13.37.47 (1).jpegWhatsApp Image 2021-05-17 at 13.37.47.jpegWhatsApp Image 2021-05-17 at 22.17.31.jpeg
 
Good morning
I have has similar problems with our TMR Mark V drooping communications and accumulating a bunch of DCC errors. We went through the panel and cleaned all DENET, I/O NET, and other pin and ribbon connectors. This helped alot. I recommend that you get your internal connection diagram and go through every connection and clean all starting with the LCC and work through all the way to the I/O NET on the I/O terminal boards. Hope this is helpful.
 
e

CSA,

Thank you for the quick reply. First I need to give information about our site. We operate 1 block combine cycle power plant with 3 GT and 1 ST. All use Mark V with TMR type. For GT we only have core C for communication and for ST we have core C and D. For each GT we also have additional simplicity HMI (added because we modified the turbine to be able to operate with 3 fuel mode HSD, Gas and MFO). We also replaced <I> PC for mark V with better spec for all GT and CCR. But for ST we still keep the old <I> PC for local HMI.
Previously we use Bailey infi 90 for the DCS, now we have retrofit to GE OC6000E.

DCC error happens in core C of our STG. When DCC error accumulated it causing <I> become blank not able to communicate with MKV. We have to continuously clear the errors otherwise it become blank and when it blank there's no other way but to reboot core C. Sometime we have trip conditions but sometimes not. So we have solution for that which is removing communication from (CTBA) C to D. And after that C is safe with no accumulated DCC errors, but core D now having the same DCC errors issue. We keep clear the errors for every 2 hours (local operator did this job)

At first my suspect is OC6000E causing this DCC errors but fortunately in GT we don't have this issue. I have read other thread about DCS retrofit causing error in communication because its requesting much faster data from mark V than the old DCS and causing bottleneck. And that lead to create errors in C core. But once again our GT is safe with no errors, only in STG we have this.

Have you used the procedure for resetting the LCC/SLCC display Diag. Alarms? If so, what happened? Did the alarms reappear and start increasing again? Yes we have. Errors is cleared and start increasing again.

Which processor (or which processors) are indicating Diagnostic Alarms on the LCC/SLCC displays? Now core D

What Diagnostic Alarms are active on the operator interface (<I> or HMI)? Here I sent you some latest diag alarms

What have done to try to resolve these LCC/SLCC Diagnostic Alarms and, MOST IMPORTANTLY: What were the results? (Other than, the alarms reappeared.) We remove communication from C to D and errors appeared in D now.

What, if any, other difficulties are occurring?

Have you used the 186 MONitor function to check the status of all of the processor's associated cards?
Yes all status are A7

What is the I/O State of the processor(s) with the Diagnostic Alarms? All IO states A7

Did these alarms appear after replacing a card in the processor? If so, which card? No

Did these alarms appear after some change was made to the operator interface? No

Did these alarms appear after a download to the one or more of the processors? If so, what was downloaded and to which processors? We have try to re-download to core D but DCC error are still the same

Does the operator interface (<I> or HMI) use MODBUS or GSM to communicate with a DCS or other control system? Yes all <I> local PC connect to OC6000E with modbus protocol.

Does the site have a <G> or GE-provided Historian? We dont have this.

I have read your explanations about what might causing the errors but my question actually is there any way to know what are all these DCC errors. Just like we have diagnostic alarm we can see what are the alarms that still active so we know what to do to eliminate it. Maybe if we know what is the detail of each DCC error that exist we might know how to solve it.

Best regardsView attachment 1271View attachment 1272

View attachment 1271View attachment 1272View attachment 1273
Good day,

I advise you to read and download the following document :
https://fr.scribd.com/document/451227055/MARK-V-Diagnostic-Alarms
It is clearly showing DCC " alarms description "

You need to suscribe and then pay for downloading that document from Scribd but it can help a lot in this case!

I guess that You may also find LCC alarms code meaning in that document...

I advise also to read the folloowing document to solve the issue ( if not done yet):
Mark V Troubleshooting failure to reach i/o status A7...

Here some notes from this document:
Function of the LCC Display to Determine which I/O Card(s) is (are) at fault

To use the DCC Monitor function of the LCC Display of a processor, press the DCC button of the LCC display keypad (“--186 MONITOR--" will be shown on the LCC Display). Press the DEC button of the keypad until “7>IO STATES" is displayed and then press the ENTER button. The socket number/obj ID (i.e., the processor's internal I/O card address), I/O card name/abbreviation, and I/O status of the card in the first socket will be displayed; successive I/O cards' I/O statuses can be read from the LCC Display by pressing the INC button, until the card name displayed doesn't change (pressing DEC will back up the display to the previous card). Write down the card name and its I/O status for all cards displayed.

NOTE

References to an IOMA card are actually references to the i80196 microprocessor on the DCC card of the Mark V control processor. (The i80196 is also known as the “I/O Master”.



If card names are displayed properly when scrolling through the DCC Monitor IO STATES function, continue with the trouble shooting procedure by skipping to Step 2, below. Should asterisks or random characters be displayed for any card name, the DCC's i80186 microprocessor is unable to access and/or communicate with the card and such a condition should be resolved first. Table I, below, is a list of the socket numbers/obj ID numbers (Mark V internal addresses) and card names in the order they should appear when scrolling through the DCC

<C>​
<Q>​
<D>​
<01>TCCA<01>TCQA
<01>​
TCCA
<02>TCCB*<02>TCQB*
<08>​
LCCD

Any time!

Cheers
Controls Guy25.
 
Here you have it !

See following notes :

According to the shared screenshots, it is displayed Drop code 05&09

You have the alarm description in this table:
qd​
05​
DCC NOT QUEUE SERVER FOR DESTINATIONA message was received for an unknown destination - a bad message was received.
qd​
06​
DCC QST QUEUE DELETION ERRORAn attempt was made to release a non–existent receiver (186 fatal error).
qd​
07​
DCC UNABLE TO GET DPM BUFFER FOR XMITA request for a dual port memory buffer was unsuccessful - it's either a failed I/O card or a communications overload.
qd​
08​
DCC UNABLE TO CREATE DPM SERVER SOCKETA dual port memory server task was not successfully created (186 fatal error).
qd​
09​
DCC DPM: INVALID DESTINATION
ADDRESS
An invalid message has been received from the dual port memory - it's either a 186 fatal error or a bad I/O card.
 
Ali Sadikin,

Tambak Lorok, eh?

Well, I would suggest you do as Frame5Guy suggested and do some maintenance on the connectors and receptacles of the Mark V I/O cards. It is highly recommended that conductive grease be applied to ALL cable connectors/receptacles at least once every two years. AND, too much grease is worse than no grease--so don't be overzealous. After powering-down the processor, begin by removing each cable connector from its receptacle, carefully (don't just jerk them out) and then reseat them; do this three or four or five times. This helps to loosen any corrosion and clean the pins and receptacles. Then, apply a thin film of conductive grease (heat sink grease will work fine if you can't find or don't have any conductive grease in any of the spare I/O card boxes in stores) to the cable connector (not to the card receptacle). Just wipe a thin line of grease (again--NOT too much) on the cable connector and then insert it into the receptacle. I like to remove the connector at least one more time and reseat it in the receptacle. This will help to get the grease on the pins and into the pin receptacles. Again, this should be done about every two years or so, especially in humid environments (such as Tambak Lorok).

The Diagnostic Alarms suggest there is something amiss with the StatusS connection--which is between <C> (maybe even <D>) and the EX2000. While these connnections are via BNC coaxial cable connectors, they are also susceptible to corrosion. And require maintenance. Sometimes, a little electrical contact cleaner sprayed judicisously into the connector (cables and cards) and a clean cotton swab rubbing the connectors will help. As will removing the connector and reseating them several times.

Also, many of the coaxial cables used for Mark V were made on site during construction--and they weren't always made very well. The people making these connections weren't always knowledgeable or experienced and lacked proper training or supervision and the right tools for the work. So, it's very possible that the coaxial cables/connectors are failing and in need of replacement (by cutting them off and properly installing new ones).

Some sites also had fiber optic repeaters for portions of the StageLink cabling between the turbines and the Mark Vs and HMIs. Also, sometimes these fiber optic cables were made very well, and they haven't been treated well over the decades since they were installed. The fiber optic repeaters do also fail, and require periodic cleaning and a relatively cool, dry place for long life--which wasn't always the case (they were sometimes installed in some pretty ugly locations (hot; humid; dusty). This could also be the case for the StatusS cabling as well; I think some installations also had fiber optic cabling/repeaters for the EX2K comm's.

Finally, the EX2000 (EX2K) equipment has the same issues with corrosion of cables/pins as the Mark V cards. So, while you're at it, do the same to the EX2K cable connectors/receptacles--unplug the cables and reseat them several times, and apply a thin film of conductive grease every couple of years or so. (If, when you do this in a couple of years or so you see a build-up of conductive grease when you pull the cable from the receptacle, do wipe any excess grease off before applying a new bit of grease).

If someone has made changes to MODBUS configuration(s), this can cause problems like this (DPM errors; constantly increasing error counts/numbers) because some error was made when typing signal names or register addresses and the Mark V just gets confused trying to get information which is incorrect. Repeatedly. Until the error is identified and corrected. This is also much more common with GE Mark V HMIs running CIMPLICITY, but you have an old-fashioned (and robust) <I> so this doesn't happen so often as with CIMPLICITY HMIs.

But, I still suspect the problem is something unseen--like corroded pins of cable connectors and/or receptacles. Or bad coaxial cable connectors. It doesn't take much sometimes for these little problems to become bigger problems.

Hope this helps!
 
ControlsGuy25,

I'm still scratching my arse after watching that YouTube video....

Can't blame the original poster; he's probably wondering how to resolve this problem. If all the I/O cards--and the processors (<C> and <D>) are at A7--and they can "stop" the problem or make it shift by reconnecting coaxial cables, then it kind of points at something amiss with the cabling or the communications at the other end. I often forget about the StatusS communications to the EX2K; and that has been an issue on some sites. And, the poor quality of lots of coaxial cables--including using the wrong type of cable (which happened a lot), and the wrong kind of connectors (there are connectors for Ethernet and those for ARCnet--and I'm not just talking about termination resistors) can cause problems sometimes years after they are installed. We also don't know if any cabling has been replaced recently.

Feedback is great. It's what makes Control.com a very good forum, better than most. But, it's also the quality of the responses. So, we just have to keep up our end of the bargain, and take the victories and satisfaction of responses when we get them.

To be honest, a lot of the issues posted are attributed to this, that or the other thing--and often not at all associated with the root cause. A lot of people are simply looking for validation of their theories, well-founded or not (usually the latter in this case) and so skew their responses and information to get affirmation of their ideas and (lack of) thought processes.

Also, a LOT of people simply think that by posting their problem to Control.com that their description is enough for someone who has seen the same or a similar issue before to post with a solution. It's like people who believe every GE-design Frame 5 heavy duty gas turbine is like every other GE-design Frame 5 heavy duty gas turbine--because they're all made by GE (and while the turbines are, the packages and auxiliaries aren't!) and they are all Frame 5s. So, that's enough information right? A Frame 5. Simple and easy.

The original poster has sent a lot of photos and information, and has been given a few suggestions, without asking for too much information to make the suggestions more concise. Let's hope he's busy solving the issue and/or enjoying his weekend or day(s) off and will bet back to his when he can with more information or the solution.

And, sometimes the problem just "goes away" whilst troubleshooting, usually when someone tries the shotgun approach--doing a whole bunch of things at the same time so that knowing which one (or ones) actually solved the problem is difficult to pinpoint. And, sometimes when people write back with resolutions they attribute the success to one of the things they tried during the shotgun approach, and it's not even the rite one. (Isn't this fun???!!?) How many times have you scratched your head or arse when reading a feedback? I'm going bald from scratching my head, and I'm wearing a hole in the seat of my pants, too--because it is ridiculous some times what we hear back.

So, take a chill pill, James. Yes; you provide a lot of information and do a lot of searching and posting of results. This is a free forum, and I can tell you we get more feedback sometimes that when I charge a Customer for help; they rarely provide any feedback, no matter how nice you are during the troubleshooting or when asking for the solution. Some people think payment is the only obligation they have. And some people honestly don't know what they're working on, and can't provide feedback because they don't know what solved the problem--especially when the use the shotgun approach to troubleshooting.

Enjoy spring, and the re-opening of the world to travel and experiences.
 
ControlsGuy25,

I'm still scratching my arse after watching that YouTube video....

Can't blame the original poster; he's probably wondering how to resolve this problem. If all the I/O cards--and the processors (<C> and <D>) are at A7--and they can "stop" the problem or make it shift by reconnecting coaxial cables, then it kind of points at something amiss with the cabling or the communications at the other end. I often forget about the StatusS communications to the EX2K; and that has been an issue on some sites. And, the poor quality of lots of coaxial cables--including using the wrong type of cable (which happened a lot), and the wrong kind of connectors (there are connectors for Ethernet and those for ARCnet--and I'm not just talking about termination resistors) can cause problems sometimes years after they are installed. We also don't know if any cabling has been replaced recently.

Feedback is great. It's what makes Control.com a very good forum, better than most. But, it's also the quality of the responses. So, we just have to keep up our end of the bargain, and take the victories and satisfaction of responses when we get them.

To be honest, a lot of the issues posted are attributed to this, that or the other thing--and often not at all associated with the root cause. A lot of people are simply looking for validation of their theories, well-founded or not (usually the latter in this case) and so skew their responses and information to get affirmation of their ideas and (lack of) thought processes.

Also, a LOT of people simply think that by posting their problem to Control.com that their description is enough for someone who has seen the same or a similar issue before to post with a solution. It's like people who believe every GE-design Frame 5 heavy duty gas turbine is like every other GE-design Frame 5 heavy duty gas turbine--because they're all made by GE (and while the turbines are, the packages and auxiliaries aren't!) and they are all Frame 5s. So, that's enough information right? A Frame 5. Simple and easy.

The original poster has sent a lot of photos and information, and has been given a few suggestions, without asking for too much information to make the suggestions more concise. Let's hope he's busy solving the issue and/or enjoying his weekend or day(s) off and will bet back to his when he can with more information or the solution.

And, sometimes the problem just "goes away" whilst troubleshooting, usually when someone tries the shotgun approach--doing a whole bunch of things at the same time so that knowing which one (or ones) actually solved the problem is difficult to pinpoint. And, sometimes when people write back with resolutions they attribute the success to one of the things they tried during the shotgun approach, and it's not even the rite one. (Isn't this fun???!!?) How many times have you scratched your head or arse when reading a feedback? I'm going bald from scratching my head, and I'm wearing a hole in the seat of my pants, too--because it is ridiculous some times what we hear back.

So, take a chill pill, James. Yes; you provide a lot of information and do a lot of searching and posting of results. This is a free forum, and I can tell you we get more feedback sometimes that when I charge a Customer for help; they rarely provide any feedback, no matter how nice you are during the troubleshooting or when asking for the solution. Some people think payment is the only obligation they have. And some people honestly don't know what they're working on, and can't provide feedback because they don't know what solved the problem--especially when the use the shotgun approach to troubleshooting.

Enjoy spring, and the re-opening of the world to travel and experiences.
CSA

The posted video was intented to guid original poster ...

Now I will cool down on supporting people here now most of them are just ignoring us and our efforts! to try to support them...Thats pretty shame..(Remenber thta post on Yacht diesel genset behavior /instability)

Yes we do lot of efforts (extra/outside works ) here...We desserve better behavior from some posters...


Anyway I enjoy to share /learn issues/cases experiences here ...Thats all benefit for every body ...

Stay blessed..

James
 
Top