RE: Stream device - parsing array of pairs of floats

[Joao Afonso via Tech-talk <tech-talk@aps.anl.gov>]

Hello Andrew,

Thank you for your answers and suggestions. I think they will be very helpful.

Best regards,
Joao
________________________________________
From: Johnson, Andrew N. [anj@anl.gov]
Sent: 19 February 2019 18:33
To: Joao Afonso; tech-talk@aps.anl.gov
Cc: Stephen Page
Subject: Re: Stream device - parsing array of pairs of floats

Hi Joao,

On 2/19/19 6:38 AM, Joao Afonso wrote:
> a) According to StreamDevice documentation:
> /"Note that input links with PP flag pointing to a StreamDevice record
> will read the _old_ value first and start the protocol afterward. This
> is a problem all asynchronous EPICS device supports have."/
>
> I noticed this at first while testing this records. If I process the
> read aSub record:
> > caput TEST:REF:TABLE:READ.PROC 1
> It will use the old value from streamdevice, not the new one.
>
> Of course, this is fixable by using a FLNK in the REF:TABLE:G records
> (as commented in the code above).
> But it means that for reading I would be triggering a streamdevice
> record, while for writing I would be triggering a aSub record.
>
> Is it possible to do this in a symmetric way?
> I.e. be able to read/write by triggering only the streamdevice or the
> aSub records?
Unfortunately not with just the records you created. You could add a
pair of triggering records that forward-link to the correct internal
record, but actually those don't need to be records, they could just be
aliases for the correct record, say:

alias("REF:TABLE:GET", "REF:TABLE:G")
alias("REF:TABLE:SET", "REF:TABLE:WRITE")

With these, you process the GET record to trigger a read and the SET
record to trigger a write, so as far as the client is concerned this is
symmetrical.
> b) For these cases, is it possible to propagate the errors from the
> streamdevice to aSub records? Or does it only work for INP links?
You can set the MS flag on the REF:TABLE:READ.INPA field for it go into
the same alarm severity as the REF:TABLE:G record whenever it reads the
input string (and BTW you should remove the PP flag from that input link
when you uncomment the FLNK). You can't propagate alarms backwards from
the REF:TABLE:S record through the OUTA link, and while you might be
able to do something by FLNKing REF:TABLE:S to another record to copy
the alarm severity back to the aSub you would have to retrigger
processing of the REF:TABLE:WRITE record for the alarm severity to take
effect, so I don't really recommend that. This might be another use for
aliases, or just use the I/O records for the serial I/O error/alarm status.

> c) When read a double type waveform using caget:
> > caget REF:TABLE:REF,
> it prints all the allocated array elements and the size NELM (in this
> case the 1024 elements). It seems to ignore the NORD field, which
> contains the actual number of valid elements on the array and may be
> much smaller.
> Is this the normal behavior for EPICS records, when I get an array
> value without knowing the size?
If you say 'caget -s REF:TABLE:REF' you will only get the valid
elements; we didn't have support for variable length arrays over the CA
protocol for a long time, so the caget default is to follow the original
behaviour but the '-s' flag triggers a variable length get. camonitor
will display just the valid elements by default.

HTH,

- Andrew

--
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon