[Bteam] [Ops] Input on BPM relative position modifications (as discussed at the last B-team meeting)

[Terry Carlino]

At one time every (Saver) save done to the machine included a set of 
ZPos information whether the save was a save with ZPOS or not. The way 
the software works is that on a bpm the relative offsets are saved in 
the POF fields. These are combined with the POS positions to create a 
PRL reading, which is used on the Relative screens. Software use to take 
the POS fields of a save and create a POF value and add it to the save. 
The ZPDT field was also update tot he time/date of the save. This was 
when the bpm Zero Pos was done using scripts. The method of Zero Pos'ing 
was changed so that the bpm ioc record zreo pos's itself when tagged by 
the script, rather than the script caputing a value into the POF field. 
This broke the Saver software and it no longer does automatic ZPOS 
information updating on each save. It now either ZPOs's the bpms and 
then saves the values or saves the values which are in the POF and ZPDT 
fields (which means we have a mess of saves with the same ZPOS 
information which is unrelated to the beam position at the time of the 
save.)
Software has promised to fix this in a future version of Saver. Maybe in 
the version that implements these changes?



Michael McCaughan wrote:
> Hi Everyone,
> I told Todd I would serve as a gathering point of input for this 
> project so we could outline what, if any, changes we want to make to 
> the current system by which we are operating vis-a-vis burt saves, 
> relative positions(& zeroing them), and the injector steering script. 
> As currently stands:
>
> One may zero the relative position of any segment of the machine (by 
> going to the individual bpm segment screens) or the machine as a whole 
> (with the zero positions script on the bpm commander. In some cases 
> this utility is used more often to denote a good setup (such as the 
> Injector or the hall lines) but it is additionally used during 
> procedures and test plans to be able to observe (and provide the 
> opportunity to back out of) orbital changes made.
>
> To perform a save with zeroed relative postions the typical method is 
> to click the appropriate bubble during a save and physically perform 
> the zeroing a script button on the BPM commander [(!)Zero Positions]. 
> One may additionally annotate a save with some description (Reza 280uA 
> gun setup for example....) or note that one only zeroed some 
> individual segments rather that the whole machine. To recover the 
> saved relative orbits using Burt one may click the BPM rels button and 
> select an allsave from which you desire to filter/grep segments (or 
> grep it from the save directly via the gui) and download as necessary.
>
> The Injector steering script allows one to steer to a saved orbit or 
> relative orbit. It defaults to rels. It is good practice to save setup 
> with the existing orbit before initializing/computing a new matrix and 
> steering to it. One must manually click the log button upon completion.
>
> If my understanding of the desires of the group was correct at the 
> b-team meeting, we want to move to this:
> The script from the BPM commander which zeroes relative positions 
> should become segmented in multiple scripts. One for the injector, one 
> for the main machine (NL/SL/BSY), and possible one for each hall with 
> the associated transport line. Possible variations on this theme which 
> have thus far been suggested include denoting which lasers were active 
> at the time of the save (as in sections of the machine this will cause 
> the orbit to vary) and returning to/augmenting the way we use the gold 
> orbits (which right now it to say not at all) as they were originally 
> envisaged (as well as a possible script for easy input of a new gold 
> orbit). It was pointed out we certainly want to retain the current 
> utility of relative orbits for the purposes of test plans etc. There 
> was also suggestion also that in the injector one should perhaps be 
> able to retain a sort of triplicate orbit, which is to say one orbit 
> with each active laser as the beams are many times not completely 
> coincident.
>
> Once we decide on a course of action appropriate software 
> modifications will need to be made. Right now the purpose of the 
> discussion is to generate the necessary specifications for 
> modification to the existing software. As an example Burt would 
> require a modification to the save GUI to denote saves with zeroed 
> relative positions in the newly defined/delineated segments. Also Gold 
> orbits are not currently a part of the information saved. If we decide 
> to go that route that information will need to be included on future 
> saves (and of course still be backwards compatible with the existing 
> ones). The steering script could be adjusted to default to a saved 
> orbit, be it a separate file (as it is currently) or the newly 
> designated gold setup. There would be some group of appropriate 
> experts who updates/changes this orbit as needed 
> (Reza/Joe/Matt/Marcy/Yan/etc.). Should we retain the steer to rels. 
> option? (As an operator I would tend towards yes...)
>
> Is there other existing software that should be modified as well in 
> this vein? Please help me identify them...
>
> As items of general note there are also a few good ideas which have 
> already been generated:
>
> *The autosteer program should automatically take a save before 
> steering to a new orbit as well as make a log when it does so. Right 
> now both of these function are done by hand if one remembers.
>
> *Zeroing relative positions should only occur for areas of the machine 
> which currently have beam though them.
>
> I welcome all opinions/input/suggestions... just send something to me 
> and I'll try to get something together for an upcoming b-team meeting 
> for discussion and so we can make appropriate recommendations.
>
> Respectfully,
> Mike McCaughan
> _______________________________________________
> Ops mailing list
> Ops at jlab.org
> https://mailman.jlab.org/mailman/listinfo/ops