SCANNERS
There are two scanners, the hand held (bargun) scanner and a fixed-mount scanner built into the slitmask stage assembly. These scanners could fail in one of three ways:
If the bargun stops working it is worth inspecting its coil cable at both ends, to see if either connector has come loose. Otherwise, the scanner wiring is probably not something you want to spend time fooling with when you're trying to get the instrument ready for observing.
Failure of the active scanning components, i.e. the laser and the onboard ROM (dumb as it is) is not fixable except by swapping in an identical spare which at present we don't have. However, these are industrial scanners designed and built for a long lifetime under warehouse conditions, and we don't expect them to die any time soon.
Of the three failure modes, the last one (dispatcher dead or hung) is the easiest to fix. Here is how to diagnose and intervene.
First, log into keamano as the user 'kics'. You will not be able to fix dispatcher problems otherwise.
The bargun dispatcher is known as dispatcher.bargun and the dispatcher for the fixed-mount mask scanner is known as dispatcher.barco. You can use the standard deimos commands such as
To check out the bargun, scan the "TEST CODE" affixed to the instrument near the connector for the bargun on the cradle. If the bargun can't be got to beep when you scan this code, you've got a hardware problem and there's little hope. If you do get a beep out of it, use a 'show' command to read the keyword:
show -s deimot BARGNGET
If this 'show' command hangs, or if you get garbage back, restart the dispatcher with deimos restart dispatcher.bargun, and try the scan again.
To check out the mask scanner, try reading the ROM version back from it:
show -s deimot SLBARCFG
The result should be slbarcfg = DNBRLMAAB . If it is scrambled or the command hangs, restart the dispatcher with deimos restart dispatcher.barco and try the command again.
The most common failure mode is for one of the dispatchers to get confused and hang or die. This is very easy to fix if you follow the above diagnostic procedured. Once you have got both scanners "talking" again, you should be able to proceed with automatic configuration.
If you insert a filter into the filter wheel and then try to scan it immediately afterwards, you may find that dremel doesn't accept the scan. The usual reason is that the filterwheel has been knocked off its unload position by your wrestling with the filter holder on its way in. This is one reason why it's faster and easier to load all the filters first and then scan the whole wheel quickly.
Similarly you may find that when scanning one position after another, you get a failure if you don't wait for the wheel to settle into the final unload position. Wait until the LED indicates that motion has stopped, and the scan-and-recognized operation should work.
Probably the worst thing that could happen to you is that the summit database server might break. This hasn't happened in almost 3 years of ESI operation, but it's within the realm of possibility. If this happens, we have to fail over to the server in Santa Cruz or get the summit server back on its feet. Either of these alternatives will require expert assistance from the DEIMOS team on the mainland, so this would be a good time to start making phone calls. But before you panic, how can you tell if the summit server is OK or not?
If the database server isn't there, then check on the machine 'waiaha' on the summit network. Can you ping it? If not, it looks like a hard crash -- call Jon Chock, Julia Simmons, or Liz Chock. If waiaha is there, try this command on polo:
isql -Uguest -Pharmless -SKSUMMIT
You should get a prompt that looks like this: isql>
If you do, then type Control-D to get back out of isql.
If you get a hang or an error message, report this ASAP to Julia, Jon, and De (de@ucolick.org).
de@ucolick.org