Reports 1-1 of 1 Clear search Modify search
AdV-COM (AdV commissioning (1st part) )
swinkels - 0:34 Saturday 27 May 2017 (37764) Print this report
IMC systematically unlocking after the interferometer
Looking into some issues with the FMOD_ERR, I found that the IMC is surviving the unlock of the interferometer in most cases, but is systematically unlocking a few seconds later, see attached figure. It seems that the SSFS is correctly switched off, but something fishy is going on with the correction sent to the MC end mirror. I find at least line 450 of ISYS_Acl suspect, which calculates a flag for the MC DPS (0 = Control by RFC, 1 = CARM2MC, 2 = SSFS, 3 = SSFS+Boost):

ACL_OP_CH IMC_LOCK_SW "V" "sum+" MC_LOCK_ON SSFS_LOCK_ON SSFS_BOOST_ON

It seems that MC_LOCK_ON and SSFS_LOCK_ON do both correctly go to zero at the moment of the unlock, while SSFS_BOOST_ON, which is derived from the channel SSFS_B4_selectFilter in SSFS_Ctrl, only goes to zero a few seconds later (when metatron detects the unlock?). The result of this is that the MC DSP thinks we are still using CARM2MC, so it is sending all the junk from the unlock to the MC mirror for a few seconds, which causes a huge kick. This bug costs maybe half a minute for every unlock of the interferometer, since it sometimes triggers the alignment instability of the IMC. It was probably also the cause for an issue with the FMOD_ERR macro, which did not check for an unlock of the IMC, so it sometimes started a measurement while the IMC was still recovering from the unlock. Fixing this should be trivial, but I leave it to INJ/SSFS experts for fear of messing up the complex logic.

Something else curious is that SSFS_SelectFilt0 is not zero but a very small number. This might be an artifact of the decimation, but if this channel is used to reset the filter when it is equal to zero, it might never do the reset. To be checked by the experts.

Images attached to this report
Comments to this report:
bersanetti - 18:14 Wednesday 31 May 2017 (37814) Print this report

Both the MC_LOCK_ON and the SSFS_LOCK_ON flags are generated as products of the manual switches and the global LSC.ENABLE switch, so they follow the fast unlock trigger and go to zero immediately when an unlock occurs; the SSFS_BOOST_ON flag, on the other hand, is based on the B4_SelectFilter SSFS switch, which we do no operate directly on: the cm command that we use for engaging the SSFS boost talks directly to the DSP. If I'm not mistaken, the B4_SelectFilter flag is 'attached' to the DSP object in Acl and it receives the information about the filter bank change from the DSP. It gets reset to 0 by the CARM_DARM_LOCK Metatron node, but this is probably too slow, also because any cm command is executed at an integer second.

As a test, I modified the logic in ISYS_Acl so that the new SSFS_BOOST_TRIG flag is the logical product of the old SSFS_BOOST_ON and SSFS_LOCK_ON, which is tied to the fast unlock trigger; a more clean solution would be to send the fast unlock trigger to the SSFS_Ctrl process, but the results should be identical (actually, with the 'ugly' solution we spare 1 sample in communication between processes). In the figure there is an example of unlock, and this effect now seems cured; I'll collect some more statistics over time to confirm it.

Images attached to this comment
Search Help
×

Warning

×