May 09, 2001
M. G. Lacasse

Long Delay Line Tests
=====================

Tests of the Long Delay control system were performed in late April.
These used the new automatic server process loading which Petar
implemented.  We found that Marc's normal way of booting up the system
(with the motor controllers and the metrology laser off) resulted in a
non-functioning control system.  The system would retain the memory of
the laser signal being weak and this error state would not reset when
the units were homed or indexed.  The long delay could be moved in
absolute mode with only motor pulse counting but not with the servo
mode where the position was compared to the position determined from
the laser signal.  If the laser was allowed to be on and providing a
good signal and the motor controllers were on before the server code
was loaded, a manual load (./srv1, ./srv2) or a reboot of the ldelay
computer would result in an operational servo mode.

These tests were run with the delay line quadra.  Attempts to repeat
these tests with the Ultrix-10 system were hampered by the code
development and then by the hacker attack which disabled the ldelay
computer for a week.

April 19, 2001
R. Millan-Gabet

Long Delay Test
===============

(from an email to Petar)

Today's test was done using the Quadra as the client. We could not try
running the client from the SUN because it was the victim of a hacker
attack earlier in the week.

These are the "problems" we found:

1- When we reboot the server with the laser off, the software never
recovers and it is not possible to run in servo mode. It only works when
reboot is done keeping the laser power on.

(You may look at the /var/log/boot.log for any interesting boot messages)

Is it possible to fix this? There may be reasons why it is not safe to
have power to the motors and laser when rebooting.

2- When the system is operating correctly (either because we started the
scripts manually after turning on the laser, or because we rebooted
keeping the laser on) the system *does* recover from blocking the laser
signal. However, this is only true after re-indexing. I guess this is
allright ... is that what you intended in your code?

By the way, the error message you get if you don't re-index after blocking
the laser is: "command structure has wrong size". That is the same message
you get if you try to servo-move after rebooting with the laser off (as in
1 above).

Other more minor comments:

a- We still get the "command error" message everytime the client starts.
I don't remember the status of this bug, maybe Mike Brewer was supposed to
fix it ...

b- I noticed that we still have multiple kernels in /boot, from when we
were trying to have one work with the disk-on-chip. The default one
is "original" and it seems ok. Would you recommend some housecleaning 
here?

c- What is the status of your instructions on how we should backup and
recover the linux box? I forget now, but I think the last we discussed was
that you could not make the external cdrom bootable ... do we have a new
plan?

We will try the same experiments soon (next week) using the SUN client,
and let you know how that goes.