Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Mon, 16 Dec 2013 11:47:12 -0600

Hi Michael,

On 12/16/2013 08:11 AM, [email protected] wrote:
> This is a question for users of cothread.catools.

I'm not one of your users so you weren't asking for my comments, but
I'll make them anyway.

> Some years ago there was an EPICS codeathon where we extended CA so
> that a request for zero length waveform would be interpreted by the
> server as a request for the "natural" length of a waveform.  The
> intent was that the .NORD field of waveform records would be
> respected, but this change to record support has only recently been
> implemented.

There has been no change to the waveform record support, if you wrote
code to run on the IOC which used dbAccess to get the waveform array,
you would always have been given NORD elements. The problem was that CA
was unable to transport the current array length along with the data,
until you actually implemented that change in Base.

At this point I should mention that the NORD and NELM fields that I talk
about below apply to the waveform record, but many other record types
provide array fields and use different field names. Each array field has
two associated fields that store the information about that array,
namely the maximum number of elements (NELM) it can hold, and the number
of array elements that currently hold valid data (NORD).

> At some point between 3.14.11 and 3.14.12.3 (DLS is in the process of
> migrating to the latter version) it seems that waveform record
> support for NORD length requests has been implemented.  Of course
> this is a change in behaviour, and inevitably something is going to
> break.

This was actually in the 3.14.12 release, which came out in November
2010. Prior to 3.14.12 the CA server code would zero-fill all elements
from NORD to NELM or whatever your subscription length was. It still
does that if you request a fixed length subscription which is longer
than NORD at the time the event is posted.

> It's unfortunately all too easy to reset the NORD of a writeable
> waveform to the wrong value by mistake, for example by performing
> something like 'caput $PV $value', which will truncate $PV.NORD to 1.
> Downstream applications monitoring $PV now see it shorten.  Arguably
> this is a bug in the specific implementation of $PV itself (for
> example in my own drivers if a writeable waveform is fixed length I
> prevent NORD being overwritten), but because nobody has paid
> attention to NORD up to now, this is a new problem.

I don't follow your comment about your drivers; waveform device support
should copy up to NELM elements into the array buffer and set NORD to
the number of elements it actually set. It shouldn't be looking at the
current value of NORD at all. (I don't agree that "nobody has paid
attention to NORD", although I can't speak for what happens elsewhere).

> The problem is that when cothread performs a caget() or camonitor()
> request the default data length that is requested is zero, and so
> when migrating from a .11 to a .12 server we can suddenly see the
> length of received waveforms shorten (or cease to be waveforms
> altogether)!

Please don't conflate the terms array and waveform, the latter is a
specific record type, but other record types also provide array fields.
I suspect that your wording there should have been "cease to be arrays
altogether" which suggests to me what your solution should be...

> I am now faced with a bit of a dilemma, so I ask all
> users of cothread to please give me your opinions to the following
> question:
> 
> 
> QUESTION: What should be the correct *default* result length when
> using cothread to perform caget() or camonitor() on a waveform?
> 
> A. The "natural" length, encoded as zero: this returns NORD elements
> on a .12 and above server, but NELM elements on older version of
> EPICS.  (This is the current default.)

I think you should stick with this meaning.

> B. The "full" length, which for a waveform is NELM elements.
> 
> 
> I am proposing to make the following *incompatible* change: the
> default result length (encoded by the 'count' parameter to 'caget'
> and 'camonitor') will change from 0 ("natural" length) to "full"
> length, and if the "natural" length is wanted it will be necessary to
> explicitly specify 'count=0' as an argument.
>
> Please shout if you think this is a bad idea...

Shout!

> While I'm breaking compatibility, maybe the result from a waveform of
> "natural" length 1 should be encoded as an array rather than as a
> scalar?

A CA client application actually has two lengths available to it; the
value returned by ca_element_count(chid) which never changes and is read
from the NELM field at channel connection time, and the count field
provided to your callback routine in the event_handler_args structure,
which is the value of NORD at the time the array was read. I suggest you
use ca_element_count(chid) to control whether you return an array or a
scalar, and the count field to set the actual length of the array.

Note that for any specific chid the server will never return a count
field that is larger than ca_element_count(chid), but unfortunately some
out-of-tree record types (e.g. the synApps array calc) used to change
their max-elements field at run-time (they didn't have a current-length
field IIRC), which is a really bad idea. If a client connected two CA
channels to one such field at different times, it could see two
different values for ca_element_count() even though both point to the
same record array field. What's more, a ca_put can never send more the
ca_element_count() elements for the chid, so with these broken record
types clients could shorten the array but never make it bigger again. I
think Tim has fixed these issues in recent versions of synApps but I
don't know in which release.

I hope this suggestion helps,

- Andrew
-- 
Advertising may be described as the science of arresting the human
intelligence long enough to get money from it. -- Stephen Leacock

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System