Experimental Physics and
Industrial Control System

Ned Arnold <[email protected]> · Fri, 2 Nov 2007 08:30:16 -0500

On Nov 2, 2007, at 2:05 AM, Heinrich du Toit wrote:
On Thu, 2007-11-01 at 10:10 -0500, Andrew Johnson wrote:

Heinrich du Toit wrote:

O let me explain.

I want to make some sort of .db file pre-processor that can do some

modifications. Mainly macro expansion type stuff.

And this I want to use so that some rule stuff can be written in
Macro's

and not in long complex records and hopefully make it easier to
maintain

and understand and change. And then maybe also handle some other
stuff

with the pre-processor to keep thing consistently linked ect...
making

it more reliable and less prone to human error. Plus the person
working

with it might not fully understand all the internal stuff of 'n db.

I'm going to assume that you're aware of the dbLoadTemplate()
facilties

of the IOC, and I'd be interested to hear what you need beyond
what that

already provides. I want to try and stop you from reinventing the
wheel

unnecessarily, but I'm not saying that what we have is comprehensive.
You should also be aware of the EPICS Extension MSI (Macro
Substitution

and Include) which implements dbLoadTemplate() expansion on a host

machine and may speed up IOC boot time if you have lots of
templates and

macros to instantiate.

Actually no - somehow I missed the whole LoadTemplate thing!!!
Wonder how that happen - guess you shouldn't assume things :)
Anyways I went through the documentation and it certainly will do
90% of

what I wanted to do - And no I don't want to reinvent the wheel.
The only thing I think that it doesn't do directly that I would've
liked

as sort of writing extra records automatically.
Let me explain:

You have an input record (or more than one)

Then you write some calc and calcout records to do things on that
input

record.

Now It would be nice if this thing created the fanout things by itself

so that all the calc and calcout stuff executes after the input

record(s)

Or is there a better way?

You may be able to eliminate the fanout records by careful design of
forward links and/or input link flags (PP, CP, etc).
For example, if the input record's forward link field referenced the
calc record and the calc record's forward link field referenced the
calcout record, all would process each time the input record
processed ... without a fanout.
For more flexibility, records can also be processed if an input PV
changes by using the .CP flag of the link. In other words, if your
calcout record had an input link such as INPA = "some_AI_record.VAL
CP NMS" then anytime the value of some_AI_record.VAL changed the
calcout record would be processed (no fanout required). CAUTION:
This uses channel access so the records process at a much lower
priority. Sometimes, cleverness can come back to haunt you.

Another example of what I want:
So firstly we have all these input records.
Then from them we have some calc and calcout records that outputs some
values that are meant to control the outputs records.
Then we have the output records.
The problem is that multiple calc records and calcout records is meant

for the same outputs record.

So this means that each rule must have a priority.

And then we possible want some combination of sel and calcout rules
that

will select the correct records output.

You should read and understand about Scan Disable (SDIS). The
processing of records can be controlled (and therefore given
priority) by clever use of this field and a calc record that
calculates "the priority".
Then there is also the Simulation fields for output records (SIML)
which can be used to control where there output record actually
writes its outputs ... which can also be used to make an out record
ineffective.

Soooooooooo many options ....
HTH -
 Ned

But I guess it should be possible to make this atleast easier with
templates , but not exactly automatic.
Thanks for your help!

If you haven't already done so, have a look at the template
facilities

provided by VDCT. Their use may not be completely obvious (and you

should ignore the "grouping" features which are not useful) but they

provide the ability to create template hierarchies and instantiate
them.

VDCT really is the best way to design complex databases at least for

anyone from an electronics background who is used to schematic
diagrams.
In the language of the VDCT template expansion stuff, "macros" pass
instance information from a parent to a child template, while "ports"
pass information from a child to its parent; the "information" I'm
talking about here are macro strings and are not directly related to
database links although they will often be expanded in them.
I'll rather stay away from VDCT
It is also relatively easy to write a DB file parser in modern
scripting

languages such as Perl and Python, but it is also easy to omit some

obscure pieces of the syntax. You should be aware that future major

releases of Base will probably replace the 'C' dbStatic library with

tools written in Perl (which will have a similar Perl library for

manipulating the underlying data).

Sounds interesting

HTH,
- Andrew

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System