EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024  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  <20182019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Fw: Delta Tau motor control problem
From: "[email protected]" <[email protected]>
To: Tech Talk <[email protected]>
Date: Fri, 3 Aug 2018 15:31:26 +0000
I'm forwarding Alan Greer's response to techtalk again since some people did not see it and I can't see it in the techtalk index.


________________________________
From: Knap, Giles (DLSLtd,RAL,LSCI)
Sent: 03 August 2018 13:50
To: Torsten Bögershausen
Subject: Fw: Delta Tau motor control problem


Torsten,


Here is Alans email in case you caouldn't find it. I hope it answers some of your questions.


________________________________
From: Alan Greer <[email protected]>
Sent: 03 August 2018 11:11
To: Knap, Giles (DLSLtd,RAL,LSCI)
Cc: Mark Rivers; [email protected]; [email protected]
Subject: Re: Delta Tau motor control problem

Hi Mark,

I have been carrying out some testing with my PowerPMAC and also discussing it with Giles at Diamond Light Source and I'm now confident we have found the cause of your problem.  I will (attempt to) explain:

1) With a PowerPMAC there is a setting for a motor called Motor[x].InPosBand.
2) The default setting of the variable in (1) is 0.
3) If you perform a move (#1j=1000.0) and then during the move tell the motor to stop (#1j/) and the value of (1) is 0 then the motor will never report that it is in position.
4) With the EPICS driver, if you demand a move and then change the demand during the move the driver will issue a stop (#1j/) and then wait for the in position flag to be true before sending the new demand.

And so I hope your problem is easily resolved by setting the value of Motor[x].InPosBand to some small non zero value.


I would like to take this opportunity to mention that the new driver available from Diamond Light Source is recommended by Observatory Sciences.  The new driver retains all of this original drivers functionality and improves on it, the driver works with PowerPMACs and Geobricks.  It is actively supported by Giles at Diamond and the original Observatory Sciences author was also part of the development team at Diamond for the new driver.

The link to the new driver is

https://github.com/dls-controls/pmac


I will update the OSL website to provide some clear messages that the new driver should be used (we will leave links to the current available versions for a period of time).

Cheers, Alan


On 3 August 2018 at 10:46, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> wrote:
Mark ,


f you want to see commands sent to controller set these PVs:

$(P):DEBUG_LEVEL = 16

$(P):DEBUG_EXECUTE = 1

(if you are using our edm screens then there is GUI for this)


This outputs all commands sent to the brick but all polling is muted.


If you want to send demands without going through the motor record then use PV

$(P):M1:DirectDemand

for motor 1.


I'm afraid I added these direct demands for similar reasons to the issue you are having. (I would like to be able to switch motor record into 'dumb' mode where it always sends all user actions to the controller. My issue was that we use 'deferred' moves where a script starts several motors simultaneously. In some circumstances on a six circle diffractometer with jittery motors, NTM logic would suppress one of the demands and this would be catastrophic.)


When I tried this on PPMAC I was using motor 6-9, all NTM related fields at default. I have also just tried it with motor 6-10-1


Regards,

giles.


________________________________
From: Mark Rivers <[email protected]<mailto:[email protected]>>
Sent: 02 August 2018 20:58:59
To: Knap, Giles (DLSLtd,RAL,LSCI); [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
Subject: Re: Delta Tau motor control problem


Have you enabled asynTrace in the underlying asyn TCP driver to see what commands are actually being sent to the controller?  There are probably asynTrace calls in the motor driver as well.

Mark


________________________________
From: Mark Davis <[email protected]<mailto:[email protected]>>
Sent: Thursday, August 2, 2018 10:18 AM
To: [email protected]<mailto:[email protected]>; Mark Rivers; [email protected]<mailto:[email protected]>
Subject: Re: Delta Tau motor control problem

Hi Giles,

It took a while to get through the differences between the version I was
using and this latest one, but I eventually got it running using the
version you released yesterday.  Unfortunately, it hasn't made any
difference.

Is there an easy way to test this functionality without going through
the motor record so I can at least determine if the problem is in the
driver or the motor record?

Does anybody know if there anything in the motor record that could cause
this if the fields in the motor record that describe various aspects of
the motor (e.g. velocity, acceleration, etc) are not properly configured?

Mark


Mark Davis NSCL/FRIB Control Systems Software Engineer [email protected]<mailto:[email protected]>
On 8/1/2018 12:04 PM, [email protected]<mailto:[email protected]> wrote:
> Hi Mark,
>
>
> See latest pmac at https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dls-2Dcontrols_pmac_releases_tag_2-2D1&d=DwIFAw&c=nE__W8dFE-shTxStwXtp0A&r=D7ZiziuMQuq40HlGYOZPBg&m=hXNy61CAHm2fE0dEnE_T6w8Mom1Re8RSl3DCYELh4zE&s=nQGySqmgeIasdlsqnzhNQCIgICRA-EbDPaFv3g9Gkvs&e=
>
>
> I agree with Mark R that this is related to an interaction between driver and NTM but I don't think a well behaved driver should ever exhibit what you describe.
>
> ________________________________
> From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of Mark Rivers <[email protected]<mailto:[email protected]>>
> Sent: 01 August 2018 15:21:19
> To: [email protected]<mailto:[email protected]>; Mark Davis
> Subject: Re: Delta Tau motor control problem
>
> 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]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of Mark Davis <[email protected]<mailto:[email protected]>>
> Sent: Wednesday, August 1, 2018 8:35 AM
> To: [email protected]<mailto:[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=hXNy61CAHm2fE0dEnE_T6w8Mom1Re8RSl3DCYELh4zE&s=-YPCsQc3KmJAS2-hRXAfTk3oJfzx4jZLMLQTKgz_GEw&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]<mailto:[email protected]>
>
>


--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom



References:
Delta Tau motor control problem Mark Davis
Re: Delta Tau motor control problem Mark Rivers
Re: Delta Tau motor control problem [email protected]
Re: Delta Tau motor control problem Mark Davis
Re: Delta Tau motor control problem Mark Rivers
Re: Delta Tau motor control problem [email protected]

Navigate by Date:
Prev: Re: Delta Tau motor control problem J. Lewis Muir
Next: Re: Delta Tau motor control problem Kevin Peterson
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  <20182019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Delta Tau motor control problem Mark Davis
Next: Re: Delta Tau motor control problem Mark Davis
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  <20182019  2020  2021  2022  2023  2024 
ANJ, 03 Aug 2018 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·