D. Barker, J. Garcia, J. Kissel
At the request of the ISC team (see LHO aLOG), we installed the standard QPD readout scheme,
${userapps}/isc/common/models/QPD.mdl
part into the L3/Test Mass level of the QUAD's generic library part
${userapps}/sus/common/models/QUAD_MASTER.mdl
in order to make the optical lever readout more transparent (because the signals used to be processed inside a bit of c-code).
In addition, we hooked up the IPC from the alignment signals to the ITM (where they had only been installed in the ETM up to today), inside
${userapps}/sus/h2/models/h2susitmy.mdl
Important notes for others:
- I've filled out the OL2EUL (OpticalLever to EULer) matrix in accordance with Thomas' investigations and LLO's precident. However, there's still a good bit of work to do to get the pitch and yaw singals into some sensible units. For, there's a gain of 1e-6 in the OPLEV PIT and YAW filters, so that the values coming out of the bank are not ridiculously huge.
- I'm not sure the Saturation or the Divide blocks are functional yet (used in the standard QPD block). With no 1e-6 gain, merely taking (S1+S3)-(S2+S4) shows values of order 1e10 to 1e11. Last I checked [(~4000 + ~4000) - (~4000 + 4000)] / (~4000) was of order 1.
- Adding the inter-process communication between ISC and the ITM required adding the appropriate IPC channels to the h2iscey.mdl, which I compiled, but did NOT install or restart. I'll leave that up to the discretion of others.
Details
-------
Simulink Model Work:
In todays work, we modified (and svn committed)
${userapps}/sus/common/models/QUAD_MASTER.mdl
${userapps}/sus/h2/models/h2susitmy.mdl
${userapps}/sus/h2/models/h2susetmy.mdl
${userapps}/isc/h2/models/h2iscey.mdl
During the compilation process, the RCG threw us a few curve balls just to keep us on our toes:
- As one passes a signal down into sub-blocks -- even though Simulink allows it -- the input and output bubbles can't be named the same thing or else the compiler throws an error claiming the blocks involved are not connected. The assumption is that the parser collects the first instance of the input/output bubble name, makes the appropriate connection, but then skips all other instances with the same name, therefore "not connecting" it.
- If you add "receiver" IPC parts, you have to name it a full channel name and that channel name has to match one in the IPC list,
/opt/rtcds/lho/h2/chans/ipc/H2.ipc
which is generated by the sender models during *their* compilation process. If you put an non-existing channel name in there, the compiler throws and error claiming that there're unexpected characters found before character ";" on lines (x,y,z), because instead of barfing that the channel doesn't exist, it merely fills in nothing, so you end up with a "channel = ;" sort of thing in the resulting code.
We've removed the optical lever power monitor from the master model, which prior-to-this-update was taken and used by the c-code. With the c-code gone, that monitor singal is no longer needed. It should be readout by someone eventually though. Perhaps we'll still it in with the monitor models eventually.
Because we're stuck with whatever names the filter blocks have in the QPD.mdl libary part, we had to change the stored optical lever framebuilder channels to
$(IFO):SUS-$(OPTIC)_L3_OPLEV_PIT_OUT_DQ 2048
$(IFO):SUS-$(OPTIC)_L3_OPLEV_YAW_OUT_DQ 2048
$(IFO):SUS-$(OPTIC)_L3_OPLEV_SUM_OUT_DQ 256
(and note that we also can't have L3_OPLEVINF's any more. These filters are now named L3_OPLEV_SEG[1,2,3,4]). The goal is to have these be the channels which are calibrated into physical units.
Added optical lever chain to
${userapps}/sus/common/medm/quad/SUS_CUST_QUAD_OVERVIEW.adl
and created a few new screens
${userapps}/sus/common/medm/quad/SUS_CUST_QUAD_L3_OPLEV.adl
${userapps}/sus/common/medm/quad/SUS_CUST_QUAD_L3_OPLEV_SEGS.adl
${userapps}/sus/common/medm/quad/SUS_CUST_QUAD_L3_OPLEV_MTRX.adl
which are shown in the attached screenshots.
