Inconsistency of Backlash Definition
It seems that the use of **backlash ** in BLISS is not well defined. It is based on an unclear (or even wrong?) definition given in the bliss.gitlab-pages (https://bliss.gitlab-pages.esrf.fr/bliss/master/bliss_motion_control_basics.html#backlash [bliss.gitlab-pages.esrf.fr]):
*backlash¶
*
*Backlash attribute defines a small movement performed at the end of a
*movement if this movement’s direction is opposed to the sign of the
*backlash.
*
*The backlash is defined in the config in _user units_.
Saying "user units" suggests
(user_)backlash = sign*dial = sign*controller_steps/steps_per_unit
instead of
(dial_)backlash = controller_steps/steps_per_unit
as it can be expected in analogy to SPEC. In BLISS, changing the parameter sign changes unexpectedly also the backlash direction!
The basic idea of this definition was probably giving the backlash in units (mm, deg, etc.) instead of controller_steps like in SPEC. Taking this in mind, I propose the following definition:
*The backlash is defined in the config in dial units (backlash = controller_steps/steps_per_unit)
Including the parameter sign in a backlash definition is bad, because it does not allow, setting up the motor parameters, including backlash, independently of the final mounting direction (which is usually taken into account by sign at the very end). With the current definition, it is not possible changing the sign alone without side effects on the limit search behavior and the positioning accuracy of the motor, because:
**In BLISS the sign of the backlash parameter must be adapted according to the sign parameter.**
There is no device (motor specific) backlash direction any more (it depends on sign and the sign of backlash). In this way the necessary backlash movement can easily be lost after some configuration changes by forgetting adapting the sign of backlash as well.
The problem became obvious after translating a SPEC configuration to BLISS. For calibrating a motor position the limit search in SPEC finished successfully, while the limit search in BLISS failed due to a backlash movement in the wrong direction.
For many movements the backlash direction is very important and I think that such a big difference to SPEC should be communicated on a more prominent place. Is it going to be revised/corrected in a future BLISS version, e.g. by defining the backlash in "dial units" and not in "user units"?
For avoiding rewriting a lot of existing BLISS configurations alternative parameters could be used, e.g. "DIALBACKLASH", "USERBACKLASH". Using the currently defined BACKLASH parameter should be deprecated.