Experimental Physics and
Industrial Control System

"Brian McAllister" <[email protected]> · Thu, 14 Dec 2000 17:34:18 -0500

> > - Clients are free to specify any desired value as the monitor
> >   deadband, as long as the corresponding pv is triggering and its
> >   primitive type is a number.
> > - On successful connection to a pv, the server may suggest related pvs
> >   that contain suitable deadbands such as the corresponding MDEL and
> >   ADEL fields, if such fields exist.
> 
> Only the server tool can decide on its own when its data has changed, and
> therefore an event should be posted. Otherwise, we are forced to poll the
> data from the server and introduce additional overhead and also
> propagation delays.
> 
> It is however desirable in future versions to allow the client to specify
> a wider deadband than what is used by the server tool to decide if its PV
> has changed. This is already on the list.

How do you propose implementing this for IOC databases ?

The decision for whether to post a monitor is made by the record, not by
the server.

How do you handle a client that requests a *smaller* deadband than the one
defined in the record ? Are you suggesting that records always post
monitors and let the server decide whether to actually send them out ?
Sounds like it could be a real performance hit.

We use custom records that implement multiple MDEL- and ADEL-like fields,
which we of course had to define new names for.
How would that be supported ?

----
Brian McAllister                    Controls Programmer/Beam Physicist
[email protected]                        MIT-Bates Linear Accelerator
(617) 253-9537                                           Middleton, MA

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System