Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Fri, 09 Apr 2004 15:38:27 -0500

The talk of how to implement bidirectional I/O through existing record
types still has a fundamental problem that *cannot* be solved using a
single VAL field no matter how you implement it - you're going to throw
away information somewhere if a new output demand occurs at about the same
time as a new value comes back from the device. You cannot simultaneously
hold both a record's last output demand and the value read back from the
device, unless this record provides the only possible way to change that
output. There is no substitute for having two different places to store
the last demand and the readback information.
This means that you cannot have a single button on a display screen which
both sets the output value and gets updated whenever the output gets
modified by some other means. If you manage to create such a button that
appears to work, there will always be some time window where either your
button does not show the actual status of the output, or a user's button
press will be ignored. Neither of these outcomes is desirable, in both
cases the user is likely to complain about flaky software. I can also
imagine situations where you could even cause the output to oscillate,
although those are slightly harder to cause.
Here at APS the accepted solution to this problem is for our MEDM screens
to have buttons or a menu to command the output value, and a separate
indicator for the current status coming back from the device. You can use
menu or radio buttons for the demand, but you must still have the separate
status feedback as well. Eric Norum pointed out that command buttons
should use verbs and the status displays adjectives (Enable -> Enabled),
and this significantly reduces the confusion between the two.
That people are trying to develop bidirectional I/O support is IMHO partly
a reflection on the capabilities of our current record types - the output
record types really should have a separate field for the readback value in
engineering units, but they generally don't. The ao and mbboDirect
records both have an RBV field which may be set by the device support and
can be monitored by CA clients, but the record support code doesn't
convert the long integer value back into engineering units, and neither
has the fields to store the back-converted engineering values anyway.
It would make sense to add a field called say IVAL to most of our current
output record types to hold the readback channel's engineering value -
this would make it much easier for applications developers than requiring
them to create a separate input record for the readback channel.
- Andrew
--
Dear God, I didn't think orange went with purple until I saw
the sunset you made last night.  That was really cool. - Caro

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System