Subject: |
Re: Naming conventions for devices and Epics records (more ...) |
From: |
Benjamin Franksen <[email protected]> |
To: |
[email protected] |
Date: |
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
- References:
- Naming conventions for devices and Epics records (more ...) Lecorche Eric
- Navigate by Date:
- Prev:
Re: Naming conventions for devices and Epics records (more ...) Maren Purves
- Next:
edm questions about "menu mux" marco_hair
- 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: Naming conventions for devices and Epics records (more ...) Maren Purves
- Next:
Ethernet electrical isolation Touchard Dominique
- 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
|