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  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 
<== Date ==> <== Thread ==>

Subject: Zero length length requests, EPICS upgrades, and cothread
From: <michael.abbott@diamond.ac.uk>
To: <tech-talk@aps.anl.gov>
Date: Mon, 16 Dec 2013 14:11:05 +0000
This is a question for users of cothread.catools.


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.

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.

Up until this change it's a fairly safe bet that almost nobody has been paying any attention to NORD, and so for example interactions which change it (such as performing a short caput to a waveform) have had no consequential effect.  My attention has been drawn to the fact that certain cothread applications now break!

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.

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

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.

Unfortunately I'm proposing one incompatible change in order to manage the impact of another incompatible change which was meant to be fully backwards compatible.  Sigh.  The irony of compatibility!  Please shout if you think this is a bad idea...


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?  Also, are there any requests for changes and fixes to cothread?

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

Navigate by Date:
Prev: RE: Mclennan PM600 motor controller Mark Rivers
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 
Navigate by Thread:
Prev: Version of nameserver being used in production Shankar, Murali
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 
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 ·