Motor Module: Known problems

Known problems with Release 6-10 and later

See issues on github: https://github.com/epics-modules/motor/issues

Known problems with Release 6-9

Known problems with Release 6-8

  1. Soft-travel Limits

  2. Newport ESP100/300/301

    The R6.8 ESP support changes made to "Use MRES rather than controller resolution to do EGUtoRAWbacktoEGU conversion." do not work. (Model 1 drivers do not always have access to motor record data.) The most obvious problem with R6.8 ESP support is the inability to "set" the controller's position.

    This patch file rolls back the R6.8 ESP changes and adds one bug fix to the EPS100/300/301 driver; when a controller error occurs, the driver prints the error code to the console and sets the RA_PROBLEM bit of the MSTA field. The motor record patch unconditionally sends a "stop motor" command whenever a driver sets the RA_PROBLEM bit. Finally, the patch file updates ESP info in the README file.

    R6-8-1 includes both the MRES related rollback and the STOP on RA_PROBLEM bug fix.

Known problems with Release 6-7

  1. Aerotech Ensemble

  2. Schneider Electric (formally IMS) MDrive

    Joe Sullivan fixed several bugs in the Schneider Electric MDrive driver associated with input buffer overflows that arose with newer MDrive firmware (e.g., 3.003). These bug fixes were 1st released with motor module R6-7-1.

Known problems with Release 6-5

  1. Aerotech Ensemble

  2. OMS MAXv WatchDog Timeout Counter

    Beginning with R6-5-1 and OMS MAXv firmware ver:1.33, the EPICS MAXv driver reads the MAXv's Watchdog Timeout Counter at bootup, and with every motor status update. If the Counter is nonzero, an error message is sent to both the errlog task and the console. Since a watchdog timer trip indicates that the MAXv has rebooted and no longer has valid motor positions, the driver disables the controller. That specific controller is no longer available to EPICS until after the VME crate has been power cycled. Other MAXv boards in the system are unaffected by this scenario.

    To better communicate this problem to the user, several medm displays have been changed. Small displays (motorx_tiny.adl, motorx.adl) will show a yellow border around their position readback values. Larger displays (motorx_more.adl, motorx_all.adl) will display the message "Controller Error" in yellow. The following error message at the console and/or in the errlog is definitive;

    ***MAXv card #(card#) Disabled*** Watchdog Timeout CTR =(count)

  3. spec upgrade required

    The RES field was removed from the motor record with R6-5. Since earlier versions of Certified Scientific Software's spec used the RES field, an upgrade to spec version 5.8.06-6 or above is required for spec to work with motor record R6-5 and above. The problem of using earlier versions of spec with motor record R6-5 exhibits itself by spec setting the "responsive" parameter to zero and not allowing any motor motion.

  4. VxWorks 6.x compiler error

    The GNU preprocessor assertions in motor.h are deprecated with the VxWorks 6.x compiler. Test for CPU macros that are compatible with VxWorks 6.x have been added. This change prevents an "Error: unknown bit order!" compiler error with VxWorks 6.x. This problem is fixed with R6-5-2 and above. Alternatively, you can replace <motor>/motorApp/MotorSrc/motor.h with the following copy: motor.h

  5. Aerotech Ensemble Home Search

    The EPICS Ensemble driver uses Aerotech's ASCII communication protocol. That protocol blocks all communication on the ASCII comm. port during a home search. Consequently, once a home search is started from EPICS, it is unable to stop it. As a result, beginning with R6-5-2, the home search command has been commented out of the EPICS driver until an Ensemble firmware update resolves this problem.

Known problems with Release 6-4

  1. R6-4 had 64-bit compile problems with the PI E816 and Aerotech Ensemble device drivers. Fixed with R6-4-1 and above.

  2. Dirk Zimoch (PSI) discovered and fixed a bug in the orginial OMS MAXv driver (R5-4) that caused the home switch status in the response string to be overwritten. Fixed with R6-4-2 and above.

  3. A problem was introduced in R6-4 of the old motor record device drive architecture. If during the move of one or more motors the motor task did not issue an OS delay during status updates, it could potentially not respond to any further motor commands. Fixed with R6-4-2 and above.

  4. There is a bug in these motor record versions (R6-4, R6-4-1, R6-4-2) that affects motors that have encoders and are configured to do closed-loop control via retries (i.e. UEIP=Yes and RTRY != 0). Retries are not done correctly and occasionally motors exceed their maximum retries and are left at their backlash position; i.e., command position - backlash distance. See the Release Notice for further error conditions. Fixed with R6-4-3 and above.

  5. The asynMotor device support in general, and the simulated motor, in particular, had save/restore related problems. Fixed with R6-4-4 and above.

  6. Previous releases of the Aerotech Ensemble device driver had incorrect Jog speeds, lacked support for a negative PosScaleFactor parameter and did not detect maximum travel limit switch faults correctly. Fixed with R6-4-4 and above.

Known problems with Release 6-3

  1. The OMS VME58 "stale data" problem is caused by the driver communicating via the ASCII commands while the DPRAM was updating. The OMS VME58 driver was modified with R6-3 to eliminate this contention and the "stale data delay" was set to zero. Since then a problem with OMS VME58 2.24-8S version firmware and all 2.35 firmware versions has arisen. When the user sets the motor record's position, the previous target and readback positions are read from the controller on the next update.

    With releases after R6-3 (e.g., R6-3-1 and R6-4) the driver searches all VME58 board ID's for either 2.24-8S or any 2.35 version. If any board is found, the "stale data delay" is set to a non-zero value.

  2. A problem was reported by Emma Shepherd (Diamond) with R6-3 if the "Use RDBL Link" field (URIP) was set to "Yes". The NTM logic was sending stop commands and issuing the "tdir=.." message to the console if the RDBL link was used. This error was the result of changing the NTM logic as described in item #11 under R6-3 modifications.

    With releases after R6-3 (e.g., R6-3-1 and R6-4), the NTM logic is restored to using feedback rather than reference positions. In addition, with release R6-4 and after, an "NTM deadband factor" field (NTMF) is added to allow the user to set the NTM deadband; NTM deadband = NTMF * (|BDST| + RDBD) NTMF must be >= 2. If properly configured, the NTM deadband prevents NTM logic from issuing a STOP command at the end of a DC motor move that overshoots its' target position.

  3. The asyn motor device driver architecture does not support the motor record GET_INFO command. Hence, operations that require a status update (i.e., setting the position) were not working. This is fixed in R6-4.

  4. In the process of fixing the OMS VME58 "stale data" problem described above, needless delays were added to the code that updated the VME58's DPRAM. These needless delays can be calculated as follows;

    delay = (n-1) * (1/sysClkRate)

    where, n = # of VME58 boards in the IOC.
    sysClkRate = 60 Hz, unless changed by a sysClkRateSet() from st.cmd.

    These delays are eliminated with R6-4-2 and above.

Known problems with Release 6-2

  1. Link errors occurred when building "XPSGatheringMain" for the solaris-sparc-gnu target. Newport users should upgrade to R6-2-1.

  2. Errors occurred in various motorApp's when building for the solaris-sparc (SUNWspro) target. SUNWspro users should upgrade to R6-2-1.

  3. Mark River's found and fixed a bug in the motor record. RDBD was being used in motor record initialization before the RDBD validation check. This resulted in motor positions not being initialized from save/restore at boot-up if RDBD was not included in a save/restore save set. This is fixed in R6-2-2.

  4. A bug was introduced into the shell command motorUtilInit affecting these versions of the motor distribution; R6-2, R6-2-1 and R6-2-2. This bug resulted in the erroneous error message; "motorUtilInit: Prefix %c: has more than 53 characters. Exiting". Replace <motor>/motorApp/MotorSrc/motorUtil.cc with the following copy:  motorUtil.cc

  5. The "alldone" PV in motorUtil.db defaulted to the "moving" state between "iocInit " and "motorUtilInit", giving the false indication that motors were moving during boot-up. The "alldone" PV now defaults to the "done" state. Replace <motor>/motorApp/Db/motorUtil.db with the following copy:  motorUtil.db

Known problems with Release 6-1

  1. The Newport PM500 driver was not issuing the correct command when it queried for the number of axes at boot up. This resulted in a "PM500 system error" message on the 1st axis; fixed in R6-2.
  2. A bug was introduced with R6-0; the OMS device support was overwriting PID parameter fields during its' normalization calculation; fixed in R6-2.
  3. There was a bug in the logic that determines the precedence between using the controller's or save/restore's motor position at boot-up. Negative controller positions were not handled correctly; fixed in R6-2
  4. The home request (HOMF/HOMR) were not cleared when a soft-limit violation occurred; fixed in R6-2.
  5. Due to releasing R6-1 during Newport development, R6-1 can result in linker errors on the symbol "xpsgathering". Newport users should upgrade to R6-2.

Known problems with Release 6-0

  1. The R6-0-bugfix CVS repository branch has become corrupted. Hence, no further changes will be made (i.e., bug fixes) to the R6-0 branch.
  2. A bug was introduced with this release. The OMS device support overwrites PID parameter fields during its' normalization calculation. This is fixed in R6-2.

Known problems with Release 5-9

  1. An undocumented change was made in R5-4 to two OMS setup functions. Namely, the unused 2nd argument ("axes per card") was eliminated from omsSetup() and oms58Setup().
  2. Since R4-5 the motor record has required that RDBD be >= MRES. The test for this condition was done using floating point values. This caused an occasional error that resulted in the record not always issuing a motor move command when RDBD = MRES and the user issued an incremental move request equal to MRES. This is fixed with R5-9-1 and R6-0.
  3. A warning message was added with R5-6 when a user attempted to move an OMS motor with an invalid velocity (slew <= base). Applications that manipulate the velocity values are unaware of this restriction and create a torrent of these messages. With release R5-9-1 and R6-0 the OMS device driver will only output this warning message once.
  4. Added a work around for OMS PC68/78 firmware error. PC68/78 controllers make an erroneous response after they are queried with the "?KP" command at boot-up. This resulted in 1st axis having same position (RP command) as last the axis. This is fixed with R5-9-1 and R6-0.
  5. GPIB under ASYN allows only one input EOS character; no output EOS is allowed. Adjustments were made to the Newport ESP300 driver to accomodate this restriction with R5-9-1 and R6-0.
  6. The CVS repository has become out of synch with the R5-9-1 tar file (motorR5-9-1.tar.gz). Hence, no further changes will be made (i.e., bug fixes) to the R5-9 branch.

Known problems with Release 5-8

Known problems with Release 5-7

Known problems with Release 5-6

Known problems with Release 5-5

Known problems with Release 5-4

  1. An undocumented change was made to two OMS setup functions. Namely, the unused 2nd argument ("axes per card") was eliminated from omsSetup() and oms58Setup() in R5-4.

Known problems with Release 5-3

  1. "sorry, not implemented: `tree_list' not supported by dump_type" error when compiling drvOms.cc and drvOms58.cc under Tornado 2.2. The Tornado 2.2 compiler (i.e., 2.96) creates errors in devLib.h. The root cause of this "bug" is a problem with the gcc-2.96 compiler bundled with Tornado 2.2. Unfortunately, to date, Wind River is only helping with workarounds; not fixing the compiler. Hence, the following patches are required.

Known problems with Release 5-2

  1. "sorry, not implemented: `tree_list' not supported by dump_type" error when compiling drvOms.cc and drvOms58.cc under Tornado 2.2. The Tornado 2.2 compiler (i.e., 2.96) creates errors in devLib.h. The root cause of this "bug" is a problem with the gcc-2.96 compiler bundled with Tornado 2.2. Unfortunately, to date, Wind River is only helping with workarounds; not fixing the compiler. Hence, the following patches are required.

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.
  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
  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.
  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.
  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.
  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.
  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.
  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.

Known problems with Release 4-8

  1. 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.
  2. Users of the status update field (STUP) should use a later release.
  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

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.

Known problems with Release 4-6

  1. An uninitialized pointer error check was omitted from ESP300_init_record() in the devESP300.c file.  This resulted in a bus error at boot-up if there was a failure to connect to the controller.  Choose one of the following methods to applying the bug fix:
  2. With release 4-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.
  3. 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.
  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-5-1 while fixing another bug; see item#2 under Modification Log from R4-5 to R4-5-1 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.

Known problems with Release 4-5

  1. Soft Channel Device Support - see Release Notice.
  2. Backlash Correction Bug Fixes - see Release Notice.
  3. With release 4-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.
  4. 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.
  5. 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.
  6. A bug was introduced in R4-5-1 while fixing another bug; see item#2 under Modification Log from R4-5 to R4-5-1 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.
  7. 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.
  8. An error occurred when the SET/USE field was in the SET mode and the FOFF field was in the FROZEN mode. Under these conditions, if the user entered a new RVAL, the record ignored every other new RVAL; with every other new DVAL that the user entered, RVAL was not updated. VAL always worked.

Known problems with Release 4-4

  1. The "Driver Power Monitoring" feature (available only for OMS VME58 controllers)  was erroneously and randomly being enabled.  Choose one of the following methods to applying the bug fix:
  2.  Code around "safeDoubleToFloat conversion bug" in EPICS R3.13.5.  A bug was introduced into R3.13.5 with the "dbConvert and dbFastLinkConv" fix (see EPICS base Release Notes for R3.13.5) that resulted in the inability to set PV fields defined as DBF_FLOAT's to zero.  One of the scenarios where this has caused a problem is when a user tries to disable software travel limits by setting DHLM = DLLM = 0.  Choose the following methods to applying the bug fix:
  3. The makeConfigAppInclude.pl perl script distibuted with R4-4 and R4-4-1 does not support spaces between the macro and the "=" sign in the config/RELEASE file.
  4. The following scenario would put the motor record into an invalid state.  A new target position (i.e., VAL/DVAL/RVAL) is written to the motor record under the following conditions,
    Install motor record version 4-4-2 or above to fix this problem.

Known problems with Release 4-3

  1. The "Driver Power Monitoring" feature (available only for OMS VME58 controllers)  was erroneously and randomly being enabled.  Choose one of the following methods to applying the bug fix:
  2. Under certain conditions target positions entered through RVAL were ignored.  If the difference between the current and the next target position (i.e., RDIF, DIFF) was less than the retry deadband (RDBD), and the next target position was in the "preferred direction", then the new RVAL was ignored.  Motor record version R4-3-2 includes the fix for this bug.

Known problems with Release 3-5

  1. Under certain conditions target positions entered through RVAL were ignored.  If the difference between the current and the next target position (i.e., RDIF, DIFF) was less than the retry deadband (RDBD), and the next target position was in the "preferred direction", then the new RVAL was ignored.