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
<2010>
2011
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
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|