Experimental Physics and
Industrial Control System

Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov> · Thu, 2 Apr 2020 09:08:59 -0700

On 3/31/20 10:44 AM, Rolf Keitel via Tech-talk wrote:
> This is a rant, which may only show that I am getting too old for EPICS. Or that staying at home because of COVID-19 makes me feel socially isolated.
> 
>  
> 
> You may stop reading right here, or read the bottom line just below,  or continue reading to the bitter end if you are masochistic enough:
> 
>  
> 
> */The bottom line: I know the release is 7./**/0.3, but IT SHOULDN’T BE THAT HARD./*

Your right.  I could try to sugar coat this, and I would add some qualifications,
but at core you're right.

It's hard to extend a 30 year old design to accommodate a major new feature
while maintaining backwards compatibility.  The idea of "group" (or batch)
access was not present originally at all in the process database.  Adding
this is a multi-step multi-year project which is not yet complete.

For example, accommodating all of the new configuration into the dbd parser(s)
is a difficult task.  There is very little room in the parser to accommodate
forward compatibility.  The info() tag facility is about it, and leaves a lot
to be desired.

Ditto the PVA data model.  Arbitrary structure are great and wonderful, but
to paraphrase: if you can store everything it's hard to store anything.
This doesn't mesh well with user expectations built around the fixed
value+meta data model of CA.  By default "value" is no different than
"alarm.status".  To first order It's up to us to make the distinction.

(The second order is slowly filling up our code with special cases)

> It all started out a while ago with me - rather innocently  - thinking “I should really start to look at EPICS 7”.
> 
>  
> 
> I got the EPICS7.0.3 tar-ball from the APS web-site and built it – no problems here – on a Kubuntu 14 system.
> (Please don’t ask why Kubuntu 14 – this is TRIUMF internal stuff).
> 
>  
> 
> I got the softIocPVA running with no problems and wondered how to set up a database with structured data for PV access.
> 
>  
> 
> You may remember, that I put this question out on tech-talk a week ago and got a few pointers. I liked the doxygen-generated QSRV documentation at
> 
> https://epics-base.github.io/pva2pva/qsrv_page.html#qsrv_group_def
> 
>  
> 
> although I had preferred a little how-to document.   I thought: a bit terse, but I can work with that.

A how-to is certainly needed.

This is some of the hardest documentation for a developer to write.
Up there with Getting Started.  I'm the one person who will never
be getting started with QSRV!  The how-to items I want I either
know off the cuff, or are features which don't exist yet.

So I start with a reference manual, which is what I need.
User feedback is critical to turn this into something which
is useful to people who aren't me.

Constructive feedback is always welcomed. Contributions even more so.
(Even a couple of paragraphs giving your explanation for an example)

https://github.com/epics-base/pva2pva/blob/master/documentation/qsrvpage.dox

> At the same time I remembered my EPICS7 training last year in Aix-en-Provence and got the circle.db database from the training IOC and made the highly  creative change to a rectangle database with records TEST:RW and TEST:RH with info nodes:
> 
> record(ai,"TEST:RW") {
> 
>     field(DESC,"rectangle width")
> 
>     field(SCAN,".2 second")
> 
>     info(Q:group,{"test:rect": {"width": {+channel:"VAL"}}})
> 
> }
> 
> record(ai,"TEST:RH") {
> 
>     field(DESC,"rectangle height")
> 
>     field(SCAN,".2 second")
> 
>     info(Q:group,{"test:rect": {"height": {+channel:"VAL"}}})
> 
> }
> 
>  
> 
> That was reasonably simple.
> 
> The IOC started ok and I googled for pvaccess command line tools, got Marty’s manual from April 2019 and started playing:
> 
>  
> 
> From a different shell I did pvlist and – bingo! – saw my IOC and when I did pvlist <IP addr>:5075 I saw
> 
> TEST:RW
> 
> TEST:RH
> 
> test:rect
> 
> Wonderful! I started to feel elated.
> 
>  
> 
> Then I went to the IOC shell and this happened:
> 
>>pvdbl
> 
> Command pvdbl not found.
> 
> Which was confirmed by
> 
>>help
> 
> which did not show any pvdbl. How should I guess that I should have to type dbgl ? That finally gave me
> 
> test:rect

You weren't to guess.  This was a later addition which I see is missing from the manual.

> Then I tried to fiddle with the default EPICS_PVAS_.... ports, couldn’t find the IOC any more whatever I did and gave up. Default ports are beautiful, anyway, aren’t they?

Sigh.  Troubleshooting network config problems with EPICS_CA* are
difficult and EPICS_PVA* is no simpler.  A little more difficult
as some of the recipes involving localhost/127.0.0.1 which work
with CA don't work with PVA.

On the plus side, "pvget -d" will at least tell you more.

> Then I used pvinfo and pvget successfully and started to feel better again.
> 
> As the output from dbget was always more than 70 lines long, I tried to use the -r switch, attempting to just get the values for width and height.
> 
> I would even have been happy to  pvget just the height, but pvget ignored me, it either gave me the full monty of 70+ lines, nothing or an “Invalid Character” message.
> 
> Well, one day I will learn!

Sigh.  At the risk of getting my head bitten off... again.
Marty and I have a difference of opinion on how '-r' (aka pvRequest) should
be interpreted.  Applying his documentation to my code, and vis. versa,
is a recipe for confusion.

> On to changing values.
> 
> I started
> 
> pvmonitor test:rect
> 
> got the full monty again, oh well!, but when I changed the TEST:RW and TEST:RH PVs on the IOC shell or with caput, I saw the changes reported on the structured data. Nice!
> 
>  
> 
> Optimistically I progressed to using pvput, but the values did not change in the IOC. I tried everything I could think of looking at pvput -h, but to no avail.
> 
>  
> 
> It took a couple of days of e-mailing with Marty to find out that I had to change the info node definition to
> 
> info(Q:group,{"test:rect": {"height": {+channel:"VAL", +putorder:0}}})
> 
> in order to allow pvput.  Did I say the documentation was somewhat terse? Stupid me had assumed the +putorder key had something to do with ordering only.

Yes, setting +putorder also acts to designate those parts of a group
where author wishes to allow remote changes.

It may have been lost in the flood, but there should be a "Put not permitted"
in in the output.

As to why this isn't a hard error.  This gets into the weeds of how PVA communicates
what changed.  It's possible, and in fact fairly easy, to mark more fields
as changed than actually have different values.  There are some clients which do this.
To a server, this appears as a Put to some fields which are allowed to be
changed, and some which aren't.

> Why did pvput come back with the full monty of all the data, sub-sub-data…. of the unchanged test:rect, but did not tell me that It cannot write to the PV?

The output format(s) of the CLI tools is... a complicated topic.
It seems that everyone wants to see something different.
No one wants to see the output of their structure change.
I don't want to support N+1 different output modes.
And no one really wants to spend time on this.

> With Marty’s help I got to the point of changing my rectangle height by typing:
> 
> pvput test:rect ‘{“height”:{“value”:33}}’
> 
> I appreciate the clarity of JSON syntax. I also know that some people delight in typing ‘}$@%, which I am less keen on.
> 
> I had tried,  naïve as I am and somewhat inspired by pvput -h, stuff like
> 
> pvput test:rect height=33
> 
> but that gave me the full monty again with unchanged values and two cryptic lines in the middle of the long page
> 
> height : Error: need a scalar field
> 
> Error: invalid bit-set length
> 
> Mmmmh????

Here your expectations are being violated by PVA.  With CA, you can almost
always omit ".VAL" because servers handle this transparently.  The PVA
equivalent is "value" or ".value".  As far as servers are concerned, "value"
can never be omitted.  But we've been sprinkling special cases into client
codes where it can.  You've unfortunately found one case where it needs to
be explicitly stated.

> pvput test:rect height.value=33

> Anyway, I decided to blame myself for not using the latest EPICS 7 release. So I got the 7.0.3.1 tar from the web-site.
> 
> My Kubuntu 14 just laughed at me. I’ll attach the error message somewhere below. Maybe anyone who had the patience to read up to hear can help me with that, but this is not really important.

"error: envData.c: No such file or directory" suggests that something went wrong earlier
in the build.  It's need to see the full log to be certain.

> Today I decided to try 7.0.3.1 on my Kubuntu 18 system. Miraculously, it built without problems. I got the softIocPVA running (on the default ports) and proudly typed
> 
> pvput test:rect ‘{“height”:{“value”:33}}’
> 
>  
> 
> And you know what happened after I had all the ‘ } and “  sorted out:
> 
> JSON syntax not supported by this build

As previously mentioned, this is a known issue which has been fixed
in VCS, but not yet released.

> Now I  want to type *#@%$!!!*. Can anybody help me to set the height field in test:rect with pvput?
> 
>  
> 
> Faithfully yours – a 25 year enthusiastic EPICS3 user.
> 
>  
> 
> As I may have said above – I volunteer to write one or two “how to” documents, but someone has to get me up to speed.
> 
> Unless I really retire first.

I'll try.  Talk to me.

> - rolf -
> 
>  
> 
>  
> 
> P.S.:
> 
> I am attaching the error from building of 7.0.3.1 on my Kubuntu 14 system. This is not important.
> 
> I will probably never need this fixed.
> 
>  
> 
>  
> 
>  
> 
> Rolf Keitel, Ph.D
> 
> TRIUMF, 4004 Wesbrook Mall
> 
> Vancouver, BC, V6T 2A3
> 
> Tel.: 604 222 7453
> 
> e-mail: rolf at triumf.ca <mailto:rolf at triumf.ca>
> 
>  
> 
> -- The old generation has to die off so that a new set of idiots can make the same mistakes all over again --

hum... yes.  I can see how this is holding us back when we could be pressing forward with exciting new mistakes.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System