Re: [Ext] Help with motorNewport config

[Laurenz Rettig via Tech-talk <tech-talk at aps.anl.gov>]

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