1) sg3 slits: I think you are already aware of the issue, but just in case I will re-iterate what we notice. At some point one of the blades on the sg3 slits was not moving properly (I think the sg3vgap top blade). I am pretty certain this is a communication issue not a mechanical issue, since the blade was 1mm off even though I was moving in 100 micron increments. It may be related to moving the slit blades too fast, which Michael did warn us not to do. When we hit the syncV and syncH buttons on the epics panel, and restricted our motion to 1s intervals this problem went away. However, perhaps it would make sense to figure out how fast the slits can go and then build this delay into the epics record somehow. One second move time seems rather arbitrary. If, for example, the slits work ok for ½ second it would be nice to know that so that all the scans could go twice as fast.
2) Stanford research amplifiers: We had some problems with adjusting the offset on the Stanford research amplifiers. At one point the offset on the pind4 amplifier would not allow itself to be changed. We tried all possible values up to 100 micro-amp offset, and so no difference. Finally we swapped amplifiers between pind4 and the pdbs and this seemed to fix the problem. Perhaps I once saw this problem with the pdbs amplifier as well. I think this is an epics record problem.
3) Beamstop. We had to modify your beamstop to put a lead block over the end so that we could get to smaller Q. The present design has the problem that the wires for the beamstop block part of the pattern. You probably shouldn’t leave our lead tape on there permanently since it could fall off. Perhaps you should make a permanent fixture with a triangular shaped block which would allow a wide angular access at small Q.
4) USAXS: We were particularly happy that we could get down to Q’s of around 6e-4 inv. ang. To do this we had to use the sg1 as the defining slit set to 100 microns, the sg2 as a trim slit set to 200 microns and the sg3 as a second trim set to 250 microns. This gave a beautiful, slit scatter free pattern down to within 4 pixels of the beam zero. We could not do this using just the sg2 and sg3’s. (I think they are just too close together)
5) MAR: The MAR worked really well. We did notice, however that there was a slight pattern in the upper central quadrant, which might have been burned in beamstop pattern from previous experiments. Also everyone seems to be leaving data on that computer. There needs to be a system to tell people to get rid of old data, and perhaps there should be a bigger hard disk. (20 gig is too small nowadays). It might be perfectly adequate (since the camera has a 3-sec readout anyway) to set up the computer to remotely mount one of the beamline disks.
6) Macros: The ccdmarseries macro doesn’t do what it is supposed to do. The camera control still opens the shutter for the dark images. I know that the common belief is that you don’t need to take darks for the MAR, but how accurately has that been tested? The fact that we could see this residual image makes me a little nervous. I certainly think it would be nice to at least have the option of measuring darks. Also, the macros for the mar at present do not mesh with the macros we use for the standard SAXS data collection macros on the I-station. Thus, you can’t set up (easily) to do a beam intensity normalization between frames, to automatically move the sample, and to dump a batchinfo file with the proper parameters. This would be nice to have. Finally, I wrote a ccdmarnewfile macro, which in the local_macros directory in case you want it.
7) Analysis software: The guys from NU were able to use the Igor based software without too much difficulty. However, it is a bit tedius to do angular averaging, since there is no equivalent to the automatic partitioning along phi which is done in Matts coherent software. I made a custom version of “coherent” that can read the mar files and do data analysis. This works, but still needs to be neatened up. I will try to improve the code and see if there is an easy way to integrate this with the main version of the software.
8) Limit switches: At one point we hit a limit switch on the samy motor. It was not possible to back of this limit except by cranking the motor by hand. This seems to me to be a bug in the epics motor record. It should allow you to move in the opposite direction of the motion limit when a limit is triggered. We can’t be the first person to have come across this issue, so there is probably a fix out there if you just know who to talk to. |