Closed frankdeath closed 1 year ago
Ran into this recently where sensors were connected to channels 3-5, but not 0-2, and there was a large delay in response due to the timeouts. Was going to make a PR that allowed for specifying the "first" axis that was connected, but I think as you say being able to have more granular control it would be better.
This issue was found long time ago and codes were added to support the feature. You can find comments in "Pull requests: Add MCS2CreateAxis and Cal/Ref/MCL frequency readback". The request seems not approved.
@Huijuan-Xu, the pull request was merged earlier this afternoon:
https://github.com/epics-motor/motorSmarAct/pull/8
I'm working on a new motorSmarAct (and motor) release.
An unusedMask
argument was added to MCS2CreateController
to allow unused axes to be specified:
I don't have a smarAct controller to use for testing. It might be necessary to add a check for the unusedMask
to getAxis
:
Paul Fenter at ANL has a SmarAct system he brings to our beamline when he runs. You might be able to borrow that for testing.
It should not be necessary to check unusedMask
in getAxis
.
asynMotorController::getAxis
returns pAxes_[axisNo]
:
The asynMotorController
constructor clears the memory it allocates for pAxes_
:
The MCS2Controller
constructor only creates an MCS2Axis
object if the relevant bit of unusedMask
is zero:
https://github.com/epics-motor/motorSmarAct/blob/cdcfd093d4717cd96ff5f6183541870bf5e0c323/smarActApp/src/smarActMCS2MotorDriver.cpp#L88
The asynMotorAxis
constructor is the only thing that sets an element of pAxes_
to a non-zero value:
https://github.com/epics-modules/motor/blob/6ee5f4ebf44ddc46d989fc97b61d6dcc2c3bbc77/motorApp/MotorSrc/asynMotorAxis.cpp#L45
And the asynMotorPoller
checks for a null pointer:
https://github.com/epics-modules/motor/blob/6ee5f4ebf44ddc46d989fc97b61d6dcc2c3bbc77/motorApp/MotorSrc/asynMotorController.cpp#L651-L652
Fixed by #8
If there is an unused channel between used channels (channel 0 and 2 are connected to stages and channel 1 is not), it causes timeouts when querying the readback position of the unused channel. This can give the appearance that the driver is taking much longer to poll than the specified idle polling period.
One possible workaround for this problem is to add a way for the used/unused axes to be specified from the iocsh and then make the getAxis methods in the only return an axis pointer for used channels.