Motor Record: Known problems with Release 4-7
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.
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.
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.
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.
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.
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.
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.
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.