EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Zero length length requests, EPICS upgrades, and cothread
From: <[email protected]>
To: <[email protected]>, <[email protected]>
Date: Wed, 18 Dec 2013 07:14:36 +0000
From: [email protected] [mailto:tech-talk-
> I'm not one of your users so you weren't asking for my comments, but
> I'll make them anyway.

Thank you!

> > 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).

When I talked about a "writeable waveform [of] fixed length" I'm thinking of in particular: 936 element waveforms used to configure the behaviour of the individual bunches in our storage ring.  In this particular case I want to support arbitrary caputs into the waveform (I might be configuring current to inject into individual bunches or TMBF gain or some other parameter) ... but I can't allow the observed length of the waveform to change!  Thus in this particular case I interpret a "short" caput as just overwriting the first elements of the array, and leaving NORD==NELM==936 in all cases.

As for "nobody has paid attention to NORD" I confess that to be an egregious exaggeration; however I fear there is an element of truth in it.  This issue has arisen because a colleague has been bitten by the change from .11 to .12.

> > 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've got a bit of a language problem here because I have three concepts to communicate with two words: CA array types, waveform record types, and Python numpy arrays; the latter are what cothread uses to represent the former.  You're right, mostly I'm just thinking CA array when I'm saying waveform.

> > 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.

On reflection I now agree.


> > 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.

Yes.  I'm slightly uneasy that this might be a compatibility breaking change, but I think it's going to be the right behaviour.  In particular it means that (so long as you know the record type) you know what data type you're going to get back.


> 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.

I seem to remember some old camera support code that used to do that here, and which used to work with our systems ... until it broke!  Probably EPICS 3.13, don't remember the details anymore.
 

> I hope this suggestion helps,

Thank you, yes, and it's helpful and comforting to have confirmation.  I sent this mailing because I was queasy about my proposal, and your reaction has helped me to reject it.  Furthermore, I think the idea of using ca_element_count() to determine whether a result is a Python scalar or array is sound.  BTW, does CA support zero length arrays, I mean with .NORD == 0?  (Just an idle question, really.  I imagine not, to be honest.)

-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
 





Replies:
Re: Zero length length requests, EPICS upgrades, and cothread Andrew Johnson
References:
Zero length length requests, EPICS upgrades, and cothread michael.abbott
Re: Zero length length requests, EPICS upgrades, and cothread Andrew Johnson

Navigate by Date:
Prev: Re: CSS Beast UI, Configure Item Kasemir, Kay
Next: RE: Zero length length requests, EPICS upgrades, and cothread michael.abbott
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Zero length length requests, EPICS upgrades, and cothread Matt Newville
Next: Re: Zero length length requests, EPICS upgrades, and cothread Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 20 Apr 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·