fix baseline to have more relevant data

[ambarb]

REMOVE ['m1a_z_actuate', 'm1a_z_stop_signal', 'm1a_z_done', 'm1a_y_actuate', 'm1a_y_stop_signal', 'm1a_y_done', 'm1a_x_actuate', 'm1a_x_stop_signal', 'm1a_x_done', 'm1a_pit_actuate', 'm1a_pit_stop_signal', 'm1a_pit_done', 'm1a_yaw_actuate', 'm1a_yaw_stop_signal', 'm1a_yaw_done', 'm1a_rol_actuate', 'm1a_rol_stop_signal', 'm1a_rol_done', 'pgm_energy_stop_signal', 'pgm_fly_start_sig', 'pgm_fly_stop_sig',

'pgm_fly_velocity', #check with @tacaswell, but should be in configuration

'pgm_fly_scan_status', #check with @tacaswell, but should be in configuration

'epu2_gap_stop_signal', 'epu1_gap_stop_signal', 'epu2_phase_stop_signal', 'epu1_phase_stop_signal', ]

Then discuss with @cmazzoli and investigate:

• nanop's
• stemp_temp
• epu1_flt #some to descriptors
• epu1_rlt #some to descriptors
• epu1_table --> probably should be descriptors or maybe not? but this is something to ask @danielballan about with V3 db
• same for EPU2

[ambarb]

I added EGU to pgm.energy , which is a PV positioner.
https://github.com/NSLS-II-CSX/xf23id1_profiles/commit/f7f4d58f2e54050a53ff381f5e45dacf4149025a

I don’t understand how it works though. I cannot configure .kind and it seems .get() does not work. It seems that pgm.energy.egu is just a simple string representation, and I could just add this to sd.baseline but this doesn't feel like the "right way". Is there something that works more like an epics motor_egu?

[mrakitin]

To employ ophyd's interface (.read(), .get(), etc.) the attribute has to be a component (Cpt). You can convert it to the component as:

    egu = Cpt(Signal, value='eV')