scan server default protocol

[georgweiss]

At ESS we're considering to use the scan server feature to automate tasks, so I have played around a bit to understand how it works.

I am unable to find a way to set the default protocol to pva. If this is indeed not possible, should a solution similar to the Phoebus runtime be considered?

[kasemir]

The scan server heavily relies on the 'put-callback' mechanism in channel access.
Without 'put-callback', we have to fall back to writing and then polling the readback to be "close enough", which means you don't know if a motor or temperature controller has really reached the desired value or is simply oscillating around it while still trying to adjust. See https://controlssoftware.sns.ornl.gov/training/2022_USPAS/Presentations/21%20Busy%20Record.pdf for some examples.

PVAccess doesn't support the same put-callback idea. There are similar mechanisms, but the PVA server in the IOC doesn't at this time use any of them. So at this time you can't really use the scan server with PVA.

[kasemir]

I'm not sure you'd have to change anything in the scan server, since it already calls into the PVPool to get a PV, and that one honors org.phoebus.pv/default

But this is missing:

1. Determine which feature in PVA should be used for the "put callback" functionality
2. Implement that in QSRV
3. Implement PV.asyncWrite for the PVA_PV, which for now just performs the plain write

   phoebus/core/pv/src/main/java/org/phoebus/pv/pva/PVA_PV.java

   Line 167 in 48fba7d

   public Future<?> asyncWrite(final Object new_value) throws Exception

[georgweiss]

Thanks for the information. Relying on updates in QSRV may not be an option at the moment.
But what if a PV is prefixed with pva://? Will the write be executed, but any read-back fail in the set command?

[kasemir]

For the Set command, https://controlssoftware.sns.ornl.gov/css_pyscanclient/html/commands.html#set, the value of completion basically doesn't make a difference. Either way we call the same PVAChannel.write. That one performs a PVA put request, it does return a Future to await completion of the network transfer, so a Set(..., completion=True) would wait for the write response.
But on the IOC side I'm not aware of a way to distinguish between OK, received the write and OK, received the write, processed the record, followed all the FLNKs and everything processed to completion, i.e., the distinction that we have with a plain CA put vs. put-completion.

[georgweiss]

Ok, so the difference between ca and pva in this case will then be a matter of risk management. Or a matter of educating users. Ultimately ca may be fine for the cases we consider.

Maybe the question of who can submit scans is a more interesting one.

[kasemir]

The CA put-callback is very important for reliable automation but somewhat tricky.
With a motor record, you can perform a CA put-callback. When the callback returns, the motor may have gone through backlash compensation, performed several retries, and has done its best to reach the requested position. We then additionally check the RBV to determine if that was good enough or not.

When a PV doesn't support put-callback, you can't really tell from the outside. The IOC will simply return the callback right away. Well, check the details on https://controlssoftware.sns.ornl.gov/css_pyscanclient/html/commands.html#set
Whoever created the IOC can check the record and device support if a given PV supports put-callback. If not, try to add that with busy record logic. Finally, configure the scan settings for the PV to use put-callback and readback check (best), just put-callback (meh), put and then poll readback (inadequate) or plain put (useless).
With Channel Access, it's tedious, but we know all this. With PVA, I don't think we've fully defined/implemented this. There were ideas like using the request type to select the behavior, but I'm not aware of a settled option.