Experimental Physics and
Industrial Control System

"Chestnut, Ronald P." <[email protected]> · Fri, 17 Nov 2006 10:54:27 -0800

Ok, I'll bite too...

For small projects with few people and few subsystems the naming convention thing is mostly an ongoing annoyance - it's pretty easy to go change things or just make exceptions or simply leave the resulting chaos in place.

All large projects (at least the recent ones) start with fabulous intentions. The names are constructed to be immediately recognizable by all involved. Simple regular expressions can parse everything. Then the left-handed reverse frambus on the third beam-line spur appears, or some (necessary) secondary support PVs are needed for something, which overloads the original naming convention at some level, or something else unforseen (and unforseeable) happens.

[This reminds me of the management request: "I need a list of specific unknown problems we will encounter!"]

Aliasing can provide some user-level protection from the underlying names. Many subsystems or middleware implementations provide this. When developers need to step into the quagmire to find some interesting problem, they nontheless still need to understand the whole mess.

Sometimes an institute has a hero(ine) who will keep raking through the pile and removing the rotten bits. A benevolent dictator approach works for a while, until the deadline pressures outweigh even his barking.

So a GOOD naming convention starts like Newt Gingrich's congress, with great intentions and high ideals. Some of that survives the rough and tumble of getting a machine going. Ultimately the structure needs fixing or all simply hang their heads and stumble forward.

With a system like IRMIS, which, when it is set up correctly, shows all PVs on all IOCs, as well as all config files and displays in which they are used, one has a chance of keeping track of things. Exceptions to the general GOOD naming convention can be kept up-to-date (by hand, mostly) in an ancillary spreadsheet. One even may have enough information to know everything that needs renaming to fix the exceptions.

Sorry for the mix of metaphors. I really don't see how to do this perfectly, but we will keep learning from each other.

Ron Chestnut

-----Original Message-----
From: Emmanuel Mayssat [mailto:[email protected]] 
Sent: Friday, November 17, 2006 10:31 AM
To: Gurd, Pamela A.
Cc: Andrew Johnson; tech talk
Subject: GOOD Naming conventions for devices and Epics records

I think what is important in this thread is not what naming convention is being used at site X, but rather what makes a GOOD naming convention.

Here is what I learned from naming conventions with epics.

1/ I like to know which hardware part is providing the signal.
This provides a tremendous help for low level debugging.
(ex. Signals is from pin 2 on ADC 3 on computer X [located at Y])

2/ End user cares about the meaning of the signal. 
(ex. Temperature of gun, setting of 3rd magnet in transport line)

3/ PV names are often found hardcoded in programs

4/ Low level and high level programming is managed by 2 different groups. 

Solution:
Use several (two) naming conventions! 
One for each level and use ALIASING!!!!!

Q: What happens if you change hardware?
You change the low level PV names and the inputs of aliases.
No need to change programs, striptools configuration files, etc.

Enjoy!

--
Emmanuel Mayssat
Lyncean Technologies, Inc

On Fri, 2006-11-17 at 12:33 -0500, Gurd, Pamela A. wrote:
> It's true that we have had problems with the sequencer going over 28 
> characters, but I think they're less of a problem than it would be to 
> try to stay within 28 characters.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System