Hello there,

We are trying to replace a SDCC or SLCC card with a new one in <T> Core of Mark-V. But when checked through CARDID, we find that firmware revision of the new card is not matching with that in the IOconfigurator screen, preventing the core from reaching A7.

What can we do?

[email protected]

 

gpk,

Your post is unclear.

What are the full part numbers of the SLCC and the SDCC cards (usually something like DS200SDCCGn or DS200SLCCGn)?

Every SLCC/SDCC isn't compatible with every Mark V. There are basically four versions of Mark V: A; Hybrid A; Hybrid B; B. There were different versions of LCC/SLCC and DCC/SDCC cards for each of the four versions, though hybrid versions did have some interchangeability. Unfortunately, GE is the only real resource to know 100% for certain....

When changing cards, did you move the PROMsets from the old cards to the new cards? Because, CARDID doesn't really identify cards--it really identifies PROMsets on cards.... (Isn't this fun?)

What does the SLCC keypad display when scrolling through IO States for each card?

Did you set the Voter ID when you replaced the SDCC (using the SLCC keypad/display)? I think CARDID will report erroneously if the Voter ID isn't set properly--but that's a vague recollection.

What error messages are displayed on the SLCC display when power is on?

Have you used the SLCC keypad to set the Voter ID of the new SDCC to <T>?

 

Dear CSA,

Here are the Part numbers of the cards that are being replaced:
DS200SLCCG3AFG & DS200SDCCG5AHD.

As reported by our site Engineer, they have set the Berg jumpers >as per the old card and also transferred the EEPROMs from the old card to the new one.

I shall try to get other details like configuring Voter ID and also the IO Status of each card as per LCC Display as well.

However I just want to know if it is possible to change the PROM revision on ioconfigurator in case of any mismatch from that displayed on HMI through CARDID.

gpk

 

gpk,

What are the card numbers of the cards being removed, as well as the card numbers of the new cards being used to replace them?

CARD_ID is NOT really a card identifier--it's a PROMset identifier. If you moved PROMs from the cards being replaced to the cards being installed then the revision numbers should not have changed. If you move a Rev. CB PROMset (Major Rev 3, Minor Rev 2) from the SDCC being replaced to the SDCC replacing it, the revision will still be CB (3.2). It can't be anything else if it was removed from the SDCC being replaced and installed on the SDCC replacing it.

Again, if the Voter ID wasn't set on the new SDCC card, I seem to recall that CARD_ID may not report the proper PROM revisions.

And, it should not be necessary to run CARD_ID when replacing cards (which involves moving PROMs from the card being replaced to the card replacing it)--because the revision will NOT change when it's moved from one SDCC to another SDCC.

When a DCC/SDCC card is replaced in a Mark V, it MUST have it's Voter ID set to match the processor the new DCC/SDCC is being installed in. This is described in the Mark V Maintenance Manual, GEH-5980, in the card replacement section. (If it's the DCC/SDCC in <C>, or <D>, then it must also have it's StageLink ID set--also using the LCC/SLCC keypad/display.)

Again--moving PROMs from one card to another does NOT change PROM revisions. And CARD_ID, despite it's name, does NOT report card revisions--it reports PROM revisions. (Yes, there are TCQA cards and TCQA PROMs, and TCDA cards and TCDA PROMs, and so on--but there's no IOMA card, yet there is an IOMA PROMset on DCC/SDCC cards and CARD_ID reports the IOMA revision level. CARD_ID is yet another extremely poorly named application/program in the GE Mark V suite of applications/programs, and it's function is NOT to report card revisions--but PROM revisions.

There are some card versions (newer versions of cards) that cannot be used to replace older versions of card--and CARD_ID won't help with that. Only GE can say for certain which cards can be used to replace which cards. IN GENERAL, a G3 can replace a G2 or a G1, but not always (again--GE makes this very fun!). I wish there was a document you could be pointed to to help with this issue, but I'm not aware of one or I'd point you to it.

I suspect the Voter ID has not been set on the new SDCC card, and CARD_ID is having problems interrogating the PROMs on the new SDCC card (which came from the old SDCC card--so the PROM version(s) did NOT change in the move!). Or, the PROMs weren't installed in the sockets correctly (wrong orientation; wrong position; bent pin(s); static discharge damaged the PROM(s); etc.).

Hope this helps!

Please write back to let us know how this is resolved!

 

Hi CSA,

Thanks for all the support. Finally we found that the voter ID of this core was wrongly set as <R> while it is <T> core. We have changed this to <T> and after that the core went only up to A4 and did not allow the EEPROM download. Error message pops out saying the partition information is not matching with that of the unit. We have formatted the EEPROMs (through EEPROM DOWNLOAD) and finally downloaded 'ALL' partition to the <T> core and rebooted the core. With this, we have succeeded to reach A7 status. Unit was also restarted and found everything was fine.

Thank you once again CSA and other group members for always being there.

 

gpk,

Thanks very much for the feedback!

Glad to hear your problem was resolved.