Experimental Physics and Industrial Control System
|
Here are some more thoughts ... I'm not actually responsible for insertion
device software here at SLS but I had a quick talk with Timo Korhonen (who
was responsible) before composing this, so I hope it gives a reasonable
representation of our experience ... any errors are mine, not Timo's.
As long as we are talking about stepper motors, I should be very surprised
if the existing EPICS motor support is unable to handle the application,
_assuming that you have got your engineering correct_, i.e. your motors do
not lose steps. The OMS card generates deterministic pulse trains to its
motors as given by the acceleration and other motor parameters. Hence, the
motions of the 2 ends of the insertion device are also deterministic.
The problem therefore reduces to getting the motors to start synchronously.
This can be done pretty (sorry, I can't quantify any of this; it hasn't
been an issue that has required measurements) reliably by driving both
motors from a single OMS card triggered by suitable fan-out and motor
records in the same ioc which is controlling the OMS card.
We have such insertion devices at SLS and they work fine ... well most of
the time. There can be problems if a movement is aborted and the direction
of motion is then changed. I shouldn't think that using the synchronised
motion support of the OMS card is going to help is such situations anyway.
Servo motors are more tricky. We do have some insertion devices driven by
servo motors. In these cases, the magnetic forces between the components
are such that it turned out to be inadequate to use encoders on the motor
shafts. We had to have encoders measuring both ends of the undulator gap
and feed these encoder signals into the corresponding OMS cards. The PID
control in the OMS cards then manages to keep the 2 ends of the undulators
sufficiently synchronised.
David Maden
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.
Cheers,
Rok
Bob Dalesio
[email protected]
410 557 0297 Maryland
505 667 5643 Los Alamos (New Number)
505 699 1632 Cell Phone
505 667 6087 Our Secretary (Lisa Marie)
- Replies:
- Re: Insertion Devices Control and EPICS Dirk Zimoch
- References:
- Re: Insertion Devices Control and EPICS Bob Dalesio
- Navigate by Date:
- Prev:
Re: Insertion Devices Control and EPICS Mohan Ramanathan
- Next:
RE: Insertion Devices Control and EPICS Mark Rivers
- 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 Rok Sabjan
- Next:
Re: Insertion Devices Control and EPICS Dirk Zimoch
- 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
|
ANJ, 10 Aug 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|