Hi Harvey,
It's very interesting to read about your experiences - we are using soft motors for very similar purposes, and like you have encountered a number of teething problems.
One thing I noticed is that your real motors are doing retries, and we found that in this case you must set the .NTM field of the soft motor to "NO". Otherwise, whenever one of the real motors does a retry, the soft motor recognises the change in direction and thinks it is going the wrong way, so it fires its .STOO link to halt the move. Looking at your db it seems you have already done this, but although the actual value is correct, the comment above it (in gap_softmotor) is wrong.
I would also definitely recommend Tim's suggestion of gating the DMOV input.
Many of our other problems stem from the fact that some of our soft motors and real motors run on different IOCs, even separated by a CA gateway. If you have this requirement too let me know as it's always useful to share experiences.
Cheers,
Emma
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Rarback, Harvey
> Sent: 22 February 2008 00:54
> To: [email protected]
> Subject: Problem with soft motor record
>
>
> Motor record gurus,
>
> I have encountered a number of problems with my use of the
> soft motor record. I am using motor driver version 6.22
> (with SLAC modifications for RTEMS) on EPICS base 3.14.8.2.
> The hardware is an OMS MAXv-8000 motor controller along with
> Kramert 505F SSI encoder readout.
>
> First the part that works pretty well:
>
> One soft motor "RowPhaseMotor" (see attached
> epu_softmotor.db) that moves four real EPU girder motors (see
> epu_realmotors.db). We have no encoders for these temporary
> motors and so use motor pulses as our position readback. The
> soft motor links RDBL, DINP, and STOO seem to behave as
> documented with the exception that "the value specified by
> DINP is used to set the DONE bit in the MSTA field; which in
> turn sets the DMOV field". The DONE bit appears to always be
> set correctly, but the DMOV field sometimes remains at zero
> after the move.
>
> Now the problematic part:
>
> One soft motor "GapMotor" (see gap_softmotor.db) that moves
> two real undulator jaws (see gap_realmotors.db). There are
> absolute linear encoders on the two jaws and I have set a
> retry count of two for both motors because of mechanical
> imperfections and magnetic deflection forces that don't allow
> reproducible motions. Each jaw motor/encoder combination
> seems to work ok. When I try to control these jaws with the
> soft motor, weird non-reproducible things happen:
>
> - the DONE bit often stays true throughout the soft motor move
> - the DMOV field stays false during and after the move
> - the soft motor will process and move again after both
> real motor moves are finished
> - sometimes one of the two jaws will start moving without
> any command.
>
> I've tried various ways to get the done condition to work,
> but without success. I would appreciate any suggestions.
>
> --Harvey
> ----
> Harvey Rarback phone:
> (650)926-3963 Stanford Linear Accelerator Center fax:
> (650)926-4100 2575 Sand Hill Road home
> phone: (650)560-9111 Menlo Park, CA 94025
> [email protected]
> http://ssrl.slac.stanford.edu/~rarback
>
> "Always tell the truth, that way you don't have to keep track."
> Pogo
>
>
- References:
- Problem with soft motor record Rarback, Harvey
- Navigate by Date:
- Prev:
Re: TTL output with soft IOC on Linux David Dudley
- Next:
Re: Multiple target os-class application build Andrew Johnson
- 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 with soft motor record Tim Mooney
- Next:
FW: Problem with soft motor record Rarback, Harvey
- 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
|