Motor Record: Known problems with Release 4-9

1. PID parameters (i.e., PCOF, ICOF and DCOF fields) were not initialized at boot-up. With R4.9.1, if the GAIN_SUPPORT bit in the MSTA is true, each nonzero, PID parameter will be initialized. For backwards compatibility, zero valued PID parameters will not be initialized.
2. Previous releases of the IMS MDrive device driver did not work. Thanks to Kevin M. Peterson (UNI-CAT) for identifying and fixing the errors in previous releases.
• Fixed with R4-9-2.
3. Two bugs were found and fixed with the Newport MM3000 device support. First, the enable/disable torque control field (CNEN) was not working. Second, an error was introduced into the Newport MM3000 device driver with R4-8; the driver was confusing valid responses with the "system error" response from the controller
• Fixed with R4-9-3.
4. A retry on initial communication with the Physik Instrumente (PI) C-844 motor controller was added. The controller was intermittently not responding after an IOC power-cycle.
• Fixed with R4-9-4.
5. Modifications were made to the motor record in order to allow a user to configure it for periodic status updates using the SCAN field.
• Available with R4-9-4.
6. The motor record would get into an invalid state when it attempted to perform a backlash correction move in the direction of an activated limit switch.
• Fixed with R4-9-5.
7. Bug fix for home request re-activating after a limit switch error is cleared. This release clears the homing and jog request after a LS or travel limit error. Updated the motorx_all.adl MEDM screen (V2.5) to show the state of the jog request.
• Fixed with R4-9-5.
8. A bug was reported by David Maden (PSI) that occurred when a motor was jogged into a limit switch with the DIR field set to "Neg". Under these conditions, the motor record was not processing the limit error condition correctly. This resulted in the motor record not setting either of the limit error indicator fields (HLS/LLS) and becoming stuck in the "Moving" state.
• Fixed with R4-9-6.
9. Kevin Peterson (UNI-CAT) and I diagnosed a bug that is in all R3.13 versions of the motor record distribution. The bug is in the interface between motor record GPIB capable drivers (i.e., Newport MM4000/5/6, MM3000, PM500, ESP300/100) and the EPICS base GPIB driver; drvGpib.
   Dynamic memory is allocated and shared with drvGpib by the motor task. The problem arises here, at the end of ibLinkTask in drvGpib.c;
   plink->deviceStatus[pnode->device] = (*(pnode->workStart))(pnode);
   pnode->workStart is a pointer to gpibIOCallback() in gpibIO.c. When gpibIOCallback() is done processing it "gives" a semaphore that is "taken" by either gpibIOSend() and gpibIORecv(). Both gpibIOSend() and gpibIORecv() immediately free the shared memory.
   This works almost all the time; but occasionally the memory is taken by some other task and trashed before the line above is executed resulting in a bus error on "pnode->device".
   As a quick fix, the task priorities of the all GPIB capable controllers has been lowered below ibLinkTasks priority. This allows ibLinkTask to finish processing and be waiting for the next GPIB request before the shared memory is de-allocated.
   All users of the R3.13.x version of the motor record distribution that use GPIB to communicate to Newport controllers (i.e., Newport MM4000/5/6, MM3000, PM500, ESP300/100), should upgrade to the R4-9-6 release.
• Fixed with R4-9-6.