Bob Dalesio wrote:
Some options:
Use the hardware capability in the OMS card -
Requires modification to driver, device support and record
support. Perhaps write an undulator record that accesses
this synchronized move in the modified driver.
Modify the driver support to wakeup the database on each
readback. The driver reads the motor position at 30 Hz. If
there was analog input device support that posted this
event, database logic could be used to wake up at 30 Hz
while the motor is moving and verify that the difference
in the gaps is constant or within tolerance. A stop to the
motors if they are starting to diverge would occur within
40 msec. This would be a minimal change to the device
support and driver and may still meet the requirements.
Bob
On Fri, 12 Dec 2003 13:38:17 +0100
Rok Sabjan <[email protected]> wrote:
>Hello everyone!
>
>I'm trying to prepare a proposal for ID control system at
>Diamond. During that time I have been asking some people
>some questions how this is currently managed in EPICS. To
>my surprise I found out that there was no clear way to
>solve this problem. I had a discussion with Tim Mooney
>and we were thinking of some possible solutions for the
>biggest problem - synchronous motor movement under EPICS.
>We have developed some suggestions, but I think it is
>time to broaden the discussion to tech-talk. There may be
>more people interested in such solutions and there are
>probably some people with some experience on the matter.
>
>First let me remind everyone on the problem. We have two
>(or more) motors which we would like to move
>synchronously. This means to guarantee the movement will
>start and end at the same time. This is extremely
>important when changing the gap of an insertion device.
>
>One may suggest that we should just wire the signal lines
>together (hardware solution) and use one signal line to
>control multiple motors, but we also want to move these
>motors independently. We may implement some logic (using
>FPGA or some other programmable logic) to multiplex this
>one signal line in one operation mode and use multiple
>signals for different motors in some other mode.
>
>The OMS VME58 card, which is normally used in EPICS for
>motion control, supports such synchronized moves, but
>this is (to my knowledge and experience) not supported
>via EPICS motor record and device support. We should also
>provide some kind of sync record, which would take
>control of correspondent motor records (when instructed
>to do so) and would then perform the synchronized moves.
>Needless to say, there are a lot of design choices to
>identify and make on the behaviour of this record.
>
>This mail is intended to identify people who have common
>interest for such a development in EPICS community.
>Definitely, we will have to make some modifications to
>the existing motor software if we decide to go through
>with any of these ideas. The idea is to make a general
>EPICS solution for such situations.
>
Hello,
we driveID (or two IDs in the case of dual undulators) with a monochromator
using the sscan record combined with the busy record. The point is, that
if the busy record is rised upon an activation of an sscan positioner,
the sscan is blocked until 'somebody' resets the busy record. This
'somebody' could be a calcout record like:
record(calcout,"$(P):alldone"){
field(SCAN,"Passive")
field(INPA,"$(P)withID1:STATUS
CP NMS")
field(INPB,"$(P)withID2:STATUS
CP NMS")
field(INPC,"$(PGM):dmov
CP NMS")
field(CALC,"A=1&&B=1&&C=1")
field(OCAL,"0")
field(OOPT,"Transition To
Non-zero")
field(DOPT,"Use OCAL")
#
<--- here the busy is reset
field(OUT,"$(P):busy PP")
}
and if you put the $(P)-E:GO transform record below as a positioner
in you sscan
# select here what to un synchronously
record(mbbo,"$(P)-E:OPT"){
field(ZRST,"PGM")
field(ONST,"PGM+ID1")
field(TWST,"PGM+ID2")
field(THST,"PGM+ID1+ID2")
field(DOL,"0")
field(PINI,"YES")
}
record(transform,"$(P)-E:GO") {
field(PREC,"3")
field(CLCA,"a")
field(CLCB,"1")
field(CLCC,"a")
field(OUTA,"$(P):energy
PP")
# set the busy record to 'busy'
field(OUTB,"$(P):busy PP")
field(OUTC,"$(P)-E:GOPGM
PP")
}
# this is the monochromator +ID1 + ID2 energy PV
record(ai,"$(P):energy")
{
field(PREC,"3")
}
record(seq,"$(P)-E:GOPGM"){
field(SELM, "All")
field(DOL1,"$(P):energy")
field(LNK1,"$(PGM):energy PP")
field(DO2,"1")
field(LNK2,"$(PGM):setE.PROC")
field(DO3,"1")
field(LNK3,"$(P)-E:GOID1.PROC")
}
record(calcout,"$(P)-E:GOID1") {
field(INPA,"$(P):energy")
#
<-- use INPC if there is an energy shift between the mono and ID1
field(INPC,"0")
field(INPB,"$(P)-E:OPT")
field(CALC,"B=1||B=3?1:0")
field(OOPT,"When Non-zero")
field(DOPT,"Use OCAL")
field(OCAL,"A+C")
field(OUT,"$(BML)-ID1:ENERGY
PP")
field(FLNK,"$(P)-E:GOID2")
record(calcout,"$(P)-E:GOID2") {
field(INPA,"$(P):energy")
#
<-- if INPC if there is an energy shift between the mono and ID2
field(INPC,"0")
field(INPB,"$(P)-E:OPT")
field(CALC,"B=2||B=3?1:0")
field(OOPT,"When Non-zero")
field(DOPT,"Use OCAL")
field(OCAL,"A+C")
field(OUT,"$(BML)-ID2:ENERGY
PP")
}
###################################################
# checking up the ID1/ID2 status for $(P)alldone
# considering the E-OPT: i.e whether the ID1/ID2 is
# scanned allong with the mono or not
###################################################
record(calc,"$(P)withID1:STATUS") {
field(SCAN,"Passive")
field(INPA,"$(BML)-ID1:STATUS CP NMS")
field(INPB,"$(P)-E:OPT CP NMS")
# +-+--------- 0 means ID1 done
field(CALC,"B=1||B=3?(A=0?1:0):1")
}
record(calc,"$(P)withID2:STATUS") {
field(SCAN,"Passive")
field(INPA,"$(BML)-ID2:STATUS CP NMS")
field(INPB,"$(P)-E:OPT CP NMS")
# +-+--------- 0 means ID2 done
field(CALC,"B=2||B=3?(A=0?1:0):1")
}
####################################################
and if you handle separately the "done" state of the monochromator,
ID1, ID2, you get a general template based solution to synchronous scans.
Cheers
_____
Swiss
/ / [email protected]
_/_/_/ _/ _/_/_/
/____ Experimental Division
_/ _/ _/
Source / Paul Scherrer Institute
_/_/ _/ _/_/
____/ CH-5232 Villigen-PSI
_/_/Light
_/ / Tel: ++41 56 310 5131
_/_/_/_/_/_/_/ _/_/_/___/ Fax: ++41
56 310 3151
- Replies:
- Re: Insertion Devices Control and EPICS Rok Sabjan
- References:
- Re: Insertion Devices Control and EPICS Bob Dalesio
- Navigate by Date:
- Prev:
Re: Spurious link alarms generated? Marty Kraimer
- Next:
Re: Insertion Devices Control and EPICS Rok Sabjan
- 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: Insertion Devices Control and EPICS Bob Dalesio
- Next:
Re: Insertion Devices Control and EPICS Rok Sabjan
- 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
|