May 10, 2001 F. P. Schloerb LMTMC Status ============ Many new features have been added to the system since the run in December. This required some rather significant changes to code in operation at that time. I was able to bring up everything that was formerly in operation (except the Long Delay) in the new system. (I have worked out a few remaining bugs at home on my simulator). The LMTMC system is not static ... we are about to bring up another significant advance with error trapping and reporting. We are also planning to add new features to the OT script writing to enable embedded scripts in the release following that. Finally, we are working on a tool for dealing with source catalogs. Redesign ======== I redesigned several of the objects in the system to make them smaller and more self-contained. For example, the single object Telescope in the December version was broken into three pieces: TelescopeModel (which handles the geometrical calculations for the mounts); TelescopeTracker (which handles the trajectory being tracked by the telescopes); and Telescope Controller (which handles commands to the telescopes). I make use of the new ability of the LMTMC system to manage arrays of objects in the design of these things. There is also a new way of dealing with interactions between the OT and the various control loops running on the VxWorks system, which involves use of a command-response handshake. All of the redesigns make this system much easier to deal with, at the cost of having more "objects" to interact with. However, the latter problem can be dealt with in a number of ways for the final system: Making "iterator" objects which manage the behavior of groups of objects; Extending the OT script writing so that you can embed scripts (to e.g. turn on all the devices in the system; or do a full initialization for that matter) in your own personal observing script. I think more things with fewer command options is better than a few things with lots of command options.... New Stuff ========= I added the spiral searcher for the telescopes, and we were able to do some fine tuning. I think the thing now (after some more work on the simulator) functions well. Now all we have to do is get the star tracker to report that it finds the star .... I added the offsets for the siderostats generated by the star tracker. Unfortunately, the tests of this were not successful. Likely problems: (1) the star tracker is not producing the right offsets; (2) the formula Mark gave me is wrong; (3) I don't understand how these are supposed to be used to control the telescopes. It is pretty easy for sign problems to occur at all steps of the transaction. This can probably only be debugged adequately at the telescope with a star tracker expert sitting next to me (or my representative .....). I think this might also work "over the phone" from my office.... Stuff that needs to be done =========================== The key next step is to complete the interfacing of the code written by John, Ettore, and Rafael into the rest of the system. This can proceed in two stages: (1) write xml config files that produce a shared memory struct which matches the handwritten ones so that we can interact with the new code through the shared memory; (2) incorporate the machine generated code into the new application and (possibly) restructure the new code to make its components smaller and easier to deal with. Stage 1 is very easy, but does require some interaction between those who wrote the application and those creating the interfaces. Stage 2 is more time consuming and requires an understanding of both the OT system and the actual application. I believe that the star tracker code should get a rather careful going over fairly soon. I think it is too big and complex. We need to have a better understanding of the expectations for the other parts of the system. We should try to make the protocol for interacting with the star tracker loop match that used elsewhere in the system. We need an interface and display for the star tracker through the MT/OT system. We can set parameters in shared memory now. The next step is for someone who knows what the critical parameters are to look at the control panels and make suggestions about design. We also need to be able to display the star tracker images. This is now "straightforward" but does require a little java program to be written by hand. While we are at it, we could also add some custom control features to the java program that does the display (if I knew what those were.) I have not looked at the data acquisition code, so I won't make any comments here. The first step (see above) is to define a shared memory struct for the OT that matches the handwritten one so that we can set parameters and make displays. I have not worried much about the details of what will go on what panel for display to the observers. We can improve this very rapidly once the basic system works, but for now things are a little crude. Perhaps we should have a workshop looking at the simulator to discuss what information needs to be put on what panels etc.