Maybe due to the real-time model update (klog27894), CPU over load occured when we engaged {D,C}HARD_Y loops and PRFPMI lost lock.
Now, we cannot reach PRFPMI_RF_LOCKED state, so please do not request PRFPMI_RF_LOCKED state to LSC_LOCK guardian until the issue will be solved.
I will try to fix the issue but If you want to use IFO before that, please use PRFPMI_TRANSITION_TO_1FSIG state.
[Yamamoto, Ushiba]
We found the exact reason why PRFPMI cannnot be locked with ASC: it is not due to CPU load but the problem in C code of the real-time model.
Somehow, ISC_Y signals send to 16th bit of BO instead of real BO signal and change the coil driver setting when VIS model obtained ISC_Y signals from ASC, BPC, and ADS models.
So, we could not use any alignment controls with ISC_Y signals including initial alignment, and please do not use ISC_Y controls until fixing the bug.
Figure 1 shows the generated C code of a part of k1visetmxp before (left) and after (right) fixing the problem.
As shown in the highlight line, the input to the 16th bit of bit2word was "sum4" instead of a proper input signal. "sum4" is a summation of yaw contorl signals from ASC, ADS, and BPC. And the 16th bit is assigned to switch the coil driver input as Drive-In or Test-In for the control signal on 4-9 pin. So the model-compile script generated a very nice code which disabled the output to one coil when yaw control signal became non-zero value.
I tried to modify the conversion script from the matlab code to the C code as shown below. After this modification, real-time models were re-compiled and worked fine.
--- Bit2Word.pm.bak 2016-11-09 09:33:17.000000000 +0900
+++ Bit2Word.pm 2023-12-09 18:25:19.000000000 +0900
@@ -75,7 +75,7 @@ sub frontEndCode {
for (0 .. $::partInCnt[$i]-2) {
$calcExp .= "\t$::fromExp[$_],\n";
}
- $calcExp .= "\t$::fromExp[$partInCnt[$i]-1]\n";
+ $calcExp .= "\t$::fromExp[$::partInCnt[$i]-1]\n";
$calcExp .= "};\n";
$calcExp .= "\L$::xpartName[$i] = 0;\n";
$calcExp .= "for (ii = 0; ii < $::partInCnt[$i]; ii++)\n{\n";
