SctRodDaq/CoolTools, and
SctRodDaq/SctApi
(2) Recompile
(3) In the OKS database, look at the command line options for SctApiCrateServerXXX? (or whatever you call the process running SctApi at present on the SR1 system) and make sure that the following debug option are set or unset appropriately:
Do *NOT* set: "dont_monitor_link_masking"
*DO* set: "pretend_link_masking" if you don't have any
modules attached, or if you think that the modules that *are*
attached are not likely to trigger any masking events. If
you are in real physics mode, try leaving this off to record
"real" maksing events.
(4) Fire the software up, and move through the run states, as high as you can (preferrably to "running" though I suspect that going to "configured" will be sufficient) and then back down again. I don't think it is necessary to have any modules powered ... though it will be necessary to have some modules in the configuration. While things are running, make a note of the name of the machine and name of the working directory in which the SctApiCrateServer? is running. (Visible in one of the PMG panels if you don't already know this info)
(5) Shut things down.
(6) ssh to the machine that ran the SctApiCrateServer?, and CC to the working directory that the SctApiCrateServer? was running in. Look to see if the directory contains a file called "LMM_Test.db". If it does, this is superb! Send me the file! (If you are interested, you should be able to read its contents by issuing a command like:
$SCT_DAQ_ROOT/SCT/COOL_Test/allRead sqlite_file:LMM_Test.db/DUMMYDB /purple/pants
which hopefully will become
$SCT_DAQ_ROOT/SCT/COOL_Test/allRead sqlite_file:LMM_Test.db/DUMMYDB /SCT/DAQ/Conditions /LinkMaksMonitoring?/V-0-0-1
in the not too distant future.
(7) Remove the "pretend_link_masking" option (which you added in step three above) from the command line options of the CrateServer?, so that future users are not inconvenienced by its presence.