AO Miscellaneous

msgd/rtdb

clients

the message daemon (Msgd for short, I guess that's what you refer to) maintains a list of variables, similar to what the TCS data dictionary does. Lots of information like the current AO loop state (open, closed, paused) and other loop parameters can be found there. In addition, the TCS subsystem AOS copies a subset of these variables to the TCS DD.

The list of AOS variables is in the AOS guide, document 481f301e.

If instead you want to interface directly with the msgd, there are both C/C++ and Python interfaces available. There isn't an user manual for those as far as I know.
The C library is called "thrdlib": https://github.com/LBTO/ao-supervisor/blob/master/lib/base/thrdlib.h
The Python one is "thAOApp": https://github.com/LBTO/ao-supervisor/blob/master/PyModules/AdOpt/thAOApp.py
Examples for the C library can be found in the Tester directory: https://github.com/LBTO/ao-supervisor/tree/master/Tester

Both allow you to connect to the msgd, read variables, be notified in case some of these variables change, etc.
We don't have a comprehensive list of which variables are present in the msgd. The best option is probably to find some GUI or other interface that already displays what you need, and look into the code to see which Msgd variable corresponds.

• Sometimes peer connection from one daemon to another will fail, but the individual daemons work OK. This means that you can access a variable by directly connecting to the peer (e.g. "ADSEC.L.M2C", connected to sxadsec), but not by specifying the host (e.g. "ADSEC.L.M2C@M_ADSEC", connected to soul-sxwfs). This can usually be fixed by restarting the message daemons. I've put a script in soul-sxwfs:~/scripts/test_m_adsec_connection.py that will try to read a variable from M_ADSEC and give an error message if it fails.

viewer

we have a GUI called vartool_AO.py and pompously named "Variable inspector" on the engineering panel

config files

Actually for operation only a few of these files are needed. There is a big configuration table (https://github.com/LBTO/ao-confcalib/blob/49a5fb616d8fb5314bcd8142cfba300bd5fd907c/calib/wfs/W1SOUL/ao/table_LUCIFER_ACE-AO.txt) that contains the YYYYMMDD to use in the column "pupils". It's usually one for each ocam mode, so four different ones. Then there three or four tables: the standard one, the "badseeing" one, the ARGOS and TTM-AO one. Typically they use the same pupils... but the table contents must reference a directory that is available on disk.

There is one python script, "aotable_sanitycheck.py", that checks whether all the files required by the standard AO table exist. It could be a starting point for something complex.