We are facing this problem popping up all C inputs into Alarm state all of sudden with alarm DCC I/O obj #4 and DCC I/O obj#13 reset alarms.when i checked the IO states in LCC keypad.its IOMA and TCD1 hanging at A2 status. I tried to check teh 5V supply on SDCC card and also the supplies on TCDA and TCPs cards all looks normal and no problems. I even tried changing SDCC and TCPS cards and also TCDA but all efforts resulted nothing. when i reboot C processor they will come to A7 status.some times it will take 3 reboots also. during this time also i checked all power supplies but nothing found abnormal. Once i formatted C and download all.even result is same. Can you please help on this

 

This is the HARDEST thing to identify--does it happen only when the unit is being operated, or only when it is shut down, or only during starting or stopping? Is it most likely to happen only during starting or stopping or, during starting or stopping of fans or pumps or motors? If you can "link" the reset events to the starting of fans or pumps (their motors, actually) or the energization or de-energization of 125 VDC solenoids, you can start looking at the associated wiring to try to determine if signal levels weren't properly segregated during construction.

This is a VERY difficult problem to prove to the Customer, especially on a unit which has been running for some time (since this is a Mk V unit, it's likely been running for some time). Site managemant just believes it's a control system problems--when it really isn't. (Now, if the control system were a little more robust, that would certainly help--but GE publishes specifications for cable routing and signal level separation, and many architect/engineers (plant designers) and construction forement and supervisors just consider them to be nuisance guidelines and/or too expensive to implement--so they don't....

It is also believed that GE has "improved" the TCDA cards in recent years, and their PROMsets, to make them more tolerant of AC noise on input wiring. You might try checking into the possibility that the newer cards/PROMsets might help alleviate the problem--it WON'T make the problem of poor construction practices go away--and if the noise gets worse, which it can and has been known to do over time (this author is not an electrical engineer, but has noticed that either the noise problems get worse, or the Mk V cards begin to be more susceptible to the noise over time.?.?.?) the problems may come return.

Yours is a tough problem--especially if the unit has been running for some time. Customers just REFUSE to understand that the affects of poor construction practices can take years to finally become a problem--they just see the control system as "the problem". And the field engineer or the technician is saddled with just "fixing" the control system--which, in many cases, just can't be done if the problem is poor signal level separation during construction.

Has your site implemented TIL (Technical Information Letter 1480-2)? If yes, are you CERTAIN the card configuration files were properly updated when the PROM upgrade was performed? If the card configuration files weren't properly updated during the implementation of the TIL and/or the card was properly "enabled" in the I/O Configurator during the implementation of the TIL (the card configuration files might be correct, but if the card was disabled then enabled to load the new configuration then that might be the problem) then downloading and re-booting and formatting and downloading and re-booting isn't going to do any good.

Also, if the processor isn't being re-booted with the switch in the <PD> (Power Distribution) core, the TCDA isn't being re-booted to make it go to the EEPROM in <C> to get the information it needs. Using the white reset button to reboot processors is NOT recommended under any circumstances--and especially when cards outside the processor (such as the TCDA card for <C>, and the TCEA cards and TCDA cards for <Q>) are involved.

It is also a possibility (likelihood) that there is an AC component (noise) to some of the inputs (or outputs.?.?.?) connected to the <C> core.

I/O OBJ #4 is the TCDA card, and I/O OBJ #13 is the IOMA "card".

You can look at the fields of the two "objects"--also referred to as "targets"--and see what inputs and outputs of those two objects are used and how they are configured.

You might try replacing the TCDA card and seeing if that helps. Another thing you might trying is to go into the I/O Configurator for <C>'s TCDA card and set all the Change Detect values for EVERY contact input to "0", verify the screen, save and exit, then download to <C> and re-boot (with the power switch). It is believed that if the Change Detect bits are set to "1" they will "flood" the associated processor (<C> in this case) with nuisance contact input changes of state
which are caused by AC noise (induced or ???) on contact input wiring to <C>.

But it sure seems like there is some kind of electrical "noise" which is causing the objects to reset or be reset.

This author knows of a couple of sites which have the battery charger's ground detection circuit enabled--which is a NO-NO for the Mk V. They have incessant nuisance battery ground alarms over the years the plants have been in operation, and they have been told repeatedly it's not correct, and shown that it's not accepted practice for the charger's ground detection circuit to be active. At one site, it has even been demonstrated that by simply disabling the charger's ground detection circuit the Battery Ground Alarm indication on the Mk V clears--but management just WILL NOT permit the necessary modifications because the A/E (Architect/Engineer) who designed the plant MUST know more than the Mark V designers! So, they just battle battery ground alarms week in and week out, month in and month out, year in and year out--because of poor construction and design practice.

Tough problem--let us know how you fare with your efforts!

markvguy

 

Hi
Are you have any ground alarm like 125 vdc ground or battery charger problem or battery ground like this?

It is true that DCC IOOBJID#4 means TCDA card and the IOOBJID#13 means IOMA .You told that you have checked the +5v dc supply on SDCC card.How much voltage you got?It should be atleast 5 or more than that.If it is less than 5 v than ,adjust the R29 potentiometer in the TCPS card to get it +5V DC.

You told you have you have tried replacing the SDCC and TCDA card.But have you followed the all the procedure while changing those cards.I think by replacing these two cards these problem should go away, until and unless you have some ground alarm persisting.

 

Yes, I tried my level best to identify AC noise with a logging multimeter by measuring AC with respect to ground to each input on DTBA and DTBB all inputs AC is below 500mv. Event printer reported no milliseconds events or SOE, AlmDump1 results nothing also. I changed TCDA card in the first incident two months ago but result same. During recent shutdown I changed TCPS and SDCC card as a precaution. Even I adjusted R29 to make 5V supply from 4.95 to 5.3 to tolerate any down swings. For me AC noise results in EVENTS or SOE and even Digitalinput Alarms by resetting in Milliseconds. That means if TCDA resets by AC noise all didgital input alarms comes to alarm state and becomes normal at the same time. In my Case all Digital inputs in C core stays in Alarm state. Finally I had an opportunity to shutdown yesterday night. I made my final attempt of troubleshooting by swapping SDCC card with other panel nearby. Convincing opeartions is a difficult part of my troubleshooting as they are already in yellow with me troubleshooting results while machine is running. Finally I changed SDCC card with other panel and after some time I got DCC I/O obj ID #13 alarm. Now it's clear to me that there is something itchy here with IOMA Eproms. To confirm that I got a new SDCC card and changed with OLD IOMA eproms, GASQ eprom set is newer than this problem so we can eliminate this chance. Fortunately the problem repeated again in the same manner of old panel after 2 hours normal operation. Now I am sure that IOMA set has some issues. As of now no spare set available and trying to get this compatible set from standy machines in Powergen side. I hope the issue is resolved. Any comments??

 

Hi,

For adjusting the 5V DC, use a good quality meter and do not trust the screen readings!!

There can be an important differance between both. Adjust the voltage between 4,95 and Maximum 5.08 volt DC!! Adjusting R29 will even to adjust the other voltages; +15, +24 -15 and -24. Be aware of this.

Success

 

I believe the voltage on SDCC only. Why did you say Maximum is 5.08? MarkV manual says maximum is 5.5. I did this with all other voltage tolerance limits in mind.

Thanks,

 

Belive this or not. Check the arcnet cables for Stagelink communication. Try reconfiguring the cables. Instead of the arcnet going from HMI to MKV to EX2000, go from HMI to EX2000 to C core. Make sure the termination resistors are placed accordingly. Replace all of the termination resistors if neccesary. TCDA also provides arcnet comm. Comm problems will overwelm C core causing it to drop it's I/O cards.

 

Belive it or not The issue is solved by replacing IOMA eproms. what i observed is after sometime all TCDA inputs in C processor are becoming 1 and stays in 1. Unfortunately if it is AC noise the state changes in milli second. This point made me curious and i tried by changing IOMA eproms with other machine when i got opertunity. Now Machine is running without any issues from 2 months.

 

This is good news, and, thanks for the feedback.

How will you get new IOMA PROMs?

The AC noise issue on contact inputs is a huge one. Many installations didn't follow good installation practices, and if the Mark V panel installation was a retro-fit, it was probably to replace a panel which wasn't quite so sensitive to AC noise on the contact inputs.

Again, congratulations--and thanks for the feedback. Quoting markvguy: "Feedback is our most important contribution [here at control.com]."