RE: [EXTERNAL] Re: [Ext] Help with motorNewport config

["Pearson, Matthew via Tech-talk" <tech-talk at aps.anl.gov>]

Hi,

 

I had a look at the original XPS code, and it seems to be broken because movesDeferred_ is never set back to false again. So after doing one deferred moves, subsequent normal moves are skipped because we think we’re still in deferred moves mode.

 

I can only assume this wasn’t caught because for applications that want to use deferred moves they keep on using it and don’t try normal moves again, plus the fact that deferred moves are not generally well known or widely used.

 

So one fix would be to add a movesDeferred_=false at the end of the XPSController::setDeferredMoves.

 

It seems like Lauenz’s code below has the same fix built into it.

 

It may be that the original logic of:

 

if (deferMoves || !movesDeferred_) {

    movesDeferred_ = true;

    return asynSuccess;

  }

 

was to support the use-case like this:

 

caput {P}:Defer.PROC 1

caput {P}:Motor1 1.0

caput {P}:Motor2 2.0

caput {P}:Motor3 3.0

caput {P}:Defer.PROC 1

 

where {P}:Defer.VAL stays at 0.

 

Mark’s patch would change that so we require the use of setting 0 and 1 rather than just processing the record.

 

I think setting 0 and 1 is better, just because of the principle of least surprise. So that patch, in combination with setting movesDeferred_ back to false, would be a reasonable way forward (although it would break any existing applications that do use the PROC method above).

 

Cheers,

Matt

 

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Laurenz Rettig via Tech-talk
Sent: Thursday, April 10, 2025 3:54 AM
To: tech-talk at aps.anl.gov
Subject: [EXTERNAL] Re: [Ext] Help with motorNewport config

 

Hi Mark, hi Edmund, I built a model 3 driver for a different controller based on motorNewport, where I also implemented deferred moves. I also experienced that the logic for enabling/disabling this in motorNewport seemed broken: https: //github. com/epics-motor/motorNewport/blob/16a818fe7e49746ffd1973c47354631cb0793e81/newportApp/src/XPSController. cpp#L441

Hi Mark, hi Edmund,

I built a model 3 driver for a different controller based on motorNewport, where I also implemented deferred moves. I also experienced that the logic for enabling/disabling this in motorNewport seemed broken: https://github.com/epics-motor/motorNewport/blob/16a818fe7e49746ffd1973c47354631cb0793e81/newportApp/src/XPSController.cpp#L441

I came up with the following code, that works for my driver as expected:

  // If we are not ending deferred moves then return
  if (deferMoves && !movesDeferred_) {
    movesDeferred_ = true;
    asynPrint(this->pasynUserSelf, ASYN_TRACE_FLOW,
        "%s:%s: Turning deferredMoves on.\n",
        driverName, functionName);
    return asynSuccess;
  }
  else if (!deferMoves && movesDeferred_) {
    /* Call deferred moves */
    status = this->processDeferredMoves();
    asynPrint(this->pasynUserSelf, ASYN_TRACE_FLOW,
       "%s:%s: Processing deferredMoves.\n",
       driverName, functionName);
    movesDeferred_ = false;
  }

This is very similar to Mark's suggestions.

Best, Laurenz

On 10.04.2025 09:44, Blomley, Edmund (IBPT) via Tech-talk wrote:

Hey Mark,

 

I think that logic is incorrect.  If deferMoves is true then it does correctly just set the flag and return.  However, deferMoves is false and movesDeferred_ is false (not currently in a deferred move state) then it sets moveDeferred_ = true and returns.  That is incorrect, it should simply return, it should not set movesDeferred_=true.

 

If the client is “well-behaved” it will only call this function with deferMoves=true when movesDeferred=false, and it will only call it with deferMoves=false and movesDeferred=true.  That could explain why this problem has not been previously noticed.  It appears that for some reason what you are doing is causing this function to be called a second time with deferMoves=false, when movesDeferred_ is already false.

 

I think the solution is to change this code to:

 

  if (deferMoves) {

    movesDeferred_ = true;

    return asynSuccess;

  }

  if (!movesDeferred_) {

    return asynSuccess;

  }

 

Sorry for the late response. I tried your patch, but it didn’t really seem to change much. Also I am not sure how our client could not be „well-behaved“, as we currently use the record itself and normal caput commands with epics base 7.0.6.

 

This is the record we use:

 

record(bo, "$(P)DeferMovement") {

    field(DESC, "Defer Moves")

    field(DTYP, "asynInt32")

    field(OUT, "@asyn($(PORT),$(ADDR),$(TIMEOUT=1))MOTOR_DEFER_MOVES")

    field(SCAN, "Passive")

    field(ZNAM, "Go")

    field(ONAM, "Defer")

    field(VAL, "0")

}

 

Are there some debug options I can switch on for the IOC to help me tracking down what is actually send from this particular record only?

 

Cheers

Eddy

-- 

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