MKV SDCCG4A Revision Level Conflict

The MKV TMR panel in question has a full compliment of SDCCG4AHD cards. One has developed a problem and we would like to change it out for a replacement, however the only replacement we can find is an SDCCG4AGD, which is an earlier revision. In the past I have changed out cards with newer revisions as the OEM always maintained this path would be kept compatible. I have not used an earlier revision replacement strategy. I am reasonably confident that using a GD to replace a GH will be OK. I see nothing in the PROM directory definition files or in IO configurator that would indicate any prospective issues. Has anyone had a similar experience or can offer some indicators on the probability of success before I start off on this path?
 
Many thanks CSA - I like your statement of the obvious, and you are perfectly correct, however the owner will no doubt have a completely different take should it "not work". I have heard that there is an OEM document which advises that the last two revision letters on MKV cards the GD and GH for example on the cards in question offer backward compatibility. Is this something you are aware of. I've searched the documents I have but have not found this indicated in any.
Best regards
 
TheGingerBeer,

I don’t have any such documents in my possession, nor can I recall any documents which specifically dealt with backward compatibility of cards. GE’s position was always to replace like either like (so to replace GD with GD, or to replace GH with GH), or to replace like with newer, so the replace GD with GH. They certainly didn’t recommend replacing GD with FA.

In this situation, if the don’have And can’t obtain a GH but do have a GD and the socketed PROMs (the ones with the paper labels with DCC, etc., I would personally try installing the socketed chips from the GH card on to the GD card, setting the hardware jumpers on the GD to match the GH and install the GD in the processor.

If there is great fear and trepidation on site, I would suggest the unit be OFF COOLDOWN, and the racking out all motor starters and then powering down one of two remaining control processors. You will need <C> to be powered up to communicate with the new card, and often I found that <C> required one of <R>, <S> or <T> to be at A7 to communicate with an HMI—which is why I would suggest having one of the two “good” control processors running, but not both of them.

I would then power-up the processor and begin with setting the processor ID and restarting the processor (from the <PD> core). I would then use the EEPROM Downloader to download FORMAT to the new DCC/SDCC card and re-start the processor again, from the <PD> core. Then I would download USER to the new DCC/SDCC card paying attention to the messages on the HMI display as each partition finished downloading and noting any error or warning messages. If the USER download completes successfully, restart the processor from the <PD> core and if it goes to A7 that would be a very good sign.

At that point I would start looking at Diagnostic Alarms for any “unusual”
alarms and trying to understand and resolve them. If there aren’t any “unusual” Diag. Alarms I would then power up the last control processor, and look through all Process- and Diagnostic Alarms for unusual alarms.

At this point, if all processors are at A7 then it’s pretty likely the Mark V will be complaining about the unit not being ON COOLDOWN. Use Logic Forcing to convince the Mark* the unit has finished the required cooldown period, and then select COOLDOWN OFF from the HMI; any Cooldown-related Process Alarms should be able to be cleared from the Alarm Display.

Start racking in the motor starter breakers; if everything is relatively good with the alarm situation AND the unit does NOT try to go on Cooldown or IS NOT trying to be on Cooldown, most of the motors should not start or run when the HOA switch is placed in the A (AUTO) position.

At this point, clear any erroneous Process- and Diagnostic Alarms. Then I would try to put the unit ON COOLDOWN, and if that's successful for several cooldown cycles, then I would attempt a CRANK operation. If that's successful, at that point it might be worth trying a FIRE operation (all you have to do is select FIRE while the unit is CRANKing, and if the manual fuel isolation valve upstream of the fuel stop valve is open, the unit should attempt to light off/fire. If after a few minutes of FIRE operation every thing seems to be okay, then just select AUTO mode and the unit will accelerate to FSNL. After a few minutes at FSNL if everything looks okay and there are no unusual alarms (Process or Diagnostic), you can either synch the unit or shut it down (I would suggest a normal fired shutdown at this point, just to make sure the unit goes into a fired shutdown and then goes ON COOLDOWN automatically).

In my personal opinion, there probably isn't that much difference between a GD and a GH--the "major" group number ("G") is the same, and the minor group numbers ("D" and "H") aren't that far apart. The difference is probably just some different components which should not greatly affect operation, if at all. I wouldn't try this by replacing a GH with a DG--uh-uh; no way. But, GH to GD, the worst thing I can imagine by using the above procedure (or something similar that slowly and methodically and logically brings the Mark* back on line and does a series of low-level operational tests before firing, all the while paying very close attention to alarms (Process and Diagnostic) and sequences, should be all that's required to catch and control any unusual or unanticipated occurrences. Someone should remain close the E-Stop Push-button at all times (just to be on the safe side--probably not required, but still a good idea), and maybe even have someone near the manual fuel isolation valve as a further precaution. (I'm only recommending all of this because it sounds like someone at site is uncomfortable with using a GD to replace a GH; and if there ain't no GHs available and the objective is to get the unit running--well, this is probably going to be the best way to accomplish this.)

As for the Timers & Counters question--there are ways around that. In my experience, at some point in the 24 hours or so following installing the new DCC/SDCC card and its EEPROM chip, the voting that takes place amongst the processors over the DENET will most likely automatically update the GD EEPROM Timer & Counter values to be the same as the other processor. And if not, who really cares; it's certainly NOT going to work the other way (the zeroes in the GD EEPROM aren't going to be written to the other control processors--they would be outvoted (SIFT and all that!).

In my personal opinion, this is most likely a safe swap--but, I have been wrong in the past and I will be wrong in the future. The only way to know for sure is to try it if there aren't any GH cards available and the unit needs to start and run. I don't believe the GD card is going to be able to do any harm to any other processor--they are all independent, and use voting when sharing data for control and protection purposes. Yes; some of the DENET comm's probably are done on the DCC/SDCC card--but even for forward compatibility there has to be some symmetry of protocol.

Tell the individual(s) to grow some hair and logically and methodically put the card in service. If not, they can just wait. It's as simple as that.

Best of luck!

I need to go find a Super Bock--or three.
 
Top