For about a week now, the lock acquisition starts with 12 W of input power, then when reaching CARM Null the power gets increased up to around 17.5 W, profiting of the several gain servos to cope with such increase for most of the main control loops.

Today the automation of the procedure has been written and saved in the nodes files: it involves both INJ_MAIN and ITF_LOCK, but this is still offline and the nodes should not be loaded yet.

This new procedure involves no new states, but just internal logic and a new file, INJ_MAIN.set (ITF_LOCK.set will follow shortly, for different topics but the same philosophy), which takes inspiration from a similar concept used in the SQZ_FLT node. The main point is two-fold:

• configuration files like we use them can be written by the nodes, but this can be dangerous if one has the file open and re-saves it, if the editor doesn't prompt quickly enough that the file has changed on disk; additionally, writing them from the nodes the way we do completely wipes out comments, which can be very annoying;
• global variables in the automation are reverted to the default declaration value when the node is loaded, as they are read back from their definition that can be out of the states; this can be annoying for state flags that need to be remembered from lock to lock; additionally, they now get to be visible in a file at all times, instead of being hidden in the code running online in RAM.

Therefore, the idea is to use INJ_MAIN.set only for parameters written by the automation itself (or to debug it or to force a specific behaviour), and not for general parameters like the ones in the .ini files. The one related to the power increase is inj_power_state ([POWER] section): given that we plan to increase the power in two big steps (and then a finer open loop tuning), such flag can be 0, 1 or 2, depending if we are respectively at low power (12 W), intermediate power (only one coarse increase) or full power (two coarse increases, the finer tuning is not important here).

Here is what happens:

• when we unlock, INJ_MAIN will go to DOWN and check such flag: if 0, nothing will happen (we should be at low power already); if 1 or 2, the node will perform 1 or 2 coarse reductions of power (5000 steps each), each time updating the parameter in the file; then, the INPUT_POWER_TUNING state will deal with the fine tuning down (or up) to 12 W, as usual but with a new logic;
• ITF_LOCK: towards the end of LOCKING_CARM_NULL_1F, in two distinct places separated by at least 15 s, two coarse increases of power will happen (-5000 and -4500 steps respectively), the inj_power_state variable will be updated, and then the fine tuning to the target power (17.5 W) will happen, by having ITF_LOCK asking INJ_MAIN to use the same INPUT_POWER_TUNING state but in a very different place of the acquisition: the new logic of the state acknowledges the power state and either targets the lower power (when it reads 0) or the higher one (when it reads 2); the same check will condition using one or the other set of parameters; to avoid killing the lock, the number of maximum attempts to tune the power in CARM Null is much higher than the one we use in DOWN.

The new logic will start to be tested tomorrow.