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
