Motor Record: Known problems with Release 4-7

  1. With release R4-5, DBE_LOG was omitted from the event select mask of all db_post_events() calls.  This prevented archival clients from being notified of process variable changes.
  2. Communication with the Newport MM3000 motor controller was getting out of synchronization whenever the MM3000 responded with an error message. This problem was resolved by having recv_mess() in drvMM3000.c detect an error message response, print the error message and then, recursively, call itself. This restored communication transmit/receive synchronization.
  3. With release R4-7, there was a slight (undocumented) modification made to the way that backlash correction functioned. If a move is in the preferred direction and the backlash speed and acceleration are the same as the slew speed and acceleration, then the backlash move is skipped and the motor moves directly to the target position. Unfortunately, there was a bug in the logic that appeared only when MRES< 0. When MRES < 0, and the backlash speed and acceleration were the same as the slew speed and acceleration, the motor record did the opposite of the requirements; i.e., it did backlash correction when the move was in the preferred direction and did not do backlash correction when the move was not in the preferred direction.
  4. The Newport ESP300 would randomly crash at boot-up because an internal parameter ("drive_resolution") was not always, under all configurations, initialized. With this release, the "drive_resolution" is set based on the response to the ESP300 "SU?" command. In addition, the user is required to set MRES to the resolution of the controller as explained in the new document /motorApp/NewportSrc/README.
  5. A bug was introduced in R4-6 while fixing another bug; see item#2 under Modification Log from R4-5 to R4-6 in the distribution README file. This error exhibited itself only under the following conditions; BDST != 0, DLY != 0 and a new target position is issued before the backlash correction move. Under these conditions the motor record became unresponsive; i.e., it locked up.
  6. Although there is no explicit statement in the motor record documentation, most user's would expect the "Readback settle time" field (DLY) to update the readback after the delay timeout. It did not do this. With this release, the readback is updated one time after the timeout.
  7. There were problems with the tweak function (TWF/TWR) when the TWV was set to less than MRES. Under this condition, the following scenario would result. First, tweak forward (TWF). Since DIFF < MRES, the motor is not moved. Next, tweak reverse (TWR). Next TWF again. The motor record does not respond; i.e., DVAL and RVAL are not updated; VAL is not posted. A single tweak, back and forth, confirms that the motor record is not responding.
  8. The motor record would lock-up when a user tried to move off an activated limit switch with the OMS VME58 servo motor controller board (i.e., model -8S). See "Known Problems" item #4 in the motor record's distribution README file.