Experimental Physics and
Industrial Control System

Hi Laurenz,

thank you for your feedback. It makes sense to have this state change for triggering callbacks etc. However, I am wondering if it would not be sufficient to trigger these once the DeferredMoves are actually started by lowering the flag again. This could still happen for all axes independent of whether they actually move.

It’s been a while since I looked in detail at the DMOV logic. The motor record likely sets DMOV=0 internally at the beginning of a move, and if the driver doesn’t confirm that a move has started you may see a quick 1->0->1 transition, and then another one once the real move has started.

In my particular case, I have interlocks in place that prevent the user from entering new setpoints while a motion is in progress. This, however, for a multimotor deferred move is triggered after the first motor position is set, and then any further setpoints cannot be set. Thus, I want to set the DMOV flag only once a move actually starts.

Setting a motor setpoint with deferred moves active would only cause that particular motor to go into DMOV=0 state, so you should still be able to set the other motors that will be part of the deferred move? Or, your interlock prevents setting any motor is any motor is moving? Perhaps the interlock could be modified to also take into account the deferred move flag status, and still allow a new setpoint if deferred moves is active?

I suppose I could do this when processing deferred moves, and could write a writeFloat64 function in my class that ommits these lines for move commands if deferredMoves is set, no?

Overwriting writeFloat64 is an option, but it would complicate the driver and then you still might find issues with callbacks etc.

Cheers,

Matt

Best, Laurenz

Hi Torsten,

 

The deferred moves logic is really associated with a controller concept rather than an axis, so it can’t be entirely handled by the motor record. For example, a lot of controllers provide the ability to synchronize a multi-axis move start (and sometimes even a start and stop time), and that needs a command sequence something like:

 

Axis 1: set new position

Axis 2: set new position

Axis 3: set new position

Axes 1,2,3: start moving (in one command)   <- a single motor record can’t do this

 

It’s possible some of the logic could be handled in the controller and axis base class poll functions. Although most (or all) drivers override those and don’t call the base class function since they currently don’t do anything.

 

Cheers,

Matt

 

 

From: Torsten Bögershausen <Torsten.Bogershausen at ess.eu>
Sent: Friday, March 10, 2023 12:04 PM
To: Pearson, Matthew <pearsonmr at ornl.gov>; Laurenz Rettig <rettig at fhi-berlin.mpg.de>; tech-talk at aps.anl.gov
Subject: Re: [EXTERNAL] DeferredMoves without setting moving flag

 

Oh, I was to fast with my first response.
The line you wrote, Matt, could go into the generic code, right ?

/Torsten

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of "Pearson, Matthew via Tech-talk" <tech-talk at aps.anl.gov>
Reply-To: "Pearson, Matthew" <pearsonmr at ornl.gov>
Date: Friday, 10 March 2023 at 17:50
To: Laurenz Rettig <rettig at fhi-berlin.mpg.de>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Subject: RE: [EXTERNAL] DeferredMoves without setting moving flag

 

 

Hi,

 

Certainly that behavior can be confusing. We enable deferred moves, set the position, and a motor appears to be moving before we say ‘Go’. However, I think it is necessary so that the motor record doesn’t think the move is completed before we have started moving. If you are relying on a callback or forward links or looking for a DMOV 0->1 transition, you’ll be depending on this behavior.

 

Also that line in asynMotorController.cpp applies to all kinds of moves and not just deferred moves. This is necessary for the same reasons, to prevent the motor record thinking that the move is complete before it’s even started and the polling function has chance to return the correct moving status. It’s likely almost every Asyn motor driver depends on that line in the base class writeFloat64 function.

 

In the poll() function in your derived class, it’s usually handled by looking at the deferred move flag for an axis. If deferred moves is enabled, then the poller reports motorStatusDone=0, something like:

 

if (deferred_move) {

  moving = true;

} else {

  //calculate moving flag as normal

}

 

Cheers,

Matt

 

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Laurenz Rettig via Tech-talk
Sent: Friday, March 10, 2023 11:17 AM
To: tech-talk at aps.anl.gov
Subject: [EXTERNAL] DeferredMoves without setting moving flag

 

Hi,

I've been working on an asyn motor controller with DeferredMoves. This in principle works, however I noticed that when DeferedMoves is enabled, and I change the setpoint of an axis, the moving flag is raised for a short time (i.e. DMOV=0), even though the axis is not moving yet. I would like to get rid of this behavior.

As far as I understand it, this is probably induced by the calls to "pAxis->setIntegerParam(motorStatusDone_, 0);" here:

https://github.com/epics-modules/motor/blob/34474ed958838ea5083f598fa4bd9f1ca7e1821c/motorApp/MotorSrc/asynMotorController.cpp#L317

and the flag is reset by the next call of the axis poll() function.

Is there a simple way to avoid this, or do I have to rewrite the whole writeFloat64 function in my controller driver, and remove these lines?

Thanks,

Laurenz

-- 

Dr. Laurenz Rettig                  rettig at fhi-berlin.mpg.de

Emmy Noether Research Group Dynamics of Correlated Materials

Fritz Haber Institute of the Max Planck Society

Department of Physical Chemistry

Faradayweg 4-6                         Tel: +49 30 8413 5225

14195 Berlin, Germany                  Fax: +49 30 8413-5387

-- 

Dr. Laurenz Rettig

Fritz Haber Institute of the Max Planck Society

Department of Physical Chemistry

Dynamics of Correlated Materials

Faradayweg 4-6

14195 Berlin, Germany

phone: +49-(0)30-8413 5225

email: rettig at fhi-berlin.mpg.de