How to use org.phoebus.pv.PV.asyncRead()

[georgweiss]

I'm a bit uncertain about how to use the PV.asyncRead() method. There is but one occurrence in the Phoebus source (in scan server). I was assuming the API could be used like so:

VType value = PVPool.getPV("mypv").asyncRead().get(1000, TimeUnit.MILLISECOND);

However, I'm getting:

Channel not in connected or disconnected state, state = 'NEVER_CONNECTED'.

Using the onValueEvent().subscribe() API works fine, though.

What am I missing?

[kasemir]

What am I missing?

The connection.

asyncRead and asyncWrite are based on the EPICS idea of a read-callback and write-callback.
They're round-trip network actions which send a read resp. write request, potentially triggering a long processing chain on the IOC which will for example start communicating with a slow device for the read or start a motor move for the write, wait for that to complete, and then send the result.
They're contrasted with the monitor-based read which just gets you the most recently received value, or the plain write which is fire-and-forget.
Both asyncRead and asyncWrite require that you're connected. If you just get a PV, you first need to wait for that to connect. The API is generally not meant for a short { create, read/write, release } use case but for the { create, subscribe, .... and stay subscribed for quite some time, occasionally write, asyncWrite, asyncRead, ...., release } use case.

A short asyncRead could be done like this:

PV pv = PVPool.getPV("SomePVName");
CountDownLatch connect = new CountDownLatch(1);
pv.onValueEvent().subscribe(value ->
{
    if (!PV.isDisconnected(value))
        connect.countDown();
});
connect.await();
System.out.println("Async read: " + pv.asyncRead().get(10, TimeUnit.SECONDS));

[georgweiss]

OK, thanks.
The use case at hand is precisely that: read a few PVs once and then disconnect as they will not be needed until a (much) later point in time.

[georgweiss]

By the way... Would it be meaningful to provide a convenience method for this? E.g. readOnce("somePVName", 10, TimeUnit.SECONDS).

[kasemir]

.. then there's likely no need for the asyncRead, because again that can trigger side effects on the IOC.
A plain subscribe, waiting for an update on each channel, then release would get you the most recent value for each PV.

This would do it for one PV:

PV pv = PVPool.getPV("SomePV");
CompletableFuture<VType> latest = new CompletableFuture<>();
pv.onValueEvent().subscribe(value -> latest.complete(value));
System.out.println(latest.get(10, TimeUnit.SECONDS));
PVPool.releasePV(pv);

If you have multiple PVs, you can create a List<CompletableFuture<VType>> latest_values and then use something like CompletableFuture.allOf(latest_values) to wait for all of them.

[kasemir]

.. readOnce("somePVName", 10, TimeUnit.SECONDS)...

I would not put readOnce in a loop for 10 PVs, but instead read the 10 PVs in parallel as shown above with List<CompletableFuture<VType>> latest_values and CompletableFuture.allOf(latest_values)

[kasemir]

But again generally tools like the display, archive, scan, ... tend to stay connected for a long time.
The 'readOnce' idea is used from python scripts that run outside of the UI, and there's already support for that.

[kasemir]

This might actually be a good example for 'easy' not being 'easy'.
Reading just one value is comparably expensive: Broadcast of name to everybody on the network, connect, ..., then disconnect after just one read? Why do you want to read just one value? Is this from within a display script, doing something that would better be handled outside the display?
When reading one value from several PVs, this would be an example:

        // Create PVs
        final List<PV> pvs = List.of(PVPool.getPV("DTL_LLRF:IOC1:Load"),
                                     PVPool.getPV("DTL_LLRF:IOC2:Load"),
                                     PVPool.getPV("DTL_LLRF:IOC3:Load"),
                                     PVPool.getPV("DTL_LLRF:IOC4:Load"),
                                     PVPool.getPV("DTL_LLRF:IOC5:Load"),
                                     PVPool.getPV("DTL_LLRF:IOC6:Load"),
                                     PVPool.getPV("SCL_LLRF:IOC01a:Load"));

        try
        {
            // Subscribe to all of them
            final List<CompletableFuture<VType>> latest = new ArrayList<>();
            for (PV pv : pvs)
            {
                final CompletableFuture<VType> done = new CompletableFuture<>();
                latest.add(done);
                pv.onValueEvent().subscribe(value -> done.complete(value));
            }

            // Await update on all of them (or fail)
            // Somewhat unfortunate that 'allOf' uses array, not list...
            CompletableFuture.allOf(latest.toArray(new CompletableFuture[latest.size()]))
                             .get(10, TimeUnit.SECONDS);

            // Print all the values
            for (int i=0; i<pvs.size(); ++i)
                System.out.println(pvs.get(i).getName() + " = " + latest.get(i).get());
        }
        finally
        {
            for (PV pv : pvs)
                PVPool.releasePV(pv);
        }

[georgweiss]

This is our use case: A dedicated IOC maintains a few PVs holding shift information. For the Olog client I want to install a custom org.phoebus.logbook.olog.ui.write.LogPropertyProvider that would return a org.phoebus.logbook.Property wrapping these PV values. The Property object is then automatically appended to the log entry.
So, when a new logbook entry is created I think it would - despite the cost - make sense to query the IOC for the PV values in a "synchronous" manner rather than having the LogPropertyProvider maintain the connections and fields to hold latest value.

[kasemir]

Right, you'll need to call a web service or connect to PVs to get that info, with comparable overhead.
Since the data happens to be in PVs, could it change while the make-elog-entry dialog is open?
So create PVs as dialog opens, then keep showing the current value, which might change?

[georgweiss]

The overhead is acceptable as the properties are retrieved asynchronously and won't delay the launch of the editor. Yes, hypothetically the data may change while the log entry is edited, but that I think would constitute a corner case that users would be aware of. After all, it's the same type of users that will update the shift information PVs. The shift information retrieved when the log entry is created is the "correct" one.