Re: Insertion Devices Control and EPICS

[Tim Mooney <mooney@aps.anl.gov>]

Rok Sabjan wrote:

> I'm trying to prepare a proposal for ID control system at Diamond. 


I want to back off a little bit and look at what an ID-control system
really has to accomplish.  This is a little bit long, so for anyone too
busy to go through all the huffing and puffing, I'll give away the
punch line now, and just say that I think something like what Mark
Rivers did with trajectoryScan (i.e., real synchronization in the
controller hardware) is the sort of solution to aim at.

The first purpose of the ID control system is to maintain a specified
magnetic field over the length of the device.  Because the leading-edge
magnets get more beam damage than trailing-edge magnets, as the device
ages, you might have to introduce taper just to obtain a uniform field
(sharp energy peak).  Worse, the ideal corrective taper is a function
of gap, though the consequences of ignoring this dependence seem
relatively minor.  (If not, you probably need new magnets.)

As the ID gap varies, it's likely that some unintended electron-beam
motion will occur, and this means you either would like very good
feedback from pairs of x-ray beam-position monitors to pairs of
steering magnets, or you would like to not change the gap if you can
avoid it.  This is another reason people taper ID's: to produce an
x-ray energy distribution large enough that they can scan the x-ray
monochromator through it without changing the ID gap at all.  But
obviously this works only over small energy ranges.  (I'm talking about
undulators, not wigglers.)

What the user wants at the end is to have the ID and x-ray
monochromator both tuned to the same x-ray energy.  This is a problem
because both devices are nonlinear in energy, and they both generally
have defects of motion comparable to or larger than their energy
bandpass.  For point-to-point energy scans (i.e., move, stop, take
data, repeat) the problem is relatively simple, and I'd argue that
existing software solves it.  You might have to have look-up tables to
supplement the equations that connect physical motions (ID gap,
monochromator angle) to energy motions, and you certainly have to take
out backlash, shaft windup, and other mechanical defects, but all these
things are within the capabilities of existing EPICS software.

What we don't have, I believe, is a generally applicable solution that
really does a good job of keeping the ID and monochromator tuned to the
same energy while both are moving over a significant energy range.
Note that the speeds of both devices have to vary while they are
moving, in order to have energy varying linearly with time.  (At least
one device has to vary it's speed while its moving in any case, to stay
in tune with the other device, because they're both nonlinear in
energy.)

This is complicated, and it's another reason people taper the ID gap.
It's easier to keep the ID and monochromator synchronized if the ID
puts out a broad energy distribution, and the monochromator just has to
stay within it, selecting a narrow slice of the distribution.  But this
is wasteful, because varying the field along the device decreases the
number of photons of any given energy.

I think there are two defensible strategies for maintaining
synchronization while both devices are moving:  1) slave the ID energy
to the monochromator energy, and move the monochromator at will; 2)
plan trajectories for both devices, and execute those trajectories in
synchrony.

I think (1) is very hard to do with precision: you have to fold in a
lot of corrections; you don't know where or how fast the monochromator
is going to go next; you have to worry about ID-acceleration time.  The
worst-case problem in slaving devices like these is that you can't
always avoid backlash and other defects by maintaining a consistent
history of motion leading to every position at which you'll acquire
data.  You might have to actually correct for defects of motion, which
means you have to know what they are and how they vary -- yuck!  I
think the slave solution is probably OK for "slow enough" scans that
are well within the following capability of a well-behaved slave, but
it runs out of gas too quickly to be the general solution.

But planning and executing trajectories for monochromator and ID seems
achievable to me.  We need a solution that allows predefined
trajectories of a small number of motors to be executed according to,
say, a clock delivered to both the monochromator and ID control
systems.  (It's probably unreasonable, in general, to expect ID and
monochromator motors to be controlled by the same hardware.  The
devices are many meters apart; they typically are maintained by
different groups of people with different scheduling constraints; and
often enough there are more than one of each device on a beamline.)

Aside from all this motion stuff is the protection system that keeps
the ID from killing itself or crushing the vacuum chamber, and I'd
argue that it belongs there: aside from all this, and implemented
separately in hardware.

--
Tim Mooney (mooney@aps.anl.gov) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab