Experimental Physics and Industrial Control System
|
Hi Mark,
That was one of the first things I looked at, and based on the
description it seems that the default value (1/Yes) is what you would
normally want for a real motor (which is what my record is using).
Just to see if it made a difference, I changed it to 0/No, and that does
indeed allow it to function. But of course it means that it forces the
motor to finish processing any unfinished move before it will process
any pending move command.
I assume that the driver SHOULD still work with the default Yes value.
Using the No value is not only less efficient, but could be a real
problem. If someone makes a typo when entering a new setpoint, it
wouldn't matter if they realized their mistake and quickly entered the
correct setpoint before the device has moved very much - It would still
go all the way to the incorrect setting before starting to move to the
correct position.
Even worse is the problems that could result when setting up a new
device if there isn't a limit switch to protect against moving too far
in one or both directions, or if there is a problem with the limit
switches. The former is in fact precisely the case I will be working
with probably within the next week (a new device that has one switch
meant for homing - which of course could double as a limit in that
direction - but no switch at all for motion in the other direction).
Mark
Mark Davis NSCL/FRIB Control Systems Software Engineer [email protected]
On 8/1/2018 10:21 AM, Mark Rivers wrote:
Hi Mark,
The motor record contains an NTM field that controls the behavior when a new target value is entered and the motor is still moving. What value does NTM have for your record?
Mark
________________________________
From: [email protected] <[email protected]> on behalf of Mark Davis <[email protected]>
Sent: Wednesday, August 1, 2018 8:35 AM
To: [email protected]
Subject: Delta Tau motor control problem
HI all,
I have run in to another problem with my attempts to control a stepper
motor using a Delta Tau controller.
Current configuration:
Motor Controller: Delta Tau Power Brick LV-IMS
EPICS version: 3.14.12.2
Asyn module: 4.32
powerPMAC driver: The 2014-09-25 version at
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.observatorysciences.co.uk_deltatau-5Fdownloads.php&d=DwIFAw&c=nE__W8dFE-shTxStwXtp0A&r=D7ZiziuMQuq40HlGYOZPBg&m=ZmTWsXZYmGLg862DZ2uV4SmvTip0gGU96U6NZ9gA7Sw&s=3qbPWlFX7bXGiYJerbx4FXUSOFfTGUf4Ic1THVCTgdE&e=
IOC config:
#===== for Power Brick LV-IMS controllers =====
drvAsynPowerPMACPortConfigure("SSH1", "192.168.137.234", "root",
"deltatau", "0", "0", "0")
# 'Ctlr port name', 'SSH port name'. 'port address'. '#axes'
'Moving poll interval (ms)', 'Idle poll interval (ms)'
powerPmacCreateController("PBRICK1", "SSH1", "0", "32", "25", "100")
# open-loop axes (they don't use the encoder readback)
pmacCreateAxis("PBRICK1", "3")
asynSetTraceMask("PBRICK1", 0, 0)
asynSetTraceMask("SSH1", -1, 0)
asynSetTraceIOMask("SSH1", -1, 0)
# includes a motor record...
dbLoadTemplate("db/powerPMAC.substitutions")
Using this configuration, I can control the motor via the motor record
just fine, as long as I wait until the motor reaches the new position
after each new setpoint.
However, if I change the setpoint while the motor is still moving, it
will stop before getting to either the new or the previous setpoint, the
done moving bit in the status value from the controller stays at 0, and
new setpoints to the motor record are ignored.
If I then give the controller a move command directly, this works fine:
The motor moves to the new position and the done moving bit goes back to
1, at which point new setpoints applied to the motor record will work again.
NOTE: Changing the setpoint in a middle of the move using commands on
the controller itself also works fine (e.g. it will happily reverse
direction in the middle of a move to get to the latest setpoint).
Given how long the motor record has been around, I assume that such a
basic problem would have been resolved long ago. And the controller is
fine with changes to the setpoint during a move, so I would think that
the problem must be in the driver.
Has anyone run in to this sort of thing before? Someone mentioned that
the driver available from the Diamond Light Source incorporates the
driver I am using (i.e. it should work for Geo Brick and Power Brick
controllers?). Does anyone now if this is a driver bug and whether or
not it is fixed in the DLS version?
Thanks.
--
Mark Davis
NSCL/FRIB
Control Systems Software Engineer
[email protected]
- Replies:
- Re: Delta Tau motor control problem J. Lewis Muir
- References:
- Delta Tau motor control problem Mark Davis
- Re: Delta Tau motor control problem Mark Rivers
- Navigate by Date:
- Prev:
Re: Delta Tau motor control problem [email protected]
- Next:
Re: Delta Tau motor control problem J. Lewis Muir
- 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:
Fw: Delta Tau motor control problem [email protected]
- Next:
Re: Delta Tau motor control problem J. Lewis Muir
- 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, 03 Aug 2018 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|