Stored values (Read and Set)

[crispd]

Some devices we'd like to save may not read back exactly what we set them to, especially cases where something is either pulsed or known to fluctuate about their set more than most. Some examples: Voltage reading from a pulsed RFQ Phase reading from a cavity (some worse than others)

Can we save, and then display, the values our devices are reading back to us as well as their existing set point?

[berryma4]

A user should use "set" pvs in the pv list, not readback pvs. If we want to add a read back pv to the compare table, we can talk about that. Dylan has this same issue of figuring out the readback and set pvs from a device. We should should discuss a general way to do this.

[crispd]

I didn't mean to say we'd only do it for those devices, nor imply that a list of such devices would need to be provided/considered: I agree with necessarily discussing a general way of doing this.

Maybe I'm confused though, what's the difference between the contents of a single snapshot and a compare? Other than multiple stored value columns being appended in the compare, and the omission of alarm status/severity?

What I mean to ask is if we wanted to add something to the compare table, is it not required for it to be in an initial snapshot?

[jbobnar]

What I mean to ask is if we wanted to add something to the compare table, is it not required for it to be in an initial snapshot?

The plan is that it does not have to be a snapshot. It is not yet implemented, but the plan is to be able to pull in the values from other sources (e.g. "optics server", config file etc.)

Regarding the readback values. If you have a naming convention, such that one can derive the readback name from the setpoint name (e.g. MYDEVICE_SET and MYDEVICE_GET), that would be perfect. Or if there is some kind of a service that can provide the mappings between setpoints and readbacks that would also work fine.

[crispd]

I like the idea of pulling for comparisons like this, both from an optics server or archived data (not mentioned but presumably do-able?).

When you mention a service for mappings, all I can think of is channel finder.. I understand we're trying to hold off on relying on external services as much as is reasonably possible?

We don't have something quite as simple as _SET and _GET, and there might but should not be some exceptions. Here's an example of a full record: REA_BTS19:PSOL_D0996:I_RD And here's what the majority of our signal endings look like for sets/reads: :V_RD Voltage Reading (PSC2) :V_CSET Voltage Control Setting (PSC2)

:AMPL_CSET RF Amplitude Control Setting (RFC1) :AMPL_RD_CAV RF Amplitude Reading in Cavity (RFC1)

:PHA_CSET Phase Control Setting (RFC1) :PHA_RD_CAV Phase Reading in Cavity (RFC1)

:I_RD Current Read (PSOL) :I_CSET Current Control Setting (PSOL)

I can move this bit to a new issue thread if it makes sense to Having your feature as an aggregation point for saveset data along with pulled 'optics server' or an archiver (retrieving read values) leads me to the question of export ability of the resulting table. I imagine for either example, later discussion, or some type of logbook, it would be nice to then export this complete table once made (possibly an option in a future 'right click menu'?)

[crispd]

Where I gave the record ending, followed by what it means, and an example device code in parenthesis

[berryma4]

@crispd I believe jaka has all this covered now.

[crispd]

Yes I think so.. I see the columns can be toggled. "Stored Setpoint (Del Live Setpoint)"; "Live Setpoint" are default. Then "Stored Readback (Del Stored Setpoint)"; and "Live Readback (Del Live Setpoint)". We should think about what columns need a delta, It might not be necessary to alarm on all these deltas. Of course you want to know if your setpoints were taken, and how well a given device can meet its setpoint, but maybe we can simplify it a bit? This is a different topic though. Happy to see the values stored! thanks!