In TurboPMAC, the limits are monitored by examining the ix24 variables. However, in PowerPMAC, ix24 represents the address of the servo-loop being used. PowerPMAC also includes protection against writing to invalid addresses.
The element Motor[%d].pLimits should be used instead.
This difference makes operations like i%d24=i%d24&$FDFFFF and i%d24=i%d24|$20000 invalid in PowerPMAC. Moreover, these operations do not disable or enable the limits as one might expect.
The correct operation should be something like Motor[%d].pLimits=0 for disabing, and Motor[%d].pLimits=Gate3[%d].Chan[%d].Status.a for enabling (preferably that address should be stored when disabling the limits).
When checking ix24, the response formats differ between TurboPMAC and PowerPMAC:
TurboPMAC uses the $%x format.
PowerPMAC uses the %d format.
Ultimately, these differences might lead to undesired behavior in two scenarios:
When homing into the limits, which is necessary to disable the limit faults.
When performing a safety check present in pmacAxis::getAxisStatus, which flags if the limits are disabled without the driver’s knowledge.
In TurboPMAC, the limits are monitored by examining the ix24 variables. However, in PowerPMAC, ix24 represents the address of the servo-loop being used. PowerPMAC also includes protection against writing to invalid addresses. The element
Motor[%d].pLimitsshould be used instead.This difference makes operations like
i%d24=i%d24&$FDFFFFandi%d24=i%d24|$20000invalid in PowerPMAC. Moreover, these operations do not disable or enable the limits as one might expect. The correct operation should be something likeMotor[%d].pLimits=0for disabing, andMotor[%d].pLimits=Gate3[%d].Chan[%d].Status.afor enabling (preferably that address should be stored when disabling the limits).When checking ix24, the response formats differ between TurboPMAC and PowerPMAC:
$%xformat.%dformat.Ultimately, these differences might lead to undesired behavior in two scenarios: