Experimental Physics and
Industrial Control System

"Thompson, David H." <[email protected]> · Mon, 12 Apr 2004 10:04:37 -0400

If you are trying to do I/O on the same point you are right.  You can't
really turn most hardware around like that anyway.  There are two or
three cases that I think we (at SNS) need to be able to do
bi-directional I/O; when talking to a smart device and you want to do
bumpless transfer of control between local and remote, when you have a
device that can set one state and depends on Epics to set the other
state, and when you have more than one PV pointing at the same hardware
address in the OUT field. 

The first case comes up in our shared memory applications when operators
at a LabView screen want to take local control of a diagnostic.  We want
to be able to "reflect" settings made in LabView back to the remote
Epics screen.  I have no control over how the diagnostics folks operate,
that is how they want to do it.

We have a lot of the third case, in all of the timing system and the
Machine protection system there are many PVs on engineering screens
organized to align with the hardware board/channel layout and operating
screens that organize according to the connected devices. When PV
aliases become available we can get rid of all of these.

In all cases: Changes to the data are operator originated for at least
one of the states, and "He who writes last writes best." is acceptable.

======================================================================

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