You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Problem

Steering is intended to calculate values for corrector magnets whose
effect will be to reduce the RMS of the beam orbit as read by BPMs. The
problem is steering only reads the existing settings (BDES) of the correctors o`
when it's initialized. From that point on, it thinks that the extant settings
(BDESes) of the correctors are the values which it last calculated. That
means if steering takes a long time to calculate new settings, the real
extant BDESes of the correctors in the db may have changed due to external
influences, such as someone implementing a "bump", before steering has the
chance to implement the values implied by the calculation it made. If the
bump is "closed" (if its effect is local in the beamline), then it should be
ok for steering to implement its correction even though the bump is in effect.
However, since steering has only recorded the extant corrector BDESes before it
started its calculation, and the bump changed those values, and steering then
implements its calculated change to the corrector settings assuming that
change is the change to the recorded BDESes, the effect is to undo the BUMP.

By the way, steering does reaquire teh extant BDESs at the beginning of each steering iterations, so it isn't true that over a long period of steering, such a in GOF, that the real values drift from those steering has recorded. The problem is confined to the time it takes steering to make one orbit correction calculation.

Objective

make steering set the values of corrector magnets as changes
from their extant values at the time of the implementation of the orbit correction solution
(when the user actually hits TRIM or in the case of AUTO steering immediately after the calculation has been completed; GOF uses AUTO steering), rather that as changes from values
acquired from the database when steering was initialized.

Information

ref_strshr:str_cor_db_in.for
This function gets the extant bdes secondary values of the corrector magnet`
database. If it is called with INIT argument it sets up the dblist ptrs
for susequent non-INIT calls. Its primary job is to set the global array
"BDES" - steering's understanding of the extant settings of the correctors.

ref_strshr:str_cor_db_out.for
This function puts the CALC_BDES value in the database (DBLPUT only,
the magfunc is handled by other functions). If it is called with INIT argument `
for susequent non-INIT calls. Its primary job is to set the bdes secondary of the corrector magnets to new values reflecting the calculated bdes.
CALC_BDES is to be interpreted as an absolute value to be implemented, so like a replacement BDES rather than a change to it. But the actually implemented BDES
is
old_BDES + ( CALC_BDES - old_BDES) * factor

where factor is a fraction to implement the correction, so say .5 says only do half the calculated correction.

Possible Implementation

So, one way to implement this fix is for str_cor_db_out to call str_cor_db_in (with the INIT param set false) immediately before using the BDES values.

Care however must be taken not to set the BDESs to values which exceed BMAX. This condition is nominally checked in each steering method's function (like STR_RMS and STR_SVD), but now, since it may have changed, it has to be checked again.

  • No labels