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  2013  <20142015  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  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Sequencer 2.2.0
From: "Mooney, Tim M." <[email protected]>
To: Benjamin Franksen <[email protected]>, "[email protected]" <[email protected]>
Date: Mon, 15 Sep 2014 15:42:49 +0000
Hi Ben,

I'm fine with all of this.  I think all my stuff is compatible with both 2.1 and 2.2, but I haven't used 2.2 yet because I haven't gotten it to run on vxWorks.

Tim Mooney ([email protected]) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab


________________________________________
From: [email protected] [[email protected]] on behalf of Benjamin Franksen [[email protected]]
Sent: Monday, September 15, 2014 9:46 AM
To: [email protected]
Subject: Re: Sequencer 2.2.0

Hi Folks

I am having second thoughts about one of the new features in version 2.2.

tl;dr: I want to go back to allowing calls to the usual built-in pv functions
only with single channels and instead introduce new, differently named
functions for arrays of channels ("multi-pv arrays"). My hope is that 2.2 is
not yet widely used and so the damage this will do is limited.

Here is the long text.

The sequencer in version 2.2, as it stands, aims to allow calls built-in pv
functions not only for expressions denoting a single channel, but also for
arrays of channels, wherever this makes sense. Such calls were allowed
previously, but (with one exception) did not do what you would expect: it
meant that the function operated on the first element of the array.

The plan for 2.2 was to give a more useful semantics to such calls: do the
action for *all* contained channels.

I won't go into the details of how to enable/disable this feature with an
additional option here, because that is irrelevant to the question.

The main gripe I have with the feature is that it blocks the path to a future
improvement: to allow users to define functions in SNL that can operate on
channel variables just like the built-in functions. A beautiful side-effect of
this change (plus the addition of defaults for function parameters) is that
the built-in functions now have valid SNL types. This means all the code in
the compiler that handles calls to built-in functions in a special way can be
scrapped. The compiler initially inserts the appropriate function symbols into
the top-level scope and all else works as it should... with one exception:
there is no reasonable systematic way of making a type T and also the type
T[5] (or *T) instances of the same type scheme. And that means I would have to
re-introduce all the special handling for built-in functions, which would make
me very unhappy.

This is why I would like to change version 2.2 so that:

* all existing built-in functions give compile-time errors when called with an
  array of channels

* new functions are introduced in those cases where operating on all contained
  elements of an array makes sense.

Please note that all this concerns only arrays where the elements are
separately assigned to different channels. It has nothing to do with the
channel's underlying value type, which can be an array or a scalar.

I have polled for opinions with regard to naming these functions before, but
my preference has changed to adding the word 'array' somewhere in the name
(currently I am favoring pvArrayXxx), because when the stuff I am working on
is finished, there will be more ways to aggregate channel variables: you can
define structs with members of channel type, for instance, and the functions I
am proposing to add will only work on simple arrays. (You will be able to
define you own function for structs that contain channels or even structs of
arrays of structs etc...)

There is also the one function to consider that had the 'do it for all
contained channels'-behavior in 2.1 (and even in 2.0): pvPutComplete. It even
has a number of optional arguments to better support this. My current plan is
to reduce this function to the simple one-channel variant, and add a new
pvArrayPutComplete with the extended functionality.

I think all this can be done without introducing any incompatibilities to the
C API. In fact, I am thinking about fixing those incompatibilities I already
introduced, namely those concerning the added timeout parameter for seq_pvGet
and seq_pvPut functions, by adding new C functions seq_pvGetTmo and
seq_pvPutTmo.

Let me know what you think.

Cheers
Ben


Replies:
Re: Sequencer 2.2.0 Benjamin Franksen
References:
Sequencer 2.2.0 Benjamin Franksen
Re: Sequencer 2.2.0 Benjamin Franksen

Navigate by Date:
Prev: Re: Sequencer 2.2.0 J. Lewis Muir
Next: Re: Sequencer 2.2.0 Benjamin Franksen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Sequencer 2.2.0 Benjamin Franksen
Next: Re: Sequencer 2.2.0 Benjamin Franksen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 17 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·