The C-plot path was fixed to allow fit functions to be compiled.
Macro files have been updated and checked: see macro notes. Still to be written:
To avoid having to type the stepper motor record field values back in with the MEDM utility, a Spec macro was written to read the fields using epics_get(), and write out a Spec do-file with epics_put() commands which will write the fields back into the Epics database.
In the process, a few debugging macros were written. These macros are contained in sem_util.mac (sem stands for spec,epics,motors). This macro file is not yet included with the other macros since it needs to be tidied up first.
Some, but not all, of the motor fields were saved for all three crates using this utility. The restoring files for B hutch motors are 9idb_fourc.sem and 9idb_surf.sem. The Spec config files take care of the Spec mnemonics and channel assignments upon switching configurations.
The previous run reported a problem in which Spec would stop talking to a particular motor, for which the only fix was to move the motor in the Epics screen. I was able to reproduce this problem by requesting a motor motion (in Spec) smaller than the deadband (RDBD). This field specifies a small interval in degrees or mm, within which Epics will not try to move the motor. Apparently one version of the Epics motor record does not reset the "done moving" flag DMOV back to 1 after this instruction, and so Spec is still waiting for it.
The short term fix is to make sure the deadband is set to correspond to one step (this field was a larger value for many motors). We might consider automatically setting RDBD based on the motor resolution in a new version of the macros that read the configuration parameters back in. Meanwhile, the Epics record will be updated and Spec will also be changed to handle this situation without hanging.
We also found that a "reconfig" command was necessary in Spec after changing a motor resolution parameter (MRES, UREV, or SREV). This is due to a bug in Spec, which was not monitoring the appropriate field to catch this change on the fly. Spec is being fixed. Meanwhile, use reconfig after changing motor resolution.
One more note, count times are limited to 214.748 seconds since CMC is using 10 MHz oscillators for the time base and scalars with 32-bit counters. If there's a demand for longer count times (what?!) these can be replaced with 1 MHz oscillators.
The float glass mirror was very rough, leading possibly to some problems in tracking the spectrometer. Ben brought another mirror from BNL and reports focussing to 0.25mm beam height and 80% reflectivity.
We also noticed large vibrations of the beam as viewed on camera. CMC might consider moving the turbo pump in the SOE, which is currently cantilevered from the wall on a trianglur unistrut brace above the flight path, with a flexible baffle feeding vibrations straight to the mirror tank. It might be better to put the pump back on the floor, on some kind of vibration isolation, and feed the baffle through something heavy like a padded concrete block, to avoid vibrations of the mirror.
For part of the experiments, we tried out the high energy range of the monochromator. Up to 19 or 20 keV, using the third harmonic of the undulator, the beam position was steady, but we couldn't get past 20 keV without the beam running off the mono in some direction. So, the energy region above 20 keV still has to be explored. But I worked for a few days at 19 keV and was satisfied with the behavior. We did find the monochromator got a bit warmer during this part of the run, and think that since the crystal positions were moved slightly, that some of the beam may have been hitting the invar holder rather than the Si crystal.
Computer access and accounts are beginning to get uncomfortable. Perhaps some less draconian policy regarding remote access can be arrived at. It is also getting crowded for all users to log on as 9idp and keep files in the same account. I realize that there are issues such as security and remote access to the FOE motors, and that more PCs are planned to allow users to store and manage files. I think this should become a priority. Some careful thought also needs to be given to the configuration of each beamline, regarding which crates each computer has access to and which devices live in the various Spec configuration files, to avoid experimenters at different stations moving each others' motors.
The first problem encountered was that the instrument sits too high too be centered on the beam with the mirror out. This is partly due to the fact that the design included wells in the floor to fix the positions of the spectrometer feet. Whether such wells will be created depends on where the spectrometer might have a permanent or partly permanent location. Since the alignment is so time consuming, it sounded like a good idea to give it a home, say in the front of the 9ID-C hutch. But it's not clear whether there is enough room for another spectrometer to run behind it, or whether users could be prevented from using the LSS as a table to toss tools onto.
Mechanically, the instrument is working very well. At first, there were difficulties in tracking, which seemed like they were due partly to instability of the beam, partly possibly due to the rough mirror, and partly due to the last few motors whose parameters had not been optimized. As of today (19 Nov 99), reflectivity measurements are underway. These measurements are sensitive to small losses of position when moving eleven motors at a time, which is what we're now discovering. This memo will be finalized at the end of the commissioning run.