Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Thu, 16 Sep 2010 22:15:03 -0400

Hi Ben,
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.
Cheers,
Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System