Subject: |
RE: Bidirectional device support |
From: |
"Robby Tanner" <[email protected]> |
To: |
"Liyu, Andrei" <[email protected]>, "Purcell, J. David" <[email protected]>, "Lionberger, Carl A." <[email protected]>, "Thompson, David H." <[email protected]>, "Andrew Johnson" <[email protected]>, "tech-talk" <[email protected]> |
Date: |
Mon, 12 Apr 2004 14:01:20 -0600 |
At the CLS, where LOCAL/REMOTE is available it is a physical switch like
an HOA. If someone at the device switches it to local, that's where it
stays until it is switched to remote. I deal with the Siemens PLCs and
we have a method of syncing the IOC data buffers with those on the PLC
before it is allowed to update after a switch from LOCAL to REMOTE.
As far as a READ/WRITE variable is concerned, from my limited
experience, it appears that one would be useful for checking/setting
bytes of PLC memory.
Regards,
Rob
> -----Original Message-----
> From: Liyu, Andrei [mailto:[email protected]]
> Sent: Monday, April 12, 2004 1:23 PM
> To: Purcell, J. David; Lionberger, Carl A.; Thompson, David
> H.; Andrew Johnson; tech-talk
> Subject: RE: Bidirectional device support
>
>
> 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
>
>
>
>
- Navigate by Date:
- Prev:
RE: Bidirectional device support Liyu, Andrei
- 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
- Navigate by Thread:
- Prev:
Re: Bidirectional device support Luedeke Andreas
- Next:
RE: Bidirectional device support Liyu, Andrei
- 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
|