Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Mon, 16 Nov 2015 14:21:56 +0000

I think this is a problem with the logic of motor record, not with the driver.  I think it is a bad idea to not filter the callbacks.  We don't want the motor record to process every time the driver does a poll, which could be at 60 Hz or higher.  It should only process due to callbacks from the driver when there is a change in status.

If a driver wants to force a callback there is a method that does not require any changes to the base classes, e.g. exposing statusChanged_ as protected or adding a new isMotorRecordnowFilterButAlwaysProcess_ flag.  The driver simply needs to set a parameter to a different value from present and then back to its current value, for example
  setDoubleParam(pC_->motorPosition_(position+1.);
  setDoubleParam(pC_->motorPosition_(position);
  callParamCallbacks();

Mark
________________________________________
From: [email protected] [[email protected]] on behalf of Torsten Bögershausen [[email protected]]
Sent: Monday, November 16, 2015 2:54 AM
To: Pearson, Matthew R.; [email protected] list
Subject: Re: motor record DLY and STOP problem

On 11/11/15 16:18, Pearson, Matthew R. wrote:
>
> Hi,
>
> There seems to be a problem with issuing a motor record STOP while we are waiting for a DLY settling time to expire. I can lock up the motor record if I issue a STOP after MOVN has gone to zero and before DMOV goes to 1. This only seems to be a problem if there are no further updates from the driver (so we have already stopped moving). It’s easy to reproduce using a simulation driver.

Now I can reproduce it.
Are you using a model 3 driver ?

If yes, then one reason is, that the poll() updates are "filtered" here, and
the motorRecord is not processed,
when the encoder/motor is not moving at all in the DLY phase:

asynStatus asynMotorAxis::callParamCallbacks()
{
   if (statusChanged_) {
     statusChanged_ = 0;
     pC_->doCallbacksGenericPointer((void *)&status_, pC_->motorStatus_, axisNo_);
   }
   return pC_->callParamCallbacks(axisNo_);
}
----------------------
A "first aid help" quickfix can look like this:
Expose the statusChanged_ (move it out from private to protected in
asynMotorAxis.h)

diff --git a/motorApp/MotorSrc/asynMotorAxis.h b/motorApp/MotorSrc/asynMotorAxis.h
index 4b22e85..1342b20 100644
--- a/motorApp/MotorSrc/asynMotorAxis.h
+++ b/motorApp/MotorSrc/asynMotorAxis.h
@@ -63,10 +63,10 @@ class epicsShareFunc asynMotorAxis {
    double *profileReadbacks_;         /**< Array of readback positions for
profile moves */
    double *profileFollowingErrors_;   /**< Array of following errors for
profile moves */
    int referencingMode_;
+  int statusChanged_;

    private:
    MotorStatus status_;
-  int statusChanged_;
    int referencingModeMove_;

    friend class asynMotorController;


-----------------
The change the driver to set statusChanged_ = 1 in the poll() function:
+  statusChanged_ = 1;


----------------------
This will make the motorRecord to be processed and get out of the DLY phase.

A better handling may be to have a flag that does not filter the callbacks,
whenever the motor record is used with a model 3 driver.

asynStatus asynMotorAxis::callParamCallbacks()
{
   if (statusChanged_ || isMotorRecordnowFilterButAlwaysProcess_) {
     statusChanged_ = 0;
     pC_->doCallbacksGenericPointer((void *)&status_, pC_->motorStatus_, axisNo_);
   }
   return pC_->callParamCallbacks(axisNo_);
}

Any thoughts ?



Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System