MK5 Diagnostic alarm 0035

MK5 Panel with one diagnostic alarm on (R ) core.

0035 DCC EEPROM TABLE CHECKSUM.

From diagnostic alarm list the following is advise

CAUSE : A bad checksum was detected for the EEPROM
EFFECT : Core powers up in default mode with control function disabled.
ACTION : Check from (I ) as to which EEPROM table has the bad checksum and download correct table.

Would appreciate any advice on the "action" and were to check the EEPROM tables as suggested and any other actions that could be taken to resolve this alarm.

Tried clearing the "system errors" as a start without effect and reluctant to jump in and re-boot the processor as yet with regard to the info suggested in the EFFECT.
 
topcat123,

I believe the Mark V Maintenance Manual, GEH-5980, has information on the various options of the EEPROM Downloader. You can use the EEPROM Downloader to view and compare check-sums, I believe.

Or, just type:<pre> EEPROM /?</pre>or<pre> EEPROM HELP</pre> for a quick explanation of the various options and parameters/sections of the EEPROM and the EEPROM Downloader.

(But, the manual has better information, if I recall correctly.)

Please write back to let us know how you fare.

Finally, when did this Diagnostic Alarm start?
 
Found the command under EEPROM DOWNLOADER> CHECK T1 R. This ran the checksum program for all TABLES on R.

It revealed that on 7th Feb 2011 there was BAD CHECKSUM on TABLES "SEQ" and "CONST".

Would downloading SEQ and CONST to R and rebooting that core be enough to clear this diagnostic?
 
topcat123,

This Diagnostic Alarm has been annunciated since 2011? ;-)

I don't know of anything else to try. Short of replacing the DCC/SDCC, because if the Diagnostic Alarm can't be reset--either from the operator interface or from the LCC/SLCC keypad, then downloading would be the next thing to try.

You have to be sure that you are downloading the same SEQ and CONST that are in use in <S> and <T>..... You can compare the file date/time stamps and checksums with <S> and <T>.

You can redirect the output of a "DOS" command (IDOS or TCI in this case) to a text file using this command syntax:<pre>EEPROM CHECK T1 R > R_CHECK.TXT</pre>

You can use whatever file name and extension you wish, and you can do this for any command-line executable and options. Then you can open the text file later with an ASCII text editor, and even print it. It will appear as if nothing is happening when the command with the redirect executes, but if you search for the filename you specified it should be there.

Hope this helps!
 
> I couldn,t believe it also when I arrived. 2011!

should have said that I ran the Checksum on S AND T also and the download for SEQ and CONST was performed at the exact same time and date. But those results were "ok".

Ploughing thru a comparison of the CONST_Q.SRC and control constant adjust to see if anything has been changed in EEPROM but not saved.

Then will do a "Download" for CONST,SEQ again for all three processors.
 
There used to be a file comparison program called BeyondCompare, and it was very useful in finding differences between files--and easy to use. I don't know if it's still available.

Some ASCII text editor programs that coders (programmers) use can also do file comparisons. UltraEdit is one such program--very powerful, and I don't know if they have a trial program (it's not freeware or shareware).

You may find after all of this that it's necessary to replace the DCC/SDCC card.... Sometimes it's cheaper to just swap the card than to spend a few days trying to make sure you're not going to cause more harm than good with a download.

Best of luck--and let us know how you fare!
 
There's also the DOS command <pre> fc</pre>If you can't find another program/application, fc can always be used to compare two ASCII text files. If there are few differences, it's a very fast method of comparison.
 
Unfortunately didn't see your last replies before my last actions.

After checking for constant differences and finding all ok, I then did a EEPROM download for CONST AND SEQ and rebooted the processors. R processor only made it to A4 status. I have the LCC IO states on an excel but nowhere on this site to upload.

Anyway as you say it all points to the DCCQ which was at status 00. I swapped the SDCC/SLCC card from S to R and it booted fine to A6. Just need the Voter ID changed and would have went to A7.

So now having to obtain a spare SDCC/SLCC card.

Would you advise any options with reformatting R eeproms. Could I do an UP from R to save the Totaliser data? Then Format and download the TABLES individually after format or would you say its best to wait for a new card, swap the prom chips and download USER?
 
topcat123,

While the EEPROM chip can be moved from one DCC card to another, since that was the "source" of the original alarm I would recommend not doing so. The new DCC should come with a blank EEPROM, but I would first recommendingX setting the hardware jumpers on the new to the same positions as the old card, moving the PROMs from the old cared to the new card, and mounting the LCC card on the new card and installing it in Loc. 1 of <R>, reconnecting all the cables, then applying power, and then setting the StageLink and Voter IDs and rebooting <R>. When communication is established with <R>, then download FORMAT and REBOOT <R>, then download ALL and reboot <R>. I believe the voted values of totalizer data will overwrite whatever was downloaded to <R> (in an hour or so!) and then all should be good.

If you wanted a "back-up" for the totalizer data you can upload it from either <S> or <T> to a generic file (TOTD_Q.AP1) while you're waiting for the DCC card, and then it's saved and available for the ALL download.

People always say, "ALL includes FORMAT--why do a FORMAT and reboot, and then do ALL with FORMAT again?!?!" Because, FORMAT is like formatting a floppy or a hard drive, you want to be sure it's fully completed and there's nothing there (except the empty formatted partitions) when the ALL download is started. Yes, it's an extra step, it takes at least a whole extra 3.4 minutes, but it's a good precaution.

Best of luck!

I wonder . . . what would happen if one put the new EEPROM from the new DCC on the old DCC in place of the one that is bad, and then tried booting-up <R>??? I wouldn't do this unless I had quick access to another EEPROM chip in case the old DCC damaged the new EEPROM, but it could just be the chip is bad, and not the whole card. Just a virtual thought.
 
There is not a readily available spare DCC card.

With the redundancy of S and T do you think I will have any issues with starting the unit again before the card replacement.

I seem to recall that the redundancy only really works if the unit is already running and a processor is lost but may not be allow for start-up. To be honest no experience of ever having to try it as panels on the whole are quite reliable.
 
The Mark V will not issue a 'Ready to Start' indication (which means it won't accept a START command) unless all the processors are healthy and communicating.

<b>I >>DO NOT<< recommend doing this</b>, but if the unit MUST be started for power and/or steam, some adventurous and gambling people have found a way to force logic to allow the other processors to believe that all of them are healthy, thereby allowing a "Ready to Start'/START.

So, it's been done--but it's not recommended. Definitely not recommended--particularly if there are Diagnostic Alarms on the remaining processors which indicate problems that could result in erratic control. (And we're not going to discuss every other Diagnostic Alarm to facilitate this.)

The reason I'm personally against doing this or recommending this is because people--operators, technicians, supervisors, managers--already believe the turbine control system is "too" protective, and using Logic Forcing to permit ill-advised operation just reinforces their belief. The logic then becomes, "If it shouldn't be possible, then the control system shouldn't allow it--but if the control system allows it, then what else could be bypassed?!?!"

I'll grant the control system designers should not have allowed some logic to be forced but I will also argue they didn't believe many people would actually try forcing some signals and would instead believe problems should be troubleshot and resolved and cards replaced to restore normal, recommended operation.

Sure; if there aren't any other Diagnostic Alarms on any of the other processors which would lead to possible erratic control--then sure. But each one of us knows the Diagnostic Alarm messages are cryptic at best, and the Help available for them is lacking and cryptic, also.

It's a decision for managers to make--and one they should not make lightly and if it works without any problems they should consider themselves extremely lucky and not push their luck in the future (meaning they should not be continually testing their luck with such measures in the future).

Because, sooner or later, luck always runs out.

There's a saying, "I'd rather be lucky than good!" But, that should always be accompanied by, "The harder I work, the luckier I get." which translates to the more I understand all of the possibilities the more I understand--and can possibly mitigate reduce)--the risks and can make better decisions about what risks to take, and what ones not to take.

Again, those who have done this have either understood and mitigated the risks to the extent possible (because they understood all the possible outcomes), or they were just very, very lucky. And, again, luck is never guaranteed to continue for any length of time.
 
Just wanted to put what resolved this issue.

A simple EEPROM UP R ALL to the (i) followed by an EEPROM DOWN R ALL. Then a reboot of the processor and back to A7. No loss of TOTD data.

regards
Topcat
 
To solve this issue could be enough only EEPROM DOWN R ALL.

If there is an alarm DCC EEPROM TABLE CHECKSUM it is not good idea to perform command EEPROM UP because some data in the EEPROM most likely are wrong (that is the reason why checksum is wrong).

This problem can appear if some cells in the EEPROM become degraded due to time and can not keep the programmed data for a long time.
Performed command EEPROM DOWN R ALL just refreshed those cells.

If you will have the same problem in the future then I advice to replace this EEPROM (X28C512P or similar) by new one. Also, the existing EEPROM can be tested with using some parallel programmer (for example Xeltek) in the various operation modes.
 
Top