Mark V DCC online replacement eventuality

Dear All

After going through a lot of documentation and threads in the forum, I have an inquiry about the possibility to change a Core (in a TMR Configuration ) while the unit is online.
As far as I am concerned the Mark V does not have the luxury of making Online hardware changes. but when it comes to the Core DCC replacement for example. as per the well know procedure. we need to upload TOTD, turn OFF the Core replace the board, power up again, change the voter ID reboot and download for the Core to reach A7 ( I know I am going very fast with the steps).
Now lets suppose the following :
At any moment a TMR Mark V panel is online and Core S DCC is out of service. hence, the whole Core is offline and subsequently TCEA Y due to the loss of IONET S. Theoretically the unit should not trip as long as the other two Cores are healthy respectively.
Furthermore, If we replace the DCC card and follow the above procedure. at the moment the Core reaches A7, eventually, will it be operational again and all its Inputs/outputs will be enabled or NOT?
If so, cant we consider this as an online replacement feasibility?

Looking forward for your replies.
Regards
 
Dude,

You have a VERY special talent. You have confused several things here, and I thought we'd already gone over replacing DCC/SDCC U9 EEPROM chips which precludes downloading and rebooting. If I recall correctly, you chose not to replace the U9 chip in you hypothetical question/post.

So, what's this all about? AND you're talking about on-line changes--we suppose that means I/O configuration changes or sequencing changes, and, yes--that's not possible. But that has nothing to do with replacing a DCC/SDCC.

A Mark V core is the metal enclosure for ALL of the I/O cards housed inside--the door opens to reveal the plastic card carriers which the 8-1/2" x 11" I/O cards are held in place. The <PD> does not have a plastic card carrier. The only card with a daughter board is the DCC/SDCC which has the LCC/SLCC card, and the keypad and LED display for the processor. <C>, <R>, <S>, <T>, <P>, <CD>, <QDn> and <D>, if the panel is equipped with a <D> processor, are the cores for a TMR turbine control panel. The <PD> power distribution module is also often referred to as a core.

You are correct--if the machine being controlled and protected is running and any one of the control processors (<R>, <S>, <T>) has a card failure requiring replacement (only the I/O cards can be replaced while the unit is running--terminal boards can only be replaced when the unit is shut down). For the control processors they communicate with their respective TCEA cards in <P>: <X>, <Y> and <Z>. When a control processor is powered-down it will also shut off the power to it's respective TCEA (so for <S> that would be <Y>). And, yes--the unit will not trip, presuming the other control processors are healthy and communicating with their protective processors and the respective protective processors are also healthy and not trying to trip the turbine then unit will not trip. That's because two of the control processors are not trying to trip the turbine, and two of the protective processors are not trying to trip the turbine. There have been many "drawings" of the trip scheme for a Mark* V showing the protective processor (primary) trip relays and the emergency (protective processor) trip relays in a two-out-of-three scheme for both the primary trip relays and the emergency trip relays. They were derived from the Signal Flow Diagrams in Appendix D of the Mark V Application Manual, GEH-6195 (I think that's the pub number).

[By the way, the respective TCDA card(s) for the protective processor that is powered-down will also be powered-down.]

If it were me, I would not upload the TOTD partition. Because when the processor is powered-up and has the correct Voter ID AND the EEPROM has been properly formatted and the USER partition has been downloaded--the Totalizer Data will automatically be updated to match the Designated Voter's Totalizer Data. AND, if you don't upload the TOTD partition to the right file and someone tries to download TOTD (or ALL) later, it has the potential to overwrite the Totalizer Data and cause big problems.

And here's the procedure (if you don't change the U9 EEPROM chip:

1) Install the new DCC/SDCC card after checking to make sure all of the socketed chips are properly inserted and all of the ribbon cables are firmly seated and the LCC/SLCC card and keypad/display are all properly seated and secure.

2) Power-up the control processor and if the U9 EEPROM chip was blank, the LCC/SLCC display will begin to cycle through a couple of I/O States repeatedly, I think it's A1 and A2, or something like that. At that point, use the LCC/SLCC keypad to set the Voter ID; if successful the LCC/SLCC display should momentarily flash OK FINE or something like that to indicate it was successful.

3) Then download the FORMAT partition to the DCC/SDCC U9 EEPROM chip and wait to see the download finishes with no warnings or errors.

4) Turn off the power to the control processor and wait about 30 seconds.

5) Turn on the power to the control processor and when the LCC/SLCC display cycles through a couple of I/O States repeatedly (the A1 and A2, probably), then download the USER partition to the control processor and WAIT for it to complete with no error messages or warnings. THIS IS VERY IMPORTANT: Even if the processor goes to I/O State A7 after the download is complete and before the reboot--it is NOT a true I/O State A7. To achieve a true I/O State A7 (meaning the respective TCEA protective processor AND the respective TCDA card(s) have downloaded the I/O Configuration with the proper I/O Configuration during their boot-up) it is ABSOLUTELY NECESSARY to re-boot the processor (DCC/SDCC and all respective I/O cards, including the TCQA/B/C) to get the necessary information from the U9 EEPROM chip since it was downloaded to.

6) Turn off the power to the control processor and wait 30 seconds.

7) Turn on the power to the control processor and after a couple of minutes it should boot to I/O State A7.

When the control processor reaches A7 it will start writing to its outputs and there is sometimes a slight upset in load (a dip or a spike) when this happens but everything should be okay. (My personal preference is to not do this while the machine is running at full (Base) load just to lower the chances of a possible trip when the outputs suddenly all start working again.)

8) Check and clear/resolve or understand ALL Diagnostic Alarms.

9) Jump up and down with joy.

If you removed the U9 EEPROM chip from the previous DCC/SDCC card and installed it properly in the socket on the new DCC/SDCC card and the hardware (Berg) jumpers on the new card are in the same positions as those on the old card, when you initially power-up the processor it should go to A7. That's because the Voter ID will already be set, and the I/O configuration and sequencing and all the other EEPROM partitions will be what they were before the old DCC/SDCC card was removed. No setting Voter ID, no downloading FORMAT and rebooting, no downloading USER and rebooting. And, because of the way all of the processors are set to match the Designated Controller's voted value of Totalizer Data about every 60 minutes (not ON the hour, but in a rolling 60 minute period) the Totalizer Data will be updated to match the voted value of Totalizer Data without uploading/downloading TOTD (and possibly causing unintended knock-on problems in the future).

Can we stop with the hypotheticals? If you have a question, or questions, just ask them.
 
Dude,

You have a VERY special talent. You have confused several things here, and I thought we'd already gone over replacing DCC/SDCC U9 EEPROM chips which precludes downloading and rebooting. If I recall correctly, you chose not to replace the U9 chip in you hypothetical question/post.

So, what's this all about? AND you're talking about on-line changes--we suppose that means I/O configuration changes or sequencing changes, and, yes--that's not possible. But that has nothing to do with replacing a DCC/SDCC.

A Mark V core is the metal enclosure for ALL of the I/O cards housed inside--the door opens to reveal the plastic card carriers which the 8-1/2" x 11" I/O cards are held in place. The <PD> does not have a plastic card carrier. The only card with a daughter board is the DCC/SDCC which has the LCC/SLCC card, and the keypad and LED display for the processor. <C>, <R>, <S>, <T>, <P>, <CD>, <QDn> and <D>, if the panel is equipped with a <D> processor, are the cores for a TMR turbine control panel. The <PD> power distribution module is also often referred to as a core.

You are correct--if the machine being controlled and protected is running and any one of the control processors (<R>, <S>, <T>) has a card failure requiring replacement (only the I/O cards can be replaced while the unit is running--terminal boards can only be replaced when the unit is shut down). For the control processors they communicate with their respective TCEA cards in <P>: <X>, <Y> and <Z>. When a control processor is powered-down it will also shut off the power to it's respective TCEA (so for <S> that would be <Y>). And, yes--the unit will not trip, presuming the other control processors are healthy and communicating with their protective processors and the respective protective processors are also healthy and not trying to trip the turbine then unit will not trip. That's because two of the control processors are not trying to trip the turbine, and two of the protective processors are not trying to trip the turbine. There have been many "drawings" of the trip scheme for a Mark* V showing the protective processor (primary) trip relays and the emergency (protective processor) trip relays in a two-out-of-three scheme for both the primary trip relays and the emergency trip relays. They were derived from the Signal Flow Diagrams in Appendix D of the Mark V Application Manual, GEH-6195 (I think that's the pub number).

[By the way, the respective TCDA card(s) for the protective processor that is powered-down will also be powered-down.]

If it were me, I would not upload the TOTD partition. Because when the processor is powered-up and has the correct Voter ID AND the EEPROM has been properly formatted and the USER partition has been downloaded--the Totalizer Data will automatically be updated to match the Designated Voter's Totalizer Data. AND, if you don't upload the TOTD partition to the right file and someone tries to download TOTD (or ALL) later, it has the potential to overwrite the Totalizer Data and cause big problems.

And here's the procedure (if you don't change the U9 EEPROM chip:

1) Install the new DCC/SDCC card after checking to make sure all of the socketed chips are properly inserted and all of the ribbon cables are firmly seated and the LCC/SLCC card and keypad/display are all properly seated and secure.

2) Power-up the control processor and if the U9 EEPROM chip was blank, the LCC/SLCC display will begin to cycle through a couple of I/O States repeatedly, I think it's A1 and A2, or something like that. At that point, use the LCC/SLCC keypad to set the Voter ID; if successful the LCC/SLCC display should momentarily flash OK FINE or something like that to indicate it was successful.

3) Then download the FORMAT partition to the DCC/SDCC U9 EEPROM chip and wait to see the download finishes with no warnings or errors.

4) Turn off the power to the control processor and wait about 30 seconds.

5) Turn on the power to the control processor and when the LCC/SLCC display cycles through a couple of I/O States repeatedly (the A1 and A2, probably), then download the USER partition to the control processor and WAIT for it to complete with no error messages or warnings. THIS IS VERY IMPORTANT: Even if the processor goes to I/O State A7 after the download is complete and before the reboot--it is NOT a true I/O State A7. To achieve a true I/O State A7 (meaning the respective TCEA protective processor AND the respective TCDA card(s) have downloaded the I/O Configuration with the proper I/O Configuration during their boot-up) it is ABSOLUTELY NECESSARY to re-boot the processor (DCC/SDCC and all respective I/O cards, including the TCQA/B/C) to get the necessary information from the U9 EEPROM chip since it was downloaded to.

6) Turn off the power to the control processor and wait 30 seconds.

7) Turn on the power to the control processor and after a couple of minutes it should boot to I/O State A7.

When the control processor reaches A7 it will start writing to its outputs and there is sometimes a slight upset in load (a dip or a spike) when this happens but everything should be okay. (My personal preference is to not do this while the machine is running at full (Base) load just to lower the chances of a possible trip when the outputs suddenly all start working again.)

8) Check and clear/resolve or understand ALL Diagnostic Alarms.

9) Jump up and down with joy.

If you removed the U9 EEPROM chip from the previous DCC/SDCC card and installed it properly in the socket on the new DCC/SDCC card and the hardware (Berg) jumpers on the new card are in the same positions as those on the old card, when you initially power-up the processor it should go to A7. That's because the Voter ID will already be set, and the I/O configuration and sequencing and all the other EEPROM partitions will be what they were before the old DCC/SDCC card was removed. No setting Voter ID, no downloading FORMAT and rebooting, no downloading USER and rebooting. And, because of the way all of the processors are set to match the Designated Controller's voted value of Totalizer Data about every 60 minutes (not ON the hour, but in a rolling 60 minute period) the Totalizer Data will be updated to match the voted value of Totalizer Data without uploading/downloading TOTD (and possibly causing unintended knock-on problems in the future).

Can we stop with the hypotheticals? If you have a question, or questions, just ask them.
I do not know why but you remind me of CSA with your approach of replying to threads. I am wondering if you are his replica lol.
Any way thank you very much for your reply. Again you ticked all the boxes so far.

You are right, I am a hypothetical person, If I go through understanding something, I start making scenarios of problems or troubleshooting steps and test myself with it. besides, several times I used to give few courses to colleagues about GT Speedtronic control basics. and often I am being asked questions where I need to post a thread to get a proper answer.
My apologies if this approach bothers you....

And Yes, Our discussion with the U9 replacement choice was insightful but I did want to stick with the traditional procedure while writing my hypothetical question.

Now, If I go back to your answer. You have mentioned Quote "(only the I/O cards can be replaced while the unit is running--terminal boards can only be replaced when the unit is shut down). Unquote
I assume you are referring to the TBs which provide hardware connection to all types of redundant input and output signals to all Cores ? (TBQA, TBQC, TBQB, TBQD, PTBA). but when it comes to QTBAs of any Core or Core C terminal boards, If a TB presumably becomes faulty, I suppose it can be replaced online. Please correct me if I am mistaken.

Looking forward for your reply.
Regards
 
Do you know how to spell assume? (I learned from a CSA post). ASS-U-ME. When one assumes something it makes an ASS of U and ME.

I was referring to ALL I/O terminal boards without exception. It might be possible to power-down a <C> or <D> and replace its I/O terminal boards but in my experience I/O assignment mistakes are always possible and can lead to unanticipated trips. And since cooldown I/O is usually connected to <C> if the unit trips then it won't go on Cooldown.

And if <C> is powered down the HMI won't work--unless there is a <D> and it's working properly.

I'm not CSA's clone, and I'm pretty sure CSA wouldn't like the comparison. He was trying to pay back a good deed; I'm not and have little patience for many younger posters who aren't trying to learn something and just want a simple answer with no effort on their part. I'm flattered, Isulamu, but it has already worn off.

Best of luck with your hypotheticals.

Over and out.
 
Do you know how to spell assume? (I learned from a CSA post). ASS-U-ME. When one assumes something it makes an ASS of U and ME.

I was referring to ALL I/O terminal boards without exception. It might be possible to power-down a <C> or <D> and replace its I/O terminal boards but in my experience I/O assignment mistakes are always possible and can lead to unanticipated trips. And since cooldown I/O is usually connected to <C> if the unit trips then it won't go on Cooldown.

And if <C> is powered down the HMI won't work--unless there is a <D> and it's working properly.

I'm not CSA's clone, and I'm pretty sure CSA wouldn't like the comparison. He was trying to pay back a good deed; I'm not and have little patience for many younger posters who aren't trying to learn something and just want a simple answer with no effort on their part. I'm flattered, Isulamu, but it has already worn off.

Best of luck with your hypotheticals.

Over and out.
WOW!!!

Best Regards,
CTTech
 
Do you know how to spell assume? (I learned from a CSA post). ASS-U-ME. When one assumes something it makes an ASS of U and ME.

I was referring to ALL I/O terminal boards without exception. It might be possible to power-down a <C> or <D> and replace its I/O terminal boards but in my experience I/O assignment mistakes are always possible and can lead to unanticipated trips. And since cooldown I/O is usually connected to <C> if the unit trips then it won't go on Cooldown.

And if <C> is powered down the HMI won't work--unless there is a <D> and it's working properly.

I'm not CSA's clone, and I'm pretty sure CSA wouldn't like the comparison. He was trying to pay back a good deed; I'm not and have little patience for many younger posters who aren't trying to learn something and just want a simple answer with no effort on their part. I'm flattered, Isulamu, but it has already worn off.

Best of luck with your hypotheticals.

Over and out.
According to the Oxford Learner's Dictionary To Assume is to think or accept that something is true but without having experienced it. Hence do not put yourself on a high horse with your assumption of the ASS-U-ME.

Me too I was referring to the C Core TBs and most importantly to the QTBAs which are dedicated TBs where if we are lucky enough. we can replace them online. Anyway, I am not lucky since the mighty Mark V panel is not in front of me otherwise I would not be posting this thread or asking for knowledge share for the one who has.

Fortunately, Back in to 2015 I was not sell short with such defamatory comments and feedbacks otherwise I would be still a younger poster in this forum...But I think a younger poster better than an imposter.

Ultimately, thanks again for your technical contribution at least.

Good luck with your impatience.
 
Top