Hello all,
Recently, we've had a sscan record fail to execute complaining about the positioner limits (i.e.,P0_ Value < LO_LIMIT @ point0). After some debugging, we have realized that the problem was on how LO_LIMIT and HI_LIMITs were determined for motors.
Particularly, from what I understand (and I could very well be wrong), if DHLM == DLLM == 0, the software limits are disabled (in the motor record) and the motor can move as long as it is within the hardware limits. The problem arises if we use the user fields as our positioner (VAL and RBV), because HLM = DHLM + OFF (or DLLM + OFF if DIR=-1) and LLM = DLLM + OFF (or DHLM + OFF for DIR=-1). But since the sscan record uses the upper_dist_limit/lower_dist_limit, which are obtained here, these limits are not read as 0 and the check fails (this check in particular).
We have worked around the issue by setting DHLM (and DLLM) to a very large range (-9999 and 9999), so that this is never triggered. But I wonder if there is a way we could improve upon it. The first question is if we could forego the check altogether, so that the positioner PV itself would limit the range. Alternatively, the check could be changed to be if (pPos>p_lr != pPos>p_hr), although in this case, it is possible someone has set the limits to the same location to block the motor into a fixed position (nevertheless, the positioner PV would still block itself from being set outside the desired limits). Finally, the message could remain the same, but the error be changed into a warning, so the scan would still run, but the user could be alerted of the "misconfiguration" (?).
My main concern is that if this check was to be changed, the current functionality would also be changed, so an upgrade could cause major issues (for IOCs relying on the current behavior). But I wanted to open up the discussion in case others also encountered the same issue.
Hello all, Recently, we've had a sscan record fail to execute complaining about the positioner limits (i.e.,
P0_ Value < LO_LIMIT @ point0). After some debugging, we have realized that the problem was on how LO_LIMIT and HI_LIMITs were determined for motors.Particularly, from what I understand (and I could very well be wrong), if
DHLM == DLLM == 0, the software limits are disabled (in the motor record) and the motor can move as long as it is within the hardware limits. The problem arises if we use the user fields as our positioner (VAL and RBV), becauseHLM = DHLM + OFF(orDLLM + OFFifDIR=-1) andLLM = DLLM + OFF(orDHLM + OFFforDIR=-1). But since the sscan record uses the upper_dist_limit/lower_dist_limit, which are obtained here, these limits are not read as 0 and the check fails (this check in particular).We have worked around the issue by setting DHLM (and DLLM) to a very large range (-9999 and 9999), so that this is never triggered. But I wonder if there is a way we could improve upon it. The first question is if we could forego the check altogether, so that the positioner PV itself would limit the range. Alternatively, the check could be changed to be
if (pPos>p_lr != pPos>p_hr), although in this case, it is possible someone has set the limits to the same location to block the motor into a fixed position (nevertheless, the positioner PV would still block itself from being set outside the desired limits). Finally, the message could remain the same, but the error be changed into a warning, so the scan would still run, but the user could be alerted of the "misconfiguration" (?).My main concern is that if this check was to be changed, the current functionality would also be changed, so an upgrade could cause major issues (for IOCs relying on the current behavior). But I wanted to open up the discussion in case others also encountered the same issue.