Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Thu, 12 Jul 2007 06:47:50 -0500

> Personally, I would even go as far as setting dbLoadTemplate on the IOC to "deprecated" status. 
> I don't see an advantage over host side expansion. 

I strongly disagree with this.  Doing host-side expansion requires an EPICS build system.  I support dozens of EPICS installations (e.g. beamlines at NSLS, IOCs running detectors at APS, NSLS, and ALS ) that use only pre-built EPICS binaries that I provide.  The personnel running these systems do not have or need the skillls to be EPICS developers.  They can and do customize their installation by creating and modifying .db, .template and .substitutions files, medm screens and startup scripts.  They can do all of this without needing to run "make".

Even on our local installation the beamline scientists can and do edit database files, but do not need to learn how to (and remember to) run "make" each time they make a change.

Running dbLoadTemplate on the IOC is very fast when the IOC uses NFS or a local file system.  Performance is not an issue.

Mark

________________________________

From: [email protected] on behalf of Ralph Lange
Sent: Thu 7/12/2007 4:59 AM
To: Emmanuel Mayssat
Cc: EPICS Tech Talk
Subject: Re: dbLoadRecord or dbLoadTemplate

Hi Emmanuel,

Using dbLoadTemplate on the IOC to blow up template databases has two noticeable disadvantages compared to blowing up the templates on the host:

*	You lose the ability to use macro substitution on the IOC. (Which your mail is about.) 
*	The process can be slow, as the template database is re-read from the file system for every instance. If the IOC uses remote shell or ftp access, this adds up to half a second or so for every instance. If you break things down to e.g. each single error bit being an instance of a template database, this can easily add up to minutes. (That's where we changed plans...)

We have changed all our IOC applications to blow up the templates on the host side. When doing this, you may leave unresolved macros in the database, which can be substituted at load time using the technique you are describing.

I would strongly suggest blowing up templates on the host side, as it gets you fast load times plus macro expansion on the IOC.

Personally, I would even go as far as setting dbLoadTemplate on the IOC to "deprecated" status. I don't see an advantage over host side expansion. (That might rather be a core-talk issue, though.)

Hope this helps,
Ralph

ps. There is absolutely no need to push your substitutions into the IOC's environment.

   dbLoadRecord(file.db,"deviceName=toto")
does exactly the same job. (Embedded spaces can still be used: enclose the substitution string with a pair of \"s.)

Emmanuel Mayssat wrote: 

	All, 
	Most of you must be familiar with dbLoadRecord and dbLoadTemplate.
	I like the first one because you can pass parameters which are not
	necessarily hard coded (i.e. you can use the same db file for different
	instances).

	epicsEnvSet(DEVN,"toto")
	dbLoadRecord(file.db,"deviceName=$(DEVN)")

	I like the dbLoadTemplate because of the clarity, but then for each
	device instantiation you need to create a complete substitution file.

	Is there a way to do something like this:
	dbLoadTemplate(file.sub,"deviceName=$(DEVN)")
	Where the db files is generated and then parsed once again with macro
	provided in command line?

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System