Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Thu, 23 Nov 2006 22:11:42 +0100

On Thursday 23 November 2006 16:36, Lecorche Eric wrote:
> Let us imagine 
> that to implement the device I must introduce internal records (calc,
> fanout ...) : is it a good approach to name them
> "LEB1-G-Q12:IntCalc1", LEB1-G-Q12:IntCalc2","LEB1-G-Q12:IntFanout1"
> ("Int" for "Internal record") ?
> [...snip, see below...]
> Also, I am aware that if later my "internal record" has to 
> be seen by the operator either its name becomes meaningless or I have
> to rename the record (without forgetting "internal" clients such as
> the sequencer for example ...).

While the general approach to naming internal records (i.e. 
DeviceName:SignalName like the user visible ones) is obvious and good 
for consistency, I don't recommend to encode the record type in the 
record name. You name a good reason in your last question. Also, it is 
redundant, a simple query 'caget XYZ.RTYP' will give you (and any CA 
client program) the record type with no effort. Most importantly, the 
record name should give an indication as to /what/ it does, rather 
than /how/. That doesn't mean a calc record must never contain the 
word 'calc' -- it should, but only if calculation of some value is its 
main purpose, and if it isn't clearer to name it just after the result 
value it produces. Thus, if it implements an internal counter, 
then 'counter' or 'count' or maybe 'cnt' should appear in the name, 
etc.. For examples of generic internal names see the section 'Private 
Channels' in the new Bessy signal naming convention that Ralph sent to 
the list.

> And how can I solve the case when 
> some internal record belong to the processing chains of two different
> devices ?

Well, apart from making some arbitrary choice left to the developer 
there are two major heuristics I tend to use: Let's say we have n 
devices of type A and m devices of type B. If the 'in-between-record' 
has n instances this strongly suggests giving it an A:xxx name, with 
the obvious analog for the case of m instances. More generally, it 
sometimes makes sense to chose names depending on the application that 
instantiates the record, rather than physical connectedness. If it 
rurns out that one needs a lot of such not-clearly-nameable records, 
there is a fat chance that you need to introduce a new 'abstract' 
device. Thus you should make sure that there is room for 
abstract 'soft' devices in your device naming convention and not only 
for concrete physical ones (which means, for instance, that physical 
location should rather not be a mandatory part of the device name 
convention).

As an aside, since such 'soft' applications tend to come later in the 
development, i.e. only some time after the basic device control stands, 
there is a tendency to concentrate on the concrete devices at first, 
and this tends to influence the naming convention in a certain way, 
like enforcing physical location which later on give you headaches.

There are also situations where it seems appropriate to allow /two/ 
device names to appear in a record name.

The Bessy convention allows an arbitrary number of intermediate elements 
(separated by colons) where only he first and last one (device name 
resp. signal name) are regulated at all (this one is not meant as a 
recommendation, it is just how things are). Intermediate elements 
usually denote either a subsystem (so the names is to be interpreted as 
device:subsystem:subsubsystem:signal) or else denote an intermediate 
record that hangs right between device A and device B. An concrete 
example is our tune feedforward, where many record names contain the 
device name of an insertion device (input), as well as the name of a 
quadrupole power supply (output), in addition to the application 
('device') name.

If you plan to allow hierarchical record names or name that may mention 
more than one device, make device names SHORT. Otherwise you'll soon 
run into the 28 char record name limit that is currently imposed (more 
or less) by channel access.

Cheers
Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System