Experimental Physics and
Industrial Control System

[email protected] (Bob Dalesio) · Mon, 5 Dec 94 15:01:56 MST

To do this correctly, there would have to be several changes.

The analog output record does fetch the value before sending a new output. The
fetch does NOT call device support, however. So there is little value here.
Even if it did call device support, it proceeds to write out the new output
(whatever is in VAL) regardless of what it read. It doesn't even consider the
possibility that the outputs can change through any other mechanism. This could
be a deficiency of the analog output record. Perhaps it should be modified to
handle this for all cases. If so, we would need to revisit all device support
that hooks to analog outputs.

You also have a race condition, where either the Multibus or EPICS tools can
be writing to this area. If they are writing at the same time, this needs to
be detected and a rational action taken.

I think you need a special record.
It would monitor the Multibus memory either as part of periodic record
processing or a device driver callback. This would update EPICS controllers with
the value that was set through the other Multibus interface.
You would need to put in an option for actions to take when an EPICS request is
made in the middle of a Multibus change:
Throw away new output if Multibus memory changed outside EPICS
Override the Multibus value with the new EPICS value
Look at both and pick the largest/smallest changes

If this didn't make any sense, we can go into more detail. In short, I think it
would be easier to create a new record type that handles this. It may be more 
correct to apply this thinking to analog outputs and fix all of the device
support so it incorporates this functionality.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System