Experimental Physics and
Industrial Control System

Kay-Uwe Kasemir <[email protected]> · Mon, 17 Oct 2005 13:41:01 -0400

Hi:

On Oct 17, 2005, at 11:57 , Marty Kraimer wrote:

2) It is not in the slides but at the presentation Mark said that

it is easy to allow ACS to talk to epics but hard to have epics

talk to ACS. I will go further and say that it will be hard to make

any wide interface talk to another wide interface unless they are

very similar. A strength of EPICS is that other systems can talk to

it.

Yes, EPICS is easier to interface than other middlewares
since it's only a flat list of properties that one
can read and sometimes write.
TANGO, ACS distinguish between commands and properties,
even commands, static properties and attributes that change at runtime.

1) The IOC database is the heart of EPICS iocCore. It is what

distinguishes EPICS from the other control systems in use by the

accelerator and telescope control systems. Most of the others have

the concept of device servers in the front ends rather that an

intelligent runtime database, which means that the intelligence

resides in the workstations or else is implement in an ad-hoc way

in the device servers or in some other systems like PLCs.

2) The interface to the IOC database is narrow in the sense that

communication is done via data rather than a large set of objects.

This is what allows general purpose tools like display managers and

what makes it easy for other systems to talk to IOCs. In EPICS

facilities it is common for operators to create displays for MEDM

or EDM. I suspect that tools like the the tango gui builder would

be used by programmers rather than operators or hardware oriented

engineers. Thus we must be carefull about how much device

orientation we introduce into IOCs. Perhaps a power supply but not

a high level physics abstraction.

Isn't it strange that on one hand we have an intelligent database,
but only a flat channels-with-properties interface to it?
Our display tools only read & write values from/to properties.
MEDM doesn't know that writing to the 'jog' fields of a motor
record actually issues a command, while writing to the
max. velocity field changes something that should probably
be stored for bumpless reboot.

V4 won't change this. Should it?
It it sufficient for redundancy to simply mirror the values
of records' fields, or is it necessary to know a bit more
about what the fields do, i.e. start a command?

-Kay

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System