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.
f7f4d58

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')