activation of table after changing table and polarization

[ambarb]

@stuwilkins Is there a process record for the current energy setpoint. If we don't change the energy, but change the phase and the lookup table, the only way I can get a new epu gap is to actually change the energy.

def pol_V(offset=None):
    cur_mono_e = pgm.en.user_readback.value
    yield from mv(epu1.table,3)
    if offset is not None:
        yield from mv(epu1.offset,offset)
    yield from mv(epu1.phase,28.5)
    yield from mv(pgm.en,cur_mono_e+1)  #TODO this is dirty trick.  figure out how to process epu.table.input
    yield from mv(pgm.en,cur_mono_e)
    print('\nFinished moving the polarization to vertical.\n\tNote that the offset for epu calibration is {}eV.\n\n'.format(offset))

[ambarb]

@johnsinsheimer do you know the answer to this? If we can process the record, then we do not need to move the pgm.en at all.

[johnsinsheimer]

If you caput to the .PROC field of the PV, it should process. But I'm not sure how to make that work with Bluesky. I can look into it a little more tomorrow. Depending on the record type, I think it might be possible to change a field to cause the record to process even if the same value is put to the .VAL field.

[ambarb]

Let's first try by hand in a terminal window. We can move the gap and then caput to the energy PV.PROC to see if the epu gap goes back to where it should. I think I tried and had troubles and either did something wrong or the IOC has a different record to process. I am unsure. @bisogni has some priorities today so we will need to ask if there is time to test.

[ambarb]

btw, SIX is still using the diamond ioc for the mono control...which is different than the energy control ioc for the spectrometer.

[johnsinsheimer]

Let me know when you test. I'm not quite sure what is not processing or what procedure you're using now to make it work.

[johnsinsheimer]

After looking at this a little more, I think the best solution is to add another record that monitors the EPU phase set point (.VAL), and when this changes, forward link to the table PV to cause it to process.

[ambarb]

That is interesting. But do we need another PV to turn this "off" and then "on". I don't want the EPU to get in a fight with itself when we scan the gap with fixed beamline energy or de-tune to change the flux or something like that. Is it possible to cover these situations on the undcontrol ioc?

[johnsinsheimer]

The enable/disable buttons and associated records should probably be changed to use .SDIS. Right now it looks enable/disable writes to the .OMSL field of the energy set point as the way to enable disable its functionality. Instead, enable/disable could be BO, and every associated record can look at this PV as the .SDIS input link to enable or disable from processing. SDIS is also common to all records while OMSL is not. In this way, one enable/disable PV can enable/disable any number of other PVs that are looking at it.

[johnsinsheimer]

But yes, I'd need to look a little more closely and rule out cases where things could be processed multiple times unexpectedly.

[ambarb]

Ok. I tried at CSX to use a script with disable/enable for changing the polarization, but it still requires that the energy set point be changed, not updated. I was just hoping to make things more simple for changing the polarization without making other things more complex

What I do not want is to have to remember to disable/enable before/after either an energy scan (which moves the gap for those listening in) or before/after a gap scan. I don't want to make custom scans to do these things. If we want to make the ophyd object for the epu more complicated, then we can do that by incorporating the undcontrol ioc and any upgrades to the ioc.

[ambarb]

presumably, once working at 2ID, I will take this to 23-ID-1 (CSX). There are times that the canting magnet is removed and CSX switches to EPU1. Do you see any problems with this or have @irawaluyo and @cmazzoli decided to not use un-canted?