diff --git a/documentation/Problems.html b/documentation/Problems.html new file mode 100644 index 00000000..eb314b35 --- /dev/null +++ b/documentation/Problems.html @@ -0,0 +1,1091 @@ + + + + + + Motor Module Known Problems + + + +

Motor Module: Known problems

+ +

Known problems with Release 6-10

+ + +

Known problems with Release 6-9

+ + +

Known problems with Release 6-8

+ +
    +
  1. +

    + Soft-travel Limits +

    +

    +

    +

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

    +
    3. +
+ +

Known problems with Release 6-7

+ +
    +
  1. +

    + Aerotech Ensemble +

    +

    +

    +

    +
    2. + +

    +

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

    +
    3. +

    + +
+ +

Known problems with Release 6-5

+ +
    +
  1. +

    + Aerotech Ensemble +

    +

    +

    +

    +
    2. + +

    +

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

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

    +
    6. + +
+ +

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

    +

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

    +

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

    +

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

    +

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

    +

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

    +

+ +

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

    +

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

    +

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

    +

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

    5. +

    +

+ +

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

    +

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

    +

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

    +

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

    +

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

    +

+ +

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. +
  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. +
  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. +
  4. + The home request (HOMF/HOMR) were not cleared when a soft-limit violation + occurred; fixed in R6-2. +
    5. +
  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. +
    6. +
+ +

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

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

Known problems with Release 5-8

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

Known problems with Release 5-7

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

Known problems with Release 5-6

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

Known problems with Release 5-5

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

Motor Record: 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. +
    2. +
+ +

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

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

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

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

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

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

Known problems with Release 4-5

+ +
    +
  1. + Soft Channel Device Support - see Release + Notice. +
    2. + +
  2. + Backlash Correction Bug Fixes - see Release + Notice. +
    3. + +
  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. + + +
  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. + +
  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. + +
  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. + +
  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. + + +
  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. +
    9. + +
+ +

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

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

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