Bidirectional device support

[Andrew Johnson <anj@aps.anl.gov>]

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