forked from epics_driver_modules/motorBase
Torsten Bögershausen
2906f3d8f9
Partly revert the following commit: commit3090983c31Author: Ron Sluiter <rsluiter@users.noreply.github.com> Date: Wed Jul 29 15:50:23 2015 +0000 Bug fix for target position (VAL/DVAL/RVAL) initialization error when the motor record is configured to do retries. And from the release notes: 6) Kevin Peterson discovered an initialization bug when the motor record is configured to do retries. When configured to do retries, the motor record issues incremental rather than absolute moves. If the motor behaves badly (e.g., a piezo stiction motor) the controller's absolute step count can be far from its' absolute readback position. The motor record initialization logic that determines how the target positions are initialized at boot-up was not taking into consideration whether or not the motor record is configured to do retries, and therefore, whether or not absolute or incremental moves were issued by the motor record. With this release, if the motor record is configured to do retries, then the controller's absolute position is ignored (because the controller's absolute position was "corrupted" by retries) and the autosave/restore position is used to set the controllers position. Switching between retries on and off (relative vs. absolute moves) between reboots will cause unpredictable results and is not covered by this bug fix. Files modified: motor_init_record_com() in MotorSrc/motordevCom.cc init_controller() in MotorSrc/devMotorAsyn.c Commit3090983cimproves the situation for setups where autosave is used, and makes things worse when autosave is not used. When autosave is not used and the motor is configured to do retries, the the DVAL field is loaded into the controller regardless. And because DVAL is 0.0 at startup, the controller position is lost. The first issue report is found here: "Problem with R6-10 issue 6 fix - controller position can be lost on reboot" https://github.com/epics-modules/motor/issues/85 And the we have another issue report here: "IOC zeroes encoder on startup" https://github.com/motorapp/Galil-3-0/issues/13 A possible way forward is discussed here: "Add a field to the motor record to allow always restoring the autosaved position" https://github.com/epics-modules/motor/issues/151 This commit adds the "RSTM" field: - 0 Disables restoring the autosaved position - 1 Always restores the autosaved position - 2 Uses the same logic as motorRecord 6.9 (or older) - 3 Uses the same logic as motorRecord 6.10 This numbering maps 0 and 1 somewhat to false/true, uses 2/3 for special handlings and leaves room for more choices. E.g. "use the encoder value, if valid, fall back to autosave if not. Or "use the URIP/RDBL" if possible. I am getting off-topic, those improvements should be done in later commits anyway.
HTML documentation
- index.html (formerly motor.html)
- motorDeviceDriver.html
- motorRecord.html
- motor_files.html
- motor_release.html
- trajectoryScan.html