
Some changes in front end Pisa box support implemented recently:

1)  Settings are BUFFERED by the front end.  Your setting request
    gets an immediate response; the voltage is actually adjusted
    in the fullness of time.  This means that your application can
    shovel up settings as fast as it wants.  It may even set many
    (e.g. 40) channels per batch, without pausing between batches.

2)  The front end retries on ~Q.  You should never see a ~Q error
    in your console application any more unless it is meaningful.
    There is no longer a reason for the application page to retry
    on ~Q.

    Note: if the Pisa box is not responding, or the serial cable
    is unplugged, then the green Camac Pisa controller eventually
    gives Q and yields a bogus data value of FFFF (hex).  The front
    end intercepts that value and produces a ~Q error code.

3)  Polling goes somewhat faster, close to the limit that the
    hardware can support.  I have measured the rate at 400 ms to
    500 ms per channel.  It works out to about 130 seconds for
    a six Pisa box string.

4)  Reading-the-setting returns the last value you set for that
    channel.  (Previously, reading-the-setting returned the reading.)
    After reboot, reading-the-setting returns zero.


Some issues and possibilities:

1)  Right now, the setting command obtains a "success" status, even
    though the setting hasn't actually happened yet.  We COULD return
    a positive status (e.g. 18 1 or 18 2) in response to a setting
    command.  (Nigel has suggested this.)  My feeling is that
    "success" is better because page D1 restore files are looking
    for a "success" status, but I am flexible.

2)  Similarly, reading-the-setting returns a number which is updated
    as soon as the setting command arrives.  It might be a long time
    before the Pisa box is actually set.  We COULD return a funny
    status in such cases.  Even better, we could negate the setting
    value if it hasn't been transmitted yet--so you would see both
    the absolute value of the voltage and an indication that the Pisa
    box isn't up-to-date.

3)  It might be interesting, for both Pisa boxes and SVX Power
    Supplies, for the front end to obtain (at bootup) the last setting
    values.  (This is not a project which you would be heavily
    involved with.)

4)  If we implement 3), then it would be possible to have Pisa box
    alarm tolerances keyed to the last setting value.  In other words,
    you could specify a range (e.g. -5 V to +3 V), and we would use
    the last setting value as the nominal value.

5)  An even more advanced feature: we can update the Pisa box settings
    as they drift.  If a channel drifts, here are two possible front
    end responses:

    a) Re-send the last setting, in the hope that it will
       bring the channel back to its proper value.
    b) Use a PID loop (or something more stunted) to try to
       regulate to the setpoint.

    Boris is an expert on closed loops, plain and fancy.

    I have no idea how small changes in these voltages affect the
    physics.  I could readily believe that changing one channel by
    one volt results in no detectable difference (oops--a pun), but
    I could believe at the same time that frequently updating many
    channels by small amounts would introduce randomness.
