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: Testing the new DBE property in EPICS R3-14-11
From: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Fri, 17 Sep 2010 11:24:45 +0200
On Friday, September 17, 2010, you wrote:
> On 16.09.2010 12:44 Ben Franksen wrote:
> > Another idea for increasing usability: Forget about DBR_XXX in the user
> > interface. Instead, let them specify a set of properties and display
> > just those, using whatever DBR type is appropriate (i.e. a superset).
> > If there is none (e.g. the user requests "timestamp+display_limits") we
> > could (a) give up and tell the user why, or (b) set up two monitors,
> > one with DBR_TIME_XXX and one with DBR_GR_XXX, then correlate the
> > events and merge them.
> 
> While I perfectly understand the idea behind that approach, I don't like
> it for the command line tools.
> 
> They are meant as a swiss army knife for tracking down Channel Access
> and IOC issues. One of the major reason for them is that with all the
> fancy and luxurious high level GUIs and tools, you never really know
> what kind of CA operations they really do, what DBR types they are
> asking for, what event flags they use, etc.
> The command line tools have to have a simple, one-to-one correlation
> between the options on the command line and their actions.
> A "caget <PV>" does exactly one CA get operation. If you specify the DBR
> type, it will use that type, and it will print exactly the data that
> comes back. That's it. No hidden extra calls, no data filtered out.
> A "camonitor <PV>" sets up exactly one subscription. If you specify the
> event mask, it will use that mask. It prints one line for every update
> that comes in.
> 
> If we start doing too many additional "automatic" things behind the
> curtains (e.g. setting up additional monitors, doing cagets to get
> metadata the subscription doesn't deliver), the command line tools may
> become nicer, but a lot less useful. There are enough nice CA clients
> around where you don't know exactly what they are doing on the wire.

You have a point there.

Cheers
Ben

References:
Testing the new DBE property in EPICS R3-14-11 Xu, Chengcheng
Re: Testing the new DBE property in EPICS R3-14-11 Ben Franksen
Re: Testing the new DBE property in EPICS R3-14-11 Ralph Lange

Navigate by Date:
Prev: Re: Testing the new DBE property in EPICS R3-14-11 Ralph Lange
Next: Reservations at the Cronwe Plaza Long Island Dalesio, Leo
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: Testing the new DBE property in EPICS R3-14-11 Ralph Lange
Next: Can devices supported in areaDetector include Jai and Imperx?(links to the data sheets ) 孟欣东
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, 17 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·