Today is...
Monday, November 20, 2017
Welcome to Control.com, the global online
community of automation professionals.
Featured Video...
Featured Video
EtherCAT with CTC’s master lets your multivendor network play well together...
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
Mark V <R> Freeze on A4_93% - DCC Error
After range updated and downloaded, and cores rebooted. <T, S> cores at A7 but <R> is not progressing beyond A4 - 93%.
By Hasan Abduillah on 8 November, 2017 - 12:09 am

After range update, the change downloaded to <C,R,S,T> in order and cores rebooted. <T, S> cores proceed to A7 but <R> is not progressing beyond A4 - 93%.
DCC Error is given but no diagnostic alarm is coming up.

Further inspection shows that on <R> Voter ID is not defined.

Associated <X> does not have the first LED on the left ON continuously whereas it is ON for <Y, Z>.

Please advise the way forward as no diagnostic is present.

Hasan Abduillah,

Hmmm.... So, a EEPROM Download was done. And, somehow, <R> lost it's Voter ID. That's not normal.

You need to use the procedure in the Mark V Maintenance Manual, GEH-5980, to set the Voter ID on <R>, then re-boot <R> (using the switch in the <PD> core for <R>). If <R> does not go to A7, I would suggest using the EEPROM Downloader to download ONLY the FORMAT partition to <R>, and then re-boot <R> (using the switch in the <PD> core for <R>). Then, when <R> is powered-up and goes to A4 (which it will because FORMAT erases the memory on the EEPROM chip), use EEPROM DOWN USER to download the remaining EEPROM partitions to <R>. And, even if <R> goes to A7 during or after the download of USER--re-boot <R> (using the switch in the <PD> core for <R>) and it should go to A7.

If <R> does not go to A7 then you're going to have to use the procedure in GEH-5980 to troubleshoot why <R> is not going to A7--in other words, which I/O card is preventing <R> from going to A7. It involves using the LCC keypad display to scroll through the various I/O States for the I/O cards associated with <R>.

The problem with <X> is likely related to the inability of <R> to recognize it is <R>. You may also need to re-boot <X> (using the switch in the <PD> core for <X>). Once you get <R> to A7, <X> should be able to get it's information from the EEPROM on <R> when <X> is re-booted and it should allow <R> to get to A7.

Please write back to let us know how you fare in resolving the problem.

If you have spare DCC, try to replace DCC Card (with old EEPROM). If the problem is gone it means the problem comes from the card. If the problem exist it is possibly from your configuration, follow GE Procedure just like CSA said.