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

Subject: Re: Attention, poll: Who needs the sequencer's pv layer?
From: Benjamin Franksen <[email protected]>
To: [email protected]
Cc: Jimmy Johnson <[email protected]>
Date: Wed, 10 Nov 2010 15:30:51 +0100
On Friday, October 29, 2010, Benjamin Franksen wrote:
> On Friday, October 29, 2010, Al Honey wrote:
> > Is it possible to have the PV/KTL support be some sort of build option,
> > as it is intimately tied into the Keck Observatory's current use of the
> > sequencers.
> 
> I don't think this would make much sense. I would have to plaster the
> sequencer code with conditional compilation directives, not a goal I
> aspire to.
> 
> Now that I know it actually gets used, I'd rather see if I can make the
> CA binding more efficient. So far, I have not yet changed anything
> significant in the pv layer. If I find that I need additional
> functionality from CA, I might ask you guys if it is possible to do
> something similar with KTL so we can extend the pv API.
> 
> > [...]
> > Kevin Tsubota returns from vacation next week so I will make sure he,
> > I, and Jimmy Johnson have a discussion on this issue.

My (currently) most important question is: Does anything else beside the 
sequencer itself use the API as defined in src/seq/pv.h in the sequencer?

I am asking because I would like to make a number of changes to this 
interface, so it gets easier to use and wastes less resources.

For instance, currently pv.h declares structs for the 12 supported data 
types, and a union of such structs, in a way similar to db_access.h. For CA 
this approach makes a certain sense (though it could be greatly simplified), 
because the dbr_* structures define not only the (client) API but also the 
wire format of CA messages. However, the PV layer does not define its own 
network protocol, just a common API, so these structure/union definitions 
are not too useful. A better approach would be to define a single (opaque) 
type pvMessage with appropriate accessors for status, severity, timestamp, 
and value. With such an interface one could also avoid copying each message 
twice, as is currently the case, namely once between CA buffer and to PV 
buffer, and then between PV buffer and sequencer buffer.

Cheers
Ben

References:
Attention, poll: Who needs the sequencer's pv layer? Ben Franksen
Re: Attention, poll: Who needs the sequencer's pv layer? Benjamin Franksen

Navigate by Date:
Prev: FW: EPICS Suggestions and Priorities Andrew Rhyder
Next: Re: EPICS Suggestions and Priorities Ralph Lange
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Attention, poll: Who needs the sequencer's pv layer? Chestnut, Ronald P.
Next: Last chance to save the sequencer's pv layer Ben Franksen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 14 Nov 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·