How to write to PV from BOB?

[thomasms]

Very basic question, and apologies for being very basic, but after trying to follow many presentations and reading various documentation I cannot find an answer, hence my motivation for coming here.

I am new to Phoebus and have created a very simple display based on Display Builder, I have a PV server providing a PV with an x and y value, both floats. I am successfully able to read these values in my display using a text box (as below).

In this simple example I also want to be able to alter this value via another widget, say a Scaled Slider.

My question is how do I go about doing this?

I have tried writing the PV via below, but it does not work.

I know it's not a problem with my server since pvputs work fine.

[kasemir]

If you have a plain IOC with a record, you can read and write those PVs.
If you create your own custom data type, you can read it via PV access, but there is no support for writing sub-sections of a complex PV Access PV.
What's supported are only the normative types.

[thomasms]

OK, thanks for clarifying. I was not aware of this.

Are there any intentions to support this in the future?

If not, are there any work arounds? Using the script functionality, for example? Although ideally I would like to avoid doing any scripting in the display itself.

[kasemir]

Maybe in the distant future.

Right now , I would say the basic priorities are like this:

• Have everything use the 'new' PV access libraries, i.e. update the IOC 'qsrv' to use pvxs
• Make sure that everything works, including pipelining, access security
• Get a PVAccess gateway, based on pvxs

With that in place, you would fundamentally be able to use normal IOCs and all the updated clients with PVA instead of Channel Access, fully supporting everything you could do with Channel Access.

You could then also use custom structures via the getaway, with your own custom server and client.
Phoebus already allows reading 'pva://name/subelement/subsubelement', but you get only that value, it cannot magically guess what to use for alarms, time stamps, or how to otherwise interpret your custom data, and it cannot write. To support that, we'd probably first need to agree on some syntax.

Anyway, that would be my basic idea of how this will progress. Doesn't mean it's going to be that way.

[thomasms]

I appreciate the comment on this, but I still find it somewhat odd due to the asymmetry of the problem - it can read but not write. I would naively think that regardless of structure, if a system is able to read a subfield on a PV then it should be able to write back in the same way (just change that subfield). I mean if it is possible to do so with pvget & pvput, then why can Phoebus not do so?

I understand that it cannot magically guess alarms & timestamps, but if I say my PV to display is pva://name/subelement/subsubelement then reading and writing should be symmetrical. (I am thinking along the lines of a PUT vs POST in REST terminology.)

This is not meant as a criticism, and sorry if it appears that way, I am just trying to better understand the problem.

[kasemir]

Time has been invested in supporting the native types, i.e. data served by softIocPVA, for reading and writing.

Some time has also been invested in supporting reads from pva://name/subelement/subsubelement, because that is generally useful to debug the data that flows between custom PVA servers and clients.

So far, no time has been invested in supporting writes to pva://name/subelement/subsubelement. The key point of custom data structures is to transfer data that belongs together as an atomic unit. Like "(x, y)" coordinates which need to be transported as a pair. A custom client can digest them as an atomic update. The generic phoebus support can display pva://coordiate/x and pva://coordiate/y, so you can monitor the data, but it won't handle that as an atomic unit. The two text updates for the ..x and ..y might not update concurrently. And there is no use in writing just the ..x part, you would have to write both x and y as a pair, so operationally there is no good use case for supporting write access from phoebus.
But feel free to implement that if you find it useful.

[thomasms]

Indeed, that is one use case, but I can certainly imagine other use cases where it makes sense to bundle a few fields together into one PV (hence one reason for PVA over CA), where one field may be permitted to change independently of other fields in the same PV.

For example, as in the case I mentioned for the timestamps issue, I have something like

structure 
    string name default:component:1
    float x 7.07089
    float mean 10
    float sig 2
    alarm_t alarm 
        int severity 0
        int status 0
        string message "No problem"
    time_t time 2021-03-29 15:16:30.844  -1 
        long secondsPastEpoch 1617023790
        int nanoseconds 843611000
        int userTag -1

I may want to change the mean or sigma for my random number but it makes sense to bundle the value with the parameters, the value is only relevant with the mean + sigma, (OK it is a toy example but could be representative of a real world problem).

I, for one, would find this useful, but maybe I am a minority. I would be interested to know how people generally tackle such problems - do they break this up to separate PVs and link them together somehow?

With regard to implementing this, I am not really a Java developer so while I could take a stab at it, it probably would not end well.

[kasemir]

In part, everybody is of course free to package the data as they want, and then implement the servers and clients to handle it.

In my opinion, EPICS did well for the last 30 years because it didn't dictate what a "Power Supply" looks like. Some may just have an on/off switch. Others add a voltage read back. Next one adds a voltage setpoint and current read back. Next is a temperature sensor and over temperature status indicator. To EPICS, each of those data items used to be a separate PV. The data layer, the basic IOC code, the displays, pretty much all the tools simply handle PV by PV, unaware of possible relationships between PVs.

With PVAccess, you could define separate data structures for each of these power supply types, but then each time you add a new type, every client out there needs to be updated to handle that new type. You have some limited backwards compatibility because clients that don't look for a specific field will simply ignore the new fields, but to make use of the new fields, clients will need to be updated.

At the extreme end, you could define just one big "TheMachine" data type which contains an array of power supply objects and so on. I think everybody agrees that would be the wrong approach because adding/removing just one device means you need to update everything in your control system.

For the in-between structures, when you ask 5 people for their opinion on what a power supply data structure should look like, you might get 10 replies, and you're then still free to come up with your own definition.

On your specific example of statistics with a value, mean, ..., the original normative types http://epics-pvdata.sourceforge.net/alpha/normativeTypes/normativeTypes.html included an "NTAggregate". You have "float x", it had "double value". You have "mean", it has "min", "max", "dispersion", ... So there's clearly some agreement that a statistics type might be useful, but what exactly it should look like isn't locked down, and so far no tool supports anything.

[thomasms]

Fully agree, but that's why I am confused because all the freedom given to me with PVA, allowing any data structure, does now not conform with Phoebus, thus boxing me in to only normative types.

I fully accept the fact that the front-end cannot magically know what to expect, but if I can display a PV as pva://mypv/subelement/subsubelement then it seems only natural to also allow this to be set via the same path pva://mypv/subelement/subsubelement (given correct access permissions of course).

I was unaware Phoebus operated like this, and in my opinion it is an extremely important piece of functionality for a control system - to be able to write a PV. I guess I will have to reignite my Java skills and see how implement this.

[thomasms]

So what I discovered, and maybe what you were hinting at before, is that if I define my PV structure now as below, I am indeed able to write PV values back.

structure
    float value 53.6251
    structure mean
        float value 54.4896
    structure sig
        float value 2
    structure name
        string value default:component:1
    alarm_t alarm 
        int severity 0
        int status 0
        string message "No problem"
    time_t timeStamp 2021-03-30 12:31:09.508  -1 
        long secondsPastEpoch 1617100269
        int nanoseconds 508293000
        int userTag -1

While it forces me to provided nested structures which bloat things out a bit, I can live with this as a solution. The implicit contract that is happening here is that each substructure requires the key to be 'value', which I now know is necessary for write-able PVs. Even trying things like 'values' will cause issues.

Thank you for your help and apologies if this became more complicated than originally planned.

[kasemir]

requires the key to be 'value'

That's because the normative types all have a value for the actual, well, value. When we read/write pva://x, we're really reading/writing x/value.

The pva://... support is somewhat lenient. Even if it's not normative type, it still looks for something called value and then tries to treat it the same way. The write part could likely be even more tolerant, i.e. if there is no x/value, it just tries to write x, but at this time I'm honestly more concerned about supporting the normative types and not accidentally breaking that. So trying to guess what else we could write when there is no value seems more bug than feature.