Re: Delta Tau motor control problem

[Mark Davis <davism50@msu.edu>]

Thanks Alan,

As you may have already seen from the message I just copied to tech-talk (I had accidentally responded just to Lewis yesterday), I was beginning to think it might be something like this.

I will give it a try as soon as I can (hopefully later this morning or this afternoon).

Mark

Mark Davis NSCL/FRIB Control Systems Software Engineer davism50@msu.edu

On 8/3/2018 6:11 AM, Alan Greer wrote:

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, giles.knap@diamond.ac.uk <giles.knap@diamond.ac.uk> 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 <rivers@cars.uchicago.edu>
Sent: 02 August 2018 20:58:59
To: Knap, Giles (DLSLtd,RAL,LSCI); tech-talk@aps.anl.gov; mark_a_davis@comcast.net

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 <davism50@msu.edu>
Sent: Thursday, August 2, 2018 10:18 AM
To: giles.knap@diamond.ac.uk; Mark Rivers; tech-talk@aps.anl.gov
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 davism50@msu.edu
On 8/1/2018 12:04 PM, giles.knap@diamond.ac.uk 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: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov> on behalf of Mark Rivers <rivers@cars.uchicago.edu>
> Sent: 01 August 2018 15:21:19
> To: tech-talk@aps.anl.gov; 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: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov> on behalf of Mark Davis <davism50@msu.edu>
> Sent: Wednesday, August 1, 2018 8:35 AM
> To: tech-talk@aps.anl.gov
> 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
> davism50@msu.edu
>
>

--
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