MOOT Status, 16 Sept. 2005

Database

Version 1 of table design was completed around Sept. 1. The tables have been created in a test database, but are so far unused.

Parameter description

Made some progress last week (before being overtaken by ACD screws); see the xml description of all delegates and their parameters and a more compact description of just those involving LATC-controlled registers.

Order of implementation

I've been making choices all along, of course, of what to concentrate on first. For example, I have stayed away and will continue to stay away from final, detailed definition of those parts of MOOT depending on other facilities which are themselves undergoing rapid change until such time as it seriously interferes with my progress.

More recently I've been concentrating on the LATC part of the configuration. The current description of LATC-controlled parameters is meant to be approximately complete. It still is subject to small changes as LATC itself changes, but nothing that would affect database design or code in MOOT. The immediate goal will be to understand and implement everything MOOT needs to do for LATC parameters. It may be that PIG-related parameters will have to be handled at the same time in order to end up with something which is usable. Included in that "everything" are:

• Settle on some definition of parameters which is at least complete. All LATC-controlled registers (e.g., as defined in James' lrd files) should appear in some parameter. It need not be the final word on how they are partitioned.
• Come up with provisional place to keep these files. Whatever needs to access them should be using the database to figure out how to access them, so if we decide to keep the files somewhere else later, it shouldn't cause great consternation.
• Define format of all associated parameter files. Typically this will be LATC-style xml; either something which may be directly input into LATC or a fragment which, when merged with a known set of other parameter files, will produce syntactically correct LATC input.
• Design something to do merging in at least a couple cases.
• Gain experience using LATC to create a binary. Is this even done by invoking LATC directly or is it handled by FMX? TDB.
• Handling of master config file. Is database organization adequate? What's its format and who generates it? Implement something which either writes it or knows how to invoke some other service to write it.
• There are plenty more items that go here...

What is missing (and will be, even when the list above is complete) is handling of other kinds of configuration, such as that which is input to LCI, or the parameters for the Filter. For the most part this information will be simpler to deal with than LATC input, but there are likely to be some surprises.

Input needed

There are a couple things I need to understand better or, before long, I'll be stuck:

• The telecommands relevant to MOOT's task: uploading files, selecting a particular part of the configuration from among alternatives which have already been uploaded, and any separate commands used to verify that these activities have occurred. What are their inputs and outputs? Under what circumstances are they given? With what frequency?

• How minor are the minor modes? That is, should ToO, ARR, and Physics be lumped together, or treated as three independent modes by MOOT? Since ARR is entered independent of any communication with Ground, all configuration information associated with it must already be available and Ground only discovers it has been entered after the fact. My guess at this point is that MOOT should not consider ARR to be a separate mode. For ToO it's less clear but, as long as the pieces of the configuration differing for ToO versus Physics are well-defined and not very numerous, I would be inclined to lump all three together.

  Similar question for calibration. Is it considered a change of mode when we cease calibrating CAL and start on TKR?

Things MOOT won't do (but which need to be done somehow)

By design the data for a single parameter must be destined for a single binary, but in reality information in one parameter may need to be maintained consistently with information in another, with a different destination. Ideally one would like a tool for each such collection of related parameters, to guarantee that the files for any related set are consistent, preferably by creating them in a single operation. An example of this occurs in the Timing delegate: the tack_delay field of the tkr_trgseq register is in one parameter and trg_align is in another because they end up in different LATC-created binaries, but their values are closely tied. What's needed is something upstream of MOOT which will create both parameter files for a single source of information.

Another sort of upstream tool would be useful for setting some threshold registers. The goal may be to set them all to some identical value measured in physics units, like energy, but because of differences in the channels the actual values set into the registers will vary. The collection of these values should be generated by tool whose inputs are the desired energy and appropriate calibration information for the channels.