Experimental Physics and Industrial Control System

At first, program is reflection of detectors/subsystem, modules
(unfortunately, Epics hasn't it). When people develop REMOTE/LOCAL
switch this question up all time. Who is master - local or remote?
Some years ago we (INR-accelerator division-beam lab) came to two-states
(LOCAL-Middle) switcher and three-positions (LOCAL-Middle-REMOTE)
detector state (operator can see by LEDs). 
So
Remote control 
- has full control in REMOTE position
- can move state from Middle position to REMOTE position
- can just read data in LOCAL position
Local control
- has full control in LOCAL position
- can move state from Middle position to LOCAL position
- can just see data in REMOTE position

At second, bi-direction data is not need usually. Operator in LOCAL
(rack place) and REMOTE (from computer) sets new value and than sees it.
This is two operations, two values ...

Andrei.

-----Original Message-----
From: Purcell, J. David [mailto:[email protected]] 
Sent: Monday, April 12, 2004 12:17 PM
To: Lionberger, Carl A.; Thompson, David H.; Andrew Johnson; tech-talk
Subject: RE: Bidirectional device support

To clarify the LabView implementation as SNS, although deployed via
shared memory, control of the remote/local switch for the LabView
devices is set up as Carl points out.  The switch is implemented in
LabView and only read with EPICS.  Control can not be taken away from
the poor guy testing (probably me).  So operators can not take control
of a diagnostic until it is returned to a remote controlled state.
However, work done locally must be reflected on operator screens and
although Dave Thompson does not have control over how we operate, he has
certainly helped us with shared memory and the "reflection" of settings
allowing us to operate.  I should also say that, obviously, all work
done locally is coordinated with operations.   


Dave

-----Original Message-----
From: Carl Lionberger [mailto:[email protected]] 
Sent: Monday, April 12, 2004 10:57 AM
To: Thompson, David H.; Andrew Johnson; tech-talk
Subject: RE: Bidirectional device support


I think the desire for bidirectional records reflects some personal 
preference; some people think there is some kind of elegance about it.
I 
agree with Andrew that it is not realistic.  I think it can be easily
avoided 
in all cases, as I outline below.

>===== Original Message From "Thompson, David H." <[email protected]> 
>===== 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,

This sounds equivalent to having a remote/local switch on the device;
the 
switch is implemented in labview.  I thought it was SNS policy to not
have 
EPICS control remote/local switches.  These should be controlled at the
device 
(locally).  EPICS reads them.  Some poor guy locally testing the
hardware 
should not have control taken away from the control room.  Its not safe.

[>]when you have a
>device that can set one state and depends on Epics to set the other 
>state,

For this you have an output record that sets it and a readback record
that 
reads it.  I find the least confusing way to do this is to have the
output 
record be momentary, ie, a bo with a HIGH of about 1 so that when you
push the 
button it sets the state (which is read out) and returns to standby.

[>]and when you have more than one PV pointing at the same hardware
>address in the OUT field.

In this case, last gets it. This just says you monitor the val field.
The 
difference from the normal case is that all device supports which write
to the 
same hardware must post monitors when any of them controls it.  Its not
really 
bidirectional control.

Carl

Carl Lionberger
SNS Controls Group
(865) 574-7636

Replies:

RE: Bidirectional device support Ralph Lange

Navigate by Date:

Prev: RE: Bidirectional device support Tang, Johnny Y.

Next: RE: Bidirectional device support Robby Tanner

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: Bidirectional device support Tang, Johnny Y.

Next: RE: Bidirectional device support Ralph Lange

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