Experimental Physics and Industrial Control System
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
- Navigate by Date:
- Prev:
Re: EPICS Meeting Noboru Yamamoto
- Next:
RE: Bidirectional device support Carl Lionberger
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
<2004>
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: Problem starting StripTool Jeff Hill
- Next:
RE: Bidirectional device support Carl Lionberger
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
<2004>
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024