We received the following two alarms:
D_3663_C Voter mismatch <S> Q_S_FDBK10
D_3656_C Voter mismatch <S> Q_S_POS19
Troubleshooting 101, what did you touch last? 24 hours prior to this alarm showing up, we had a contractor test our Chemtron CO2 system. They simulated all alarms, did a puff test, and tested other various things. This should have not caused the above issue, but this was the only thing that was touched on the system before the alarm came up.
After looking into the two alarms, I realized they stemmed from Regulator #10 on <S> Core from the TBQC card. When I opened up the prevote screen, under the signal names: Q_S_FDBK10 and Q_S_POS19, I noticed <R> Core was around -10 , <T> Core was around -10, and <S> Core was saturated at 128. Since we do not use regulators 9 through 12, nor have any signals terminate on that card in those positions, we ignored the alarms for a bit since we were in a week outage and had more pressing issues.
Our control system is a Mark V TMR.
On <S> Core, TBQC goes to TCQF for regulators #9 - #12. We do not use these.
On <R> Core, TBQC goes to TCQA for regulators #1 - #8. Standard for the gas valves.
The issue never really became a problem until the end of the week when we went to go auto calibrate the gas valves prior to introducing gas back into the system. The secondary gas valve, Regulator #6 Type 43, that terminates on <R> Core TBQC and goes to TCQA was having issues. It would not calibrate and I would get the following fault message:
"NOT REACH 50% TOWARD + SAT. WITHIN 5 SEC."
I had another worker go out to the valve to visually monitor the valve as I stroked it manually to various positions. I was able to stroke the valve at all positions at the required measurements.
Earlier this year we replaced the moog servo regulators and verified the stroke measurements by using a dial indicator. They all checked out just fine. Every year we measured the stroke and in my three years, we never had to adjust and the measurements were always just about spot on. We had atleast 100 runs, if not more, with the new moogs installed and never had an issue.
I have attached three videos of what happens during the autocalibration process.
Below is a list of what I have tried already:
1. Took voltage readings on <S> TBQC Terminal 5 + 6 and had -2.4VDC and -2VDC. Again, nothing is terminated on this. This appeared to be rail voltage of an OP Amp and I thought that may be backfeeding from the terminal card to the board. I disconnected the ribbon cable (JFS) from <S> TBQC that goes to TCQF. That seemed to make the -10 values on <T> and <R> and they went to -25 but <S> core still was at 128 for POS19 on the prevote screen. With that said, it kind of proved to me that the issue lies within a terminal card, possibly the circuitry has a short in it.
2. I removed the ribbon cable (JUUS) from <S> TBQG that runs to TCQF. No change.
3. I removed 3PL from TCQF and <S> Core. No Change.
4. Replaced TBQC on <S> Core, no change.
5. Checked LVDT excitation voltage on all valves on QTBA <R> Core, all LVDTs metered around 7 VRMS. As we stroked the valve, we also metered the excitation voltage and no drop.
6. We disconnected each cores servo output from each respective QTBA card for regulator #6 and stroked the valve to all positions by ONLY using one core. Each core was able to fully stroke the valve without issues. This proved that servo current is good for each of <R> and <S> and <T>.
7. We had reconnected <R> and <T> servo outputs on QTBA and tried to perform an auto calibrate and we would still have <R> and <R> fail on auto calibrate.
8. We hooked up three multimeters in series with each cores QTBA servo output on the secondary valve and monitored current. Tested good.
9. I replaced TCQF on <S> core but our reconditioned TCQF card was defective. I had to swap back to the old TCQF card and a new one is on order.
10. I had another worker physically look at the valve as it went into all of its position and again, no issues. It was able to travel just fine. That ruled out any stop block issues, current issues, wiring issues, ect. I do not believe this valve has any physical issues.
11. Through I/O Configuration, I disabled regulator #10 on TCQF card, downloaded, and I was able to cure the 128 saturation issue, but the valve still had the same auto calibration issues. So this step proved to me that these two issues, voter mismatch and secondary valve not calibrating, are not related.
The only thing left on the list that I may do is change the TCQA card. I just cannot prove that this cards is the issue. There are no other signs that lead me to it. I would think that if TCQA had a problem I would get another alarm specifically for the secondary gas valve. But again, I get NO OTHER ALARAMS but the two I listed at the start of this.
Does auto calibrate use another set of reference setpoints vs. what I would enter for a manual setpoint?
I have a hard time believing that the secondary gas valve calibration issue is tied to the regulator 10 alarm issue but it is a Mark V so I am not throwing anything out. Has anyone has issues similar to this that could shed some light? I have spent more than two days trying to figure this out.
D_3663_C Voter mismatch <S> Q_S_FDBK10
D_3656_C Voter mismatch <S> Q_S_POS19
Troubleshooting 101, what did you touch last? 24 hours prior to this alarm showing up, we had a contractor test our Chemtron CO2 system. They simulated all alarms, did a puff test, and tested other various things. This should have not caused the above issue, but this was the only thing that was touched on the system before the alarm came up.
After looking into the two alarms, I realized they stemmed from Regulator #10 on <S> Core from the TBQC card. When I opened up the prevote screen, under the signal names: Q_S_FDBK10 and Q_S_POS19, I noticed <R> Core was around -10 , <T> Core was around -10, and <S> Core was saturated at 128. Since we do not use regulators 9 through 12, nor have any signals terminate on that card in those positions, we ignored the alarms for a bit since we were in a week outage and had more pressing issues.
Our control system is a Mark V TMR.
On <S> Core, TBQC goes to TCQF for regulators #9 - #12. We do not use these.
On <R> Core, TBQC goes to TCQA for regulators #1 - #8. Standard for the gas valves.
The issue never really became a problem until the end of the week when we went to go auto calibrate the gas valves prior to introducing gas back into the system. The secondary gas valve, Regulator #6 Type 43, that terminates on <R> Core TBQC and goes to TCQA was having issues. It would not calibrate and I would get the following fault message:
"NOT REACH 50% TOWARD + SAT. WITHIN 5 SEC."
I had another worker go out to the valve to visually monitor the valve as I stroked it manually to various positions. I was able to stroke the valve at all positions at the required measurements.
Earlier this year we replaced the moog servo regulators and verified the stroke measurements by using a dial indicator. They all checked out just fine. Every year we measured the stroke and in my three years, we never had to adjust and the measurements were always just about spot on. We had atleast 100 runs, if not more, with the new moogs installed and never had an issue.
I have attached three videos of what happens during the autocalibration process.
Below is a list of what I have tried already:
1. Took voltage readings on <S> TBQC Terminal 5 + 6 and had -2.4VDC and -2VDC. Again, nothing is terminated on this. This appeared to be rail voltage of an OP Amp and I thought that may be backfeeding from the terminal card to the board. I disconnected the ribbon cable (JFS) from <S> TBQC that goes to TCQF. That seemed to make the -10 values on <T> and <R> and they went to -25 but <S> core still was at 128 for POS19 on the prevote screen. With that said, it kind of proved to me that the issue lies within a terminal card, possibly the circuitry has a short in it.
2. I removed the ribbon cable (JUUS) from <S> TBQG that runs to TCQF. No change.
3. I removed 3PL from TCQF and <S> Core. No Change.
4. Replaced TBQC on <S> Core, no change.
5. Checked LVDT excitation voltage on all valves on QTBA <R> Core, all LVDTs metered around 7 VRMS. As we stroked the valve, we also metered the excitation voltage and no drop.
6. We disconnected each cores servo output from each respective QTBA card for regulator #6 and stroked the valve to all positions by ONLY using one core. Each core was able to fully stroke the valve without issues. This proved that servo current is good for each of <R> and <S> and <T>.
7. We had reconnected <R> and <T> servo outputs on QTBA and tried to perform an auto calibrate and we would still have <R> and <R> fail on auto calibrate.
8. We hooked up three multimeters in series with each cores QTBA servo output on the secondary valve and monitored current. Tested good.
9. I replaced TCQF on <S> core but our reconditioned TCQF card was defective. I had to swap back to the old TCQF card and a new one is on order.
10. I had another worker physically look at the valve as it went into all of its position and again, no issues. It was able to travel just fine. That ruled out any stop block issues, current issues, wiring issues, ect. I do not believe this valve has any physical issues.
11. Through I/O Configuration, I disabled regulator #10 on TCQF card, downloaded, and I was able to cure the 128 saturation issue, but the valve still had the same auto calibration issues. So this step proved to me that these two issues, voter mismatch and secondary valve not calibrating, are not related.
The only thing left on the list that I may do is change the TCQA card. I just cannot prove that this cards is the issue. There are no other signs that lead me to it. I would think that if TCQA had a problem I would get another alarm specifically for the secondary gas valve. But again, I get NO OTHER ALARAMS but the two I listed at the start of this.
Does auto calibrate use another set of reference setpoints vs. what I would enter for a manual setpoint?
I have a hard time believing that the secondary gas valve calibration issue is tied to the regulator 10 alarm issue but it is a Mark V so I am not throwing anything out. Has anyone has issues similar to this that could shed some light? I have spent more than two days trying to figure this out.