- 64-bit compatiablity -
-- 64-bit compile problems with the PI E816 and Aerotech Ensemble device drivers - were fixed. Mark Rivers made numerous changes to eliminate all 64-bit compiler - warning messages. -
- OMS MAXv -- Dirk Zimoch (PSI) fixed a bug in the OMS MAXv driver that caused the set_status() - function to overwrite the home switch status in the response string -
- asyn motor - -- Support for the Highland Technologies V540 motor controller has been removed. -
- Aerotech Ensemble - -- Aerotech Soloist and Ensemble asyn motor support -
-- Added two new drivers from Aerotech; the Soloist controller and an asyn motor - version of the Ensemble. Since the Ensemble network connection requires period - communication from the host to prevent the Ensemble from closing the network - socket, the Ensemble support based on the old device driver architecture will be - removed after R5-6. The asyn motor architecture supports continuous, periodic - updates; the old architecture does not. -
-- Stale SET position data from OMS VME58 controllers. -
-- A problem with certain OMS VME58 firmware versions (2.24-8S and all 2.35 - versions) has arisen since modifications made under R6-3. When the user sets - the motor record's position, the previous target and readback positions are read - from the controller on the next update. This occurs with the previous release (R6-3) - because the "stale data delay" was changed from 10ms to zero for the drvOms58 - driver. -
-- With this release the driver searches all VME58 board ID's for either 2.24-8S or - any 2.35 version. If any board is found with these versions, the "stale data - delay" is set to a non-zero value for all VME58 boards in the system. -
-- "tdir=" error messages -
-- A problem was reported by Emma Shepherd (Diamond) with the previous release 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 changes to the NTM logic in R6-3. -
-- With this release, the NTM logic is restored to using feedback rather than - reference positions. In addition, an "NTM deadband factor" field (NTMF) is - added to allow the user to set the NTM deadband as follows; -
-- 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. -
- -- Access Security Level changes -
- -- Major changes have been made to the Access Security Level (ASL) attribute of the - motor record fields. With previous releases, the following fields were set to - ASL=0; FOF, VOF, SSET, SUSE, VBAS, VMAX, SBAS, SMAX, UREV and MRES. All other - fields were set to ASL=1 by default. -
-- With this release, the policy is to set all the fields that the user requires to - do the following to ASL = 0; -
- All other fields are set to ASL = 1. -
-- This means that out of the list of fields that were previously set to ASL=0; - VBAS, VMAX, SBAS, SMAX, UREV and MRES are now set to ASL=1. -
- -- OMS MAXv A24/A32 VMEbus addressing bug fix -
-- Previous releases had a problem with the OMS MAXv device driver when it was - configured for more than one board, and, either A24 or A32 addressing was - specified. The driver was not sizing the address space occupied by each MAXv - correctly. -
- -- asyn motor archtecture updates -
--
- Deferred moves for asyn motors -
-- The asyn motor framework now supports a flag to indicate that moves should be - deferred. When at zero, moves proceed as normal. When set to one, moves - should be deferred and remembered by the controller driver, but not executed - immediately. When set back to zero, the controller driver should then start - all the moves (or at least moves to the last requested demand positions) that - have been deferred, as near to simultaneously as is possible for the - particular model of controller. The flag is implemented per-controller, so - all axes on a particular controller instance are affected, but axes on other - controllers via the same driver are unaffected. -
-- It is the responsibility of the motor controller driver to actually provide - such functionality, or to give an error if the parameter is not recognised. - Currently the Newport XPS controller driver and the Delta Tau PMAC driver - (in the tpmac module available from Diamond) support this. -
-- To use the flag, connect to any asyn port/addr combination on the controller, - using the parameter "DEFER". e.g. for a bo record, use DTYP=asynUInt32Digital, - OUT=@asynMask(port,1,1)DEFER, ZNAM="Go", ONAM="Defer" -
-- 64-bit compatiablity -
-- Previous releases of the motor record distribution would not compile for 64-bit - platforms. Numerous minor modifications were made for this release to attain 64-bit - compatibility. Note that at the time of writing (03/14/08), this release was - successfully compiled on a Linux Fedora Core 6 x86_64 host using gcc version - 4.1.2, but there are bugs. Since EPICS base (R3.14.9) has not had all the bugs - wrung out (Mantis ID's #309, #310), there are no immediate plans to debug 64-bit - related problems. -
- - attocube systems AG ANC150 - -- Ron Sluiter added support for the attocube systems AG ANC150 Piezo Step - Controller. -
- - Aerotech's Ensemble - -- Chad Weimer (Aerotech) added support for Aerotech's Ensemble family of digital - servo controllers. -
- - Physik Instrumente GmbH & Co. Model E-816 - -- John Hammonds added support of the Physik Instrumente (PI) GmbH & Co. E-816 - motor controller. -
-- save/restore of motor positions -
-- Mark Rivers found and fixed a bug in the motor record that resulted in motor - positions not being initialized from save/restore at boot-up if the retry - deadband field (RDBD) was not included in a save set. -
-- motorUtil error message -
-- 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" -
-- DC motor support -
-- Two changes were made to the motor record to better support DC motors. -
- The examples iocNoMPF and iocWithMPF were renamed iocNoAsyn and iocWithAsyn, - respectively. -
-- Animatics Corporation SmartMotor -
-- Shifu Xu's support for the Animatics Corporation SmartMotor was added. -
-- piezosystem jena, Inc. EDS -
-- Joe Sullivan added support for the piezosystem jena GmbH EDS data interface module. -
- Kohzu SC-800 - -- Ron Sluiter added support for the Kohzu SC-800 stepper motor controller. -
-- Newport PM500 Initialization Problem -
-- The 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. -
-- Overwritten PID Parameters -
-- A bug was introduced with R6-0; the OMS device support was overwriting PID - parameter fields during its' normalization calculation. -
-- Motor Position Initialization -
-- 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. -
- Newport Build Problem - -- 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. -
-- Thorlabs model MDT695 -
-- Joe Sullivan added support for Thorlabs Piezo Control Module, model MDT695. -
-- PI C-862 communiation errors -
-- A 17ms "status update delay" was added to the driver to prevent the controller - from dropping communication characters. This problem resulted in erroneous - error responses from the controller. -
-- motorStatus[xx].adl displays -
-- All motorStatus[xx].adl displays were modified to show motor position with text - rather than with bar graphs. -
-- Physik Instrumente GmbH & Co. Model E-710 -
-- Joe Sullivan added support for the Physik Instrumente (PI) GmbH & Co. Model E-710 - motor controller. -
-- OMS MAXv Polling Rate -
-- The OMS MAXv polling rate, which is set from the MAXvSetup() st.cmd command, is - allowed to be as high as the OS clock rate; i.e., (1/epicsThreadSleepQuantum()). -
-- Changes to New Focus Device Support -
-- The New Focus Model 8750 Network Controller device support ("PMNC8750") has been - changed to "PMNC87xx". It now supports both the 8750 and 8752 models. -
-- Physik Instrumente GmbH & Co. Model C-862 -
-- Mohan Ramanathan and Ron Sluiter added support for the Physik Instrumente (PI) - GmbH & Co. Model C-862 motor controller. -
- -- ACS Tech80 SPiiPlus -
-- Joe Sullivan added support for the ACS Tech80 SPiiPlus motor controller. -
- -- Spectra-Physics Encoder Mike -
-- Joe Sullivan added support for the Spectra-Physics Encoder Mike Controller (Model: - 18011). -
-- Soft Motor allocation limit -
-- Peter Denison (Diamond Light Source) enhanced the Soft Channel device support by - eliminating the 50 soft motor limit and replacing it with an unlimited linked list. -
-- All motors done/stop/moving utility -
-- Kevin Peterson's (UNI-CAT) motorUtil task was added to the motor record - distribution. The motorUtil task monitors and maintains 3 PV's; $(P)alldone, $(P)allstop, - $(P)moving. motorUtil is a replacement for the all_com_##.db distributed with - the STD support module. See the motorUtil.db file for details. -
- -- Asyn Motor -
-- Peter Denison (Diamond), Nick Rees (Diamond) and Mark Rivers (APS) have added a - new motor record device support architecture based on ASYN; called "asyn motor" - support. The asyn motor support is an attempt to define a clean, extensible - API for motor controller drivers to support. This is a preliminary release - of work in progress. Do not use asynMotor device support at this time, except - for development and testing purposes only. -
- -- New Focus 8750 Network Controller -
-- Joe Sullivan added support for the New Focus Model 8750 Network Controller. -
- -- Physik Instrumente (PI) E-662 piezo controller -
-- Joe Sullivan added support for the Physik Instrumente (PI) GmbH & Co. Model E-662 - piezo controller. -
- -- Newport XPS-C8 asyn motor support -
-- Mark Rivers added asyn motor support for the Newport XPS-C8 motor controller. - This is a preliminary release of work in progress. However, it has fewer - problems than the previous XPS support, so we recommend using the new asyn - support for the XPS, with the understanding that it is still under development. -
- -- Trajectory Scanning -
-- Mark Rivers added the Trajectory Scanning software for both the Newport MM4005 - and XPS-C8 motor controllers to the motor record distribution. -
- -- OMS PC68 and PC78 support -
-- Brian Tieman and Ron Sluiter added support for the standalone, RS-232 versions - of the OMS PC68 and PC78 model controllers. The same device driver (OMS PC68/78) - supports both models. -
-- Faulhaber MCDC2805 -
-- Mark Rivers added support for the Faulhaber MCDC2805 servo controller. -
- -- Parker Hannifin, Compumotor Division, 6K Series -
-- Joe Sullivan added support for Parker Hannifin, Compumotor Division, 6K Series - controllers. -
-- With this release, if the absolute values of both the save/restore's target - position and the controller's commanded position are greater than the re-try - deadband (RDBD) at boot-up, then DVAL will be initialized from the controller's - value. In other words, if the absolute value of the controller's commanded - position is greater than the re-try deadband at boot-up, than the controller's - position takes precedence over the save/restore value. -
-- Physik Instrumente (PI) C-630 -
-- Kurt Goetze added support for the Physik Instrumente (PI) model C-630 motion - controller. -
- -- Physik Instrumente (PI) C-848 -
-- Support added for the Physik Instrumente (PI) C-848 motor controller. -
-- IMS MDrive users must make the following configuration changes to their MDrive's - as described in the distribution document "motorR5-6/motorApp/ImsSrc/README". -
- The motor record distribution has been converted from MPF to ASYN R4.1. All - support for MPF has been removed. -
-- Slew acceleration calculations were incorrect. Instead of the correct - calculation; A = (Vf - Vo) / t, the record was using A = Vf / t, which is - correct only if Vo (VBAS) is zero. Thanks to Harvey Rarback for pointing out - this long standing error. -
-- If the motor record is processed and there are no functions to perform (i.e., no - current or outstanding move request), then the motor record will perform a status - update using the STUP field. -
-- OMS MAXv device support -
- Device support for Oregon Micro Systems, Inc. MAXv controller was added. --
- -- Delta Tau PMAC -
-- Device support for Delta Tau's PMAC2-VME controller was added. -
-- 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). - Although this problem has been resolved there is a design problem with the OMS - VME58 servo controller that prevents it, in most cases, from moving off an - activated limit switch. Users are advised to avoid this situation -
- - Encoder Resolution (ERES) Polarity -- Previous releases of the motor record forced the sign of ERES to match the sign - of MRES. With this release, ERES and MRES may have different signs. This - allows the user to change the sign of ERES rather than reverse encoder wires - when the motor and encoder direction are reversed. Warning! This does - not work with controllers that are doing closed-loop control; e.g., DC motors. - Reference (D/A) and feedback (encoder) signals must have the same polarity for - DC motors or the motor will literally run away. -
- -- PID parameter initialization -
-- PID parameters (i.e., PCOF, ICOF and DCOF fields) were not initialized at boot-up. - With this release, 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. -
- -- IMS MDrive Device Driver -
-- 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. - A README file has been added to the ImsSrc directory that documents how the - MDrive must be initialized before using it with this device driver. -
-- - Three Device Drivers New To R3.14.x -
-- The following three device drivers have been ported from the R3.13.x compatible - version of the motor record: -
- Status Update (STUP) -
-- The STUP field (Status Update) has been modified due to bug fixes. The STUP - field functions as follows; -
- With the STUP field it is possible to have another EPICS record periodically - write ON(1) to the motor record's STUP field. This would result in continuous, - periodic status updates. -
-- Newport MM3000 Communication -
-- 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. -
- -- OMS VX2-006 Spurious Interrupts -
-- Spurious interrupts were occurring with OMS VX2-006 ver 1.04 controller boards. - For the sake of throughput, the OMS VME8/44 device driver enables the done (DON_E) - and input buffer full (IBF_E) interrupts, but disables the transmit buffer empty - (TBE_E). -
-- The OMS boards are RORA VME type interrupters. The "release" register is the - status register. It contains information on the status of the transmit/receive - buffer interrupts and the done interrupt. Since the device driver was not using - the transmit buffer empty interrupt, it was polling the status register when - sending a command to the controller. With the VX2, if the IRQ became active - during a status register read cycle, the IRQ was negated at the end of the cycle - and the CPU board generated a spurious interrupt. -
-- The VME8/44 models somehow prevented the spurious interrupts from occurring by - latching the IRQ, if and when, the IRQ became active during a status register - read. -
-- This problem has been fixed by using all of the OMS board interrupts (i.e., - enable transmit buffer empty). The OMS VME8/44/VX2/VS4 design is limited with - regard to interrupts by an all or none choice. -
- -- Backlash Correction Bug Fix -
-- 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. -
- -- Newport ESP300 Device Driver Crash -
-- 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 distribution document motor/motorApp/NewportSrc/README. -
- -- Update Rate Bug Fix -
-- There were two timing related bugs with the previous release (R5.1). First, the - update rate was not working properly. The end result was that the motor task - was polling controllers as fast as possible. Second, there was an error in the - motor_task function process_messages() that enforces a time delay between - UNDEFINED or IMMEDIATE type commands (e.g., LOAD_POS, SET_ENC_RATIO, etc.) and - an INFO type command. One result of this error was that on OMS VME58 - controllersan INFO update after a LOAD_POS command would, intermittently, yield - the previous position. -
- -- Backlash Correction after Jogging Bug Fix -
-- Backlash correction after jogging was not working for controllers that do not - support multiple position commands on the same command line (e.g., Newport - ESP300). This has been corrected with this release with one caveat; in contrast - to the feature described in Backlash Correction Bug Fix above, backlash - correction is always done after jogging, regardless of the jog acceleration and - speed parameters -
- -- DLY field -
-- 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. -
-
- Since a functioning DLY field performs the same function as the drv
- New Features + 64-bit compatability
-- PREM - @PUT(pvname, pv-value, delay in seconds)@-
-
- POST - @PUT(pvname, pv-value)@- Note that the PREM supports a delay argument, but that POST does not. The Readback - settle time field (DLY) should be used to create a time delay after the PV - specified in the POST field is written. See the Miscellaneous fields - section of motorRecord.html for further information on the INIT, PREM and POST - fields.
-
+ 64-bit compile problems with the PI E816 and Aerotech Ensemble device drivers were + fixed. Mark Rivers made numerous changes to eliminate all 64-bit compiler warning + messages. +
+ OMS MAXv ++ Dirk Zimoch (PSI) fixed a bug in the OMS MAXv driver that caused the set_status() + function to overwrite the home switch status in the response string +
++ asyn motor +
++ Highland Technologies +
++ Support for the Highland Technologies V540 motor controller has been removed. +
++ Aerotech Ensemble +
++ Aerotech Soloist and Ensemble asyn motor support +
++ Added two new drivers from Aerotech; the Soloist controller and an asyn motor version + of the Ensemble. Since the Ensemble network connection requires period communication + from the host to prevent the Ensemble from closing the network socket, the Ensemble + support based on the old device driver architecture will be removed after R5-6. + The asyn motor architecture supports continuous, periodic updates; the old architecture + does not. +
++
++ Stale SET position data from OMS VME58 controllers. +
++ A problem with certain OMS VME58 firmware versions (2.24-8S and all 2.35 versions) + has arisen since modifications made under R6-3. When the user sets the motor record's + position, the previous target and readback positions are read from the controller + on the next update. This occurs with the previous release (R6-3) because the "stale + data delay" was changed from 10ms to zero for the drvOms58 driver. +
++ With this release the driver searches all VME58 board ID's for either 2.24-8S or + any 2.35 version. If any board is found with these versions, the "stale data delay" + is set to a non-zero value for all VME58 boards in the system. +
++ "tdir=" error messages +
++ A problem was reported by Emma Shepherd (Diamond) with the previous release 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 changes to the NTM logic in R6-3. +
++ With this release, the NTM logic is restored to using feedback rather than reference + positions. In addition, an "NTM deadband factor" field (NTMF) is added to allow + the user to set the NTM deadband as follows; +
++ 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. +
++ Access Security Level changes +
++ Major changes have been made to the Access Security Level (ASL) attribute of the + motor record fields. With previous releases, the following fields were set to ASL=0; + FOF, VOF, SSET, SUSE, VBAS, VMAX, SBAS, SMAX, UREV and MRES. All other fields were + set to ASL=1 by default. +
++ With this release, the policy is to set all the fields that the user requires to + do the following to ASL = 0;
++ All other fields are set to ASL = 1. +
++ This means that out of the list of fields that were previously set to ASL=0; VBAS, + VMAX, SBAS, SMAX, UREV and MRES are now set to ASL=1. +
++ OMS MAXv A24/A32 VMEbus addressing bug fix +
++ Previous releases had a problem with the OMS MAXv device driver when it was configured + for more than one board, and, either A24 or A32 addressing was specified. The driver + was not sizing the address space occupied by each MAXv correctly. +
++ asyn motor archtecture updates +
++ Deferred moves for asyn motors +
++ The asyn motor framework now supports a flag to indicate that moves should be deferred. + When at zero, moves proceed as normal. When set to one, moves should be deferred + and remembered by the controller driver, but not executed immediately. When set + back to zero, the controller driver should then start all the moves (or at least + moves to the last requested demand positions) that have been deferred, as near to + simultaneously as is possible for the particular model of controller. The flag is + implemented per-controller, so all axes on a particular controller instance are + affected, but axes on other controllers via the same driver are unaffected. +
++ It is the responsibility of the motor controller driver to actually provide such + functionality, or to give an error if the parameter is not recognised. Currently + the Newport XPS controller driver and the Delta Tau PMAC driver (in the tpmac module + available from Diamond) support this. +
++ To use the flag, connect to any asyn port/addr combination on the controller, using + the parameter "DEFER". e.g. for a bo record, use DTYP=asynUInt32Digital, OUT=@asynMask(port,1,1)DEFER, + ZNAM="Go", ONAM="Defer" +
++ 64-bit compatiablity +
++ Previous releases of the motor record distribution would not compile for 64-bit + platforms. Numerous minor modifications were made for this release to attain 64-bit + compatibility. Note that at the time of writing (03/14/08), this release was successfully + compiled on a Linux Fedora Core 6 x86_64 host using gcc version 4.1.2, but there + are bugs. Since EPICS base (R3.14.9) has not had all the bugs wrung out (Mantis + ID's #309, #310), there are no immediate plans to debug 64-bit related problems. +
++ attocube systems AG ANC150 +
++ Ron Sluiter added support for the attocube systems AG ANC150 Piezo Step Controller. +
++ Aerotech's Ensemble +
++ Chad Weimer (Aerotech) added support for Aerotech's Ensemble family of digital servo + controllers. +
++ Physik Instrumente GmbH & Co. Model E-816 +
++ John Hammonds added support of the Physik Instrumente (PI) GmbH & Co. E-816 + motor controller. +
++
++ save/restore of motor positions +
++ Mark Rivers found and fixed a bug in the motor record that resulted in motor positions + not being initialized from save/restore at boot-up if the retry deadband field (RDBD) + was not included in a save set. +
++ motorUtil error message +
++ 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" +
++ DC motor support +
++ Two changes were made to the motor record to better support DC motors.
++ Examples renamed +
++ The examples iocNoMPF and iocWithMPF were renamed iocNoAsyn and iocWithAsyn, respectively. +
++ Animatics Corporation SmartMotor +
++ Shifu Xu's support for the Animatics Corporation SmartMotor was added. +
++ piezosystem jena, Inc. EDS +
++ Joe Sullivan added support for the piezosystem jena GmbH EDS data interface module. +
++ Kohzu SC-800 +
++ Ron Sluiter added support for the Kohzu SC-800 stepper motor controller. +
++ Newport PM500 Initialization Problem +
++ The 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. +
++ Overwritten PID Parameters +
++ A bug was introduced with R6-0; the OMS device support was overwriting PID parameter + fields during its' normalization calculation. +
++ Motor Position Initialization +
++ 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. +
++ Newport Build Problem +
++ 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. +
++ Thorlabs model MDT695 +
++ Joe Sullivan added support for Thorlabs Piezo Control Module, model MDT695. +
+
+
+ Requirements
+
+ EPICS base R3.14.8.2 or greater. See the "Required Modules" section of the
+ Motor Record web page for details.
+
+ PI C-862 communiation errors +
++ A 17ms "status update delay" was added to the driver to prevent the controller from + dropping communication characters. This problem resulted in erroneous error responses + from the controller. +
++ motorStatus[xx].adl displays +
++ All motorStatus[xx].adl displays were modified to show motor position with text + rather than with bar graphs. +
++ Physik Instrumente GmbH & Co. Model E-710 +
++ Joe Sullivan added support for the Physik Instrumente (PI) GmbH & Co. Model + E-710 motor controller. +
+
+
+ Requirements
+
+ EPICS base R3.14.8.2 or greater. See the "Required Modules" section of the
+ Motor Record web page for details.
+
+ OMS MAXv Polling Rate +
++ The OMS MAXv polling rate, which is set from the MAXvSetup() st.cmd command, is + allowed to be as high as the OS clock rate; i.e., (1/epicsThreadSleepQuantum()). +
++ Changes to New Focus Device Support +
++ The New Focus Model 8750 Network Controller device support ("PMNC8750") has been + changed to "PMNC87xx". It now supports both the 8750 and 8752 models. +
++ Physik Instrumente GmbH & Co. Model C-862 +
++ Mohan Ramanathan and Ron Sluiter added support for the Physik Instrumente (PI) GmbH + & Co. Model C-862 motor controller. +
++ ACS Tech80 SPiiPlus +
++ Joe Sullivan added support for the ACS Tech80 SPiiPlus motor controller. +
++ Spectra-Physics Encoder Mike +
++ Joe Sullivan added support for the Spectra-Physics Encoder Mike Controller (Model: + 18011). +
+
+
+ Requirements
+
+ EPICS base R3.14.8.2 or greater. See the "Required Modules" section of the
+ Motor Record web page for details.
+
+ Soft Motor allocation limit +
++ Peter Denison (Diamond Light Source) enhanced the Soft Channel device support by + eliminating the 50 soft motor limit and replacing it with an unlimited linked list. +
++ All motors done/stop/moving utility +
++ Kevin Peterson's (UNI-CAT) motorUtil task was added to the motor record distribution. + The motorUtil task monitors and maintains 3 PV's; $(P)alldone, $(P)allstop, $(P)moving. + motorUtil is a replacement for the all_com_##.db distributed with the STD support + module. See the motorUtil.db file for details. +
++ Asyn Motor +
++ Peter Denison (Diamond), Nick Rees (Diamond) and Mark Rivers (APS) have added a + new motor record device support architecture based on ASYN; called "asyn motor" + support. The asyn motor support is an attempt to define a clean, extensible API + for motor controller drivers to support. This is a preliminary release of + work in progress. Do not use asynMotor device support at this time, except + for development and testing purposes only. +
++ New Focus 8750 Network Controller +
++ Joe Sullivan added support for the New Focus Model 8750 Network Controller. +
++ Physik Instrumente (PI) E-662 piezo controller +
++ Joe Sullivan added support for the Physik Instrumente (PI) GmbH & Co. Model + E-662 piezo controller. +
++ Newport XPS-C8 asyn motor support +
++ Mark Rivers added asyn motor support for the Newport XPS-C8 motor controller. This + is a preliminary release of work in progress. However, it has fewer problems than + the previous XPS support, so we recommend using the new asyn support for the XPS, + with the understanding that it is still under development. +
++ Trajectory Scanning +
++ Mark Rivers added the Trajectory Scanning software for both the Newport MM4005 and + XPS-C8 motor controllers to the motor record distribution. +
++ OMS PC68 and PC78 support +
++ Brian Tieman and Ron Sluiter added support for the standalone, RS-232 versions of + the OMS PC68 and PC78 model controllers. The same device driver (OMS PC68/78) supports + both models. +
+
+
+ Requirements
+
+ EPICS base R3.14.7 or greater. See the "Required Modules" section of the Motor
+ Record web page for details.
+
+ Faulhaber MCDC2805 +
++ Mark Rivers added support for the Faulhaber MCDC2805 servo controller. +
++ Parker Hannifin, Compumotor Division, 6K Series +
++ Joe Sullivan added support for Parker Hannifin, Compumotor Division, 6K Series controllers. +
+
+
+ Requirements
+
+ EPICS base R3.14.7 or greater. See the "Required Modules" section of the Motor
+ Record web page for details.
+
+ With this release, if the absolute values of both the save/restore's target position + and the controller's commanded position are greater than the re-try deadband (RDBD) + at boot-up, then DVAL will be initialized from the controller's value. In other + words, if the absolute value of the controller's commanded position is greater than + the re-try deadband at boot-up, than the controller's position takes precedence + over the save/restore value. +
++ Physik Instrumente (PI) C-630 +
++ Kurt Goetze added support for the Physik Instrumente (PI) model C-630 motion controller. +
++ Physik Instrumente (PI) C-848 +
++ Support added for the Physik Instrumente (PI) C-848 motor controller. +
+
+
+ Requirements
+
+ EPICS base R3.14.7 or greater. See the "Required Modules" section of the Motor
+ Record web page for details.
+
+ IMS MDrive users must make the following configuration changes to their MDrive's + as described in the distribution document "motorR5-6/motorApp/ImsSrc/README". +
+
+
+ Requirements
+
+ EPICS base R3.14.7 or greater. See the "Required Modules" section of the Motor
+ Record web page for details.
+
+ The motor record distribution has been converted from MPF to ASYN R4.1. All support + for MPF has been removed. +
++ Slew acceleration calculations were incorrect. Instead of the correct calculation; + A = (Vf - Vo) / t, the record was using A = Vf / t, which is correct only if Vo + (VBAS) is zero. Thanks to Harvey Rarback for pointing out this long standing error. +
+
+
+ Requirements
+
+ EPICS base R3.14.6 or greater. See the "Required Modules" section of the Motor
+ Record web page for details.
+
+ If the motor record is processed and there are no functions to perform (i.e., no + current or outstanding move request), then the motor record will perform a status + update using the STUP field. +
++ OMS MAXv device support +
+ Device support for Oregon Micro Systems, Inc. MAXv controller was added. ++
++ Delta Tau PMAC +
++ Device support for Delta Tau's PMAC2-VME controller was added. +
+
+
+ Requirements
+
+ EPICS base R3.14.5 or greater. See the "Required Modules" section of the Motor
+ Record web page for details.
+
+ OMS VME58 Servo Limit Switch Problem
++ 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). Although + this problem has been resolved there is a design problem with the OMS VME58 servo + controller that prevents it, in most cases, from moving off an activated limit switch. + Users are advised to avoid this situation +
++ Encoder Resolution (ERES) Polarity
++ Previous releases of the motor record forced the sign of ERES to match the sign + of MRES. With this release, ERES and MRES may have different signs. This allows + the user to change the sign of ERES rather than reverse encoder wires when the motor + and encoder direction are reversed. Warning! This does not work with controllers + that are doing closed-loop control; e.g., DC motors. Reference (D/A) and feedback + (encoder) signals must have the same polarity for DC motors or the motor will literally + run away. +
++ PID parameter initialization +
++ PID parameters (i.e., PCOF, ICOF and DCOF fields) were not initialized at boot-up. + With this release, 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. +
++ IMS MDrive Device Driver +
++ 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. + A README file has been added to the ImsSrc directory that documents how the MDrive + must be initialized before using it with this device driver. +
++ Three Device Drivers New To R3.14.x +
++ The following three device drivers have been ported from the R3.13.x compatible + version of the motor record:
++ Status Update (STUP) +
++ The STUP field (Status Update) has been modified due to bug fixes. The STUP field + functions as follows;
++ With the STUP field it is possible to have another EPICS record periodically write + ON(1) to the motor record's STUP field. This would result in continuous, periodic + status updates. +
+
+
+ Requirements
+
+ EPICS base R3.14.4 or greater. See the "Required Modules" section of the Motor
+ Record web page for details.
+
+ Newport MM3000 Communication +
++ 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. +
++ OMS VX2-006 Spurious Interrupts +
++ Spurious interrupts were occurring with OMS VX2-006 ver 1.04 controller boards. + For the sake of throughput, the OMS VME8/44 device driver enables the done (DON_E) + and input buffer full (IBF_E) interrupts, but disables the transmit buffer empty + (TBE_E). +
++ The OMS boards are RORA VME type interrupters. The "release" register is the status + register. It contains information on the status of the transmit/receive buffer interrupts + and the done interrupt. Since the device driver was not using the transmit buffer + empty interrupt, it was polling the status register when sending a command to the + controller. With the VX2, if the IRQ became active during a status register read + cycle, the IRQ was negated at the end of the cycle and the CPU board generated a + spurious interrupt. +
++ The VME8/44 models somehow prevented the spurious interrupts from occurring by latching + the IRQ, if and when, the IRQ became active during a status register read. +
++ This problem has been fixed by using all of the OMS board interrupts (i.e., enable + transmit buffer empty). The OMS VME8/44/VX2/VS4 design is limited with regard to + interrupts by an all or none choice. +
++ Backlash Correction Bug Fix +
++ 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. +
++ Newport ESP300 Device Driver Crash +
++ 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 distribution document motor/motorApp/NewportSrc/README. +
++ Update Rate Bug Fix +
++ There were two timing related bugs with the previous release (R5.1). First, the + update rate was not working properly. The end result was that the motor task was + polling controllers as fast as possible. Second, there was an error in the motor_task + function process_messages() that enforces a time delay between UNDEFINED or IMMEDIATE + type commands (e.g., LOAD_POS, SET_ENC_RATIO, etc.) and an INFO type command. One + result of this error was that on OMS VME58 controllersan INFO update after a LOAD_POS + command would, intermittently, yield the previous position. +
++ Backlash Correction after Jogging Bug Fix +
++ Backlash correction after jogging was not working for controllers that do not support + multiple position commands on the same command line (e.g., Newport ESP300). This + has been corrected with this release with one caveat; in contrast to the feature + described in Backlash Correction Bug Fix above, backlash correction is always + done after jogging, regardless of the jog acceleration and speed parameters +
++ DLY field +
++ 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. +
++ Since a functioning DLY field performs the same function as the drvReadbackDelay + variables, with the added advantage that the delay can be motor specific, the drvReadbackDelay + variables have been deleted (except for the MM4000). +
+
+ !WARNING!
+
+
+ Requirements
+
+ EPICS base R3.14.2 or greater. See the "Required Modules" section of the Motor
+ Record web page for details.
+
+ !WARNING!
+ motorRecord.dbd has been modified. This requires rebuilding any and all user
+ trees (i.e., <ioctop>) that load the motor record (see README items #3 and
+ #4 for details).
+
+ New Features +
+
+ !WARNING!
+ motorRecord.dbd has been modified. This requires rebuilding any and all user
+ trees (i.e., <ioctop>) that load the motor record (see README items #3 and
+ #4 for details).
+
+++ Case #1: The motor record is given a new position, which is in the opposite direction + from the current motor motion. If NTM is yes, the motor is immediately stopped + and given a motion command to the new position. If NTM is no, the motor completes + the previous move before it is given a motion command to the new position. +
+
+++ Case #2: The motor record is given a new position, which is in the same direction + as the current motor motion, but the new position is closer to the motor's current + position than the original target position. If NTM is yes, the motor is stopped + after it has gone past the new position; then a command is given to return to the + new position. If NTM is no, the motor completes the previous move before it + is given a motion command to the new position. +
+
+++ Case #3: The motor record is given a new position, which is in the same direction + as the current motor motion, but the new position is further from the motor's current + position than the original position. After the motor reaches the original + target position and stops, a command is given to the new target position. + This case is independent of NTM. +
+
+
++ New Features +
+
+ !WARNING!
+ motorRecord.dbd has been modified. This requires you to 'rebuild' any and
+ all user trees (i.e., <ioctop>) that load the motor record (see README item
+ #2 for details).
+
+ Communication Retries
++ Once a communication error is detected, one retry is attempted (Further retries + are made, if the position RETRY field is non-zero). If the retry fails, then + a communication error is reported. No further attempt is made to communicate + with the controller until subsequent user input (e.g., a new target position is + entered). This change affects all device drivers using GPIB or RS232 serial + communication mechanisms (i.e., non-VME Bus boards). +
++ The requirements on how the motor record processes a new target position while the + motor is in motion have never been specified. The requirements are as follows:
- Case #1: The motor record is given a new position, which is in the opposite - direction from the current motor motion. If NTM is yes, the motor - is immediately stopped and given a motion command to the new position. If - NTM is no, the motor completes the previous move before it is given a - motion command to the new position.-
-
- Case #2: The motor record is given a new position, which is in the same - direction as the current motor motion, but the new position is closer to the - motor's current position than the original target position. If NTM is yes, - the motor is stopped after it has gone past the new position; then a command is - given to return to the new position. If NTM is no, the motor - completes the previous move before it is given a motion command to the new - position.-
-
- Case #3: The motor record is given a new position, which is in the same - direction as the current motor motion, but the new position is further from the - motor's current position than the original position. After the motor - reaches the original target position and stops, a command is given to the new - target position. This case is independent of NTM.-
-
- New Features + Case #1: The motor record is given a new position, which is in the opposite + direction from the current motor motion. The motor is immediately stopped + and given a motion command to the new position.
--Once a communication error is detected, one retry is attempted (Further retries -are made, if the position RETRY field is non-zero). If the retry fails, -then a communication error is reported. No further attempt is made to -communicate with the controller until subsequent user input (e.g., a new target -position is entered). This change affects all device drivers using GPIB or -RS232 serial communication mechanisms (i.e., non-VME Bus boards). -
-- Case #1: The motor record is given a new position, which is in the - opposite direction from the current motor motion. The motor is immediately - stopped and given a motion command to the new position. -- -
- Case #2: The motor record is given a new position, which is in the same - direction as the current motor motion, but the new position is closer to the - motor's current position than the original target position. The motor is - stopped after it has gone past the new position; then a command is given to - return to the new position.- -
-
- Case #3: The motor record is given a new position, which is in the same - direction as the current motor motion, but the new position is further from the - motor's current position than the original position. After the motor - reaches the original target position and stops, a command is given to the new - target position (Previous motor record versions ignored the new target position.) -
-Soft Channel device support modifications -
- --For VMEbus based motor controllers only (i.e., OMS), a hole in an array -of VME based motor controller boards caused the system to crash with a memory access -error on the address of the missing controller. For example, if -oms58Setup(3, 8, 0x4000, 190, 5, 10) was issued without a board at 0xFFFF5000, a -bus error would occur if the user attempted to move a motor on the missing board. -
- --This release allows holes in an array of VMEbus based motor controllers. -
- --RES Field -
- --With previous releases of the motor record, the RES field was set to either ERES -or MRES, based on whether or not the following statement was true; MSTA -indicates an encoder is present, AND, UEIP is set to YES. This state (i.e., -MSTA indicates an encoder is present, AND, UEIP is set to YES) resulted in the -record converting all position and velocity related values from EGU's to raw -encoder counts before sending them to the motor controller. This is the -manner in which the OMS controllers work (see OMS User's Manual, ER# command). -
- -
-With this release, all raw positions, velocity and acceleration are in terms of
-motor steps. The RES field is preserved for backward compatibility only. With
-this release, the RES field is always equal to MRES.
-
---
-- - DIRECTION: (0:Negative, 1:Positive) -
-- - DONE: motion is complete. -
-- - PLUS_LS: plus limit switch has been hit. -
-- - HOMELS: state of the home limit switch. -
-- - Unused -
-- - POSITION: closed-loop position control is enabled. -
-- - Unused -
-- - HOME: if at home position. -
-- - PRESENT: encoder is present. -
-- - PROBLEM: driver stopped polling. -
-- - MOVING: non-zero velocity present. -
-- - GAIN_SUPPORT: motor supports closed-loop position control. -
-- - COMM_ERR: Controller communication error. -
-- - MINUS_LS: minus limit switch has been hit.
- -
-
- New Features -
--Advanced Control Systems and Mclennan device driver support -
- --Mark Rivers has added device driver support for the following motor controllers: -
- --The travel limits can be disabled by setting both dial high and low limits equal -to zero; i.e., DHLM = DLLM = 0. -
- --RVAL ignored error -
- --A problem was discovered with entering target positions through RVAL. 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. This error -occured on releases as far back as V3.4. -
- --Two new fields (JVEL and JAR) were added to support jog velocity and -acceleration parameters. These fields are only supported with Oregon Micro -Systems, Inc device driver support. The JVEL field allows the user to -change the jog velocity of the motor on-the-fly. -
- --STOP field hangs record -
- --An error was introduced into the motor record with the release of V4.2 (see -README file item #14 under V4.2 ). This error occurred if the STOP field -was activated when the motor was not moving (i.e., MIP = 0). The motor -record would become "stuck", and not respond to a move request (due to the -internal state machine associated with IP being set to the "stop" state), until -the condition was cleared by either a SPMG-stop or some other user action that -forced the MIP field to zero. -
- --HIDEOS support removed -
- -
-HIDEOS is no longer supported. MPF is the only supported alternative to
-HIDEOS.
-
-
-!WARNING!
-motorRecord.dbd has been modified. This requires you to 'rebuild' any and
-all user trees (i.e., <ioctop>) that load the motor record (see README
-item #20 for details).
-
-
-
-At boot-up, if one field of a field pair (i.e., VMAX/SMAX, VBAS/SBAS, VELO/S, -BVEL/SBAK) is zero and the other field is nonzero, the nonzero field takes -precedence. If both fields of a given field pair are nonzero, the RPS -member of the field pair (i.e., SMAX, SBAS, S, SBAK) takes precedence. -This requirement was lost with the release of V4.0. -
- --Moving Off a Limit Switch with a Oms58 device -
- --An error occurs with the OMS VME58 when the user runs the motor into a limit -switch and then attempts to move away from the limit switch. If either an -absolute or incremental move is utilized to move away from the limit switch, the -OMS VME58 ignores the 1st move attempt. Subsequent moves work. In -addition, the user can jog off a limit switch. This error was hidden in -most applications if RTRY was nonzero. -
- --Separate motion commands for target and backlash moves -
- --The record level support assumed that the motor controller would accept two -motion commands on the same command line. This occurs when backlash -compensation is enabled. Since the IM483[PL/SM] controller does not have -this capability, support for a command line "record separator" character was -added. The record separator is defined as an ASCII (IS2) character = /x1E. -Currently, only one record separator is allowed in a command line. -
- --Errors introduced in V4.0 -
- --Unfortunately, several errors were introduced into the motor record with V4.0. -The following have been fixed: -
- --Device driver support for the Newport PM500 is available for this release of the -motor record. This device/driver is based on Mark River's PM500 V2.0 -release. -
- --Intelligent Motion Systems, Inc. IM483 device support -
- -
-Device driver support for Intelligent Motion Systems (IMS) IM483[I/IE] is
-available with this release. Two different device/drivers are available
-for the same motor controller. The two device/drivers, IM483PL and
-IM483SM, correspond to the two available IM483 communication modes, party
-line and single mode, respectively (see the IMS Software Reference
-Manual for details).
-
-
-All previous motor record releases contained the DMOV problem; the commanded
-position update problem was limited to the previous release (V3.5). With
-this release, a dbPutField to either HOMF or HOMR is valid on a FALSE to TRUE
-transition (i.e., 0 to 1), but a TRUE to FALSE transition (i.e., 1 to 0) will
-result in an error. motorx_all.adl_V2.2 (which is included
-with this distribution) sets the HOM[F/R] fields on when the user presses the
-homing button, but is does not set it off when the button is released.
-The motor record clears the HOM[F/R] field when the homing operation is done (i.e.,
-completed or terminated).
-
-
-Previous releases of the motor record allowed the auto restore to take
-precedence over the controller when initializing the target position (i.e., DVAL).
-
-
-
-- --
-- - MRES -
-- - UREV -
-- - VBAS -
-- - SBAS -
- -
-Device driver support for the MM3000 exist for this release of the motor record. -Note the following differences between the MM4000 and MM3000 device drivers: -
- --In order to support BURT, range checking is done in such a way that any minimum -(i.e., VBAS/SBAS) or maximum (i.e., VMAX/SMAX) value entered is valid. -For example, if the minimum is entered and it exceeds the maximum, then the -maximum is set to the new minimum value. Slew (VELO/S) and backup -velocity (BVEL/SBAK) fields are forced by the motor record to be within the -range set by VMAX/SMAX and VBAS/SBAS, inclusively. For example, if VELO is -entered and it is less than the minimum, then VELO is set to VBAS. -
- --To facilitate software upgrades, a zero VMAX disables maximum velocity error -checking. Those who use both BURT and VMAX (i.e., nonzero VMAX) should -insure that VMAX and VBAS are placed before VELO and BVEL in their BURT request -files. VMAX/SMAX have Access Security Level zero. -
- -
-motorx_setup_1.7.adl (which is included with this distribution) includes
-support for the maximum velocity fields.
-
-
- 1. INIT - Sent at record initialization.-No error checking is done by the motor record or the device driver to insure -that the command strings are valid. Command primitives that result in a -response from the motion control board are valid, but the response is not -processed.
- 2. PREM - Sent before every command string that causes motion.
- 3. POST - Sent after a complete motion is finished or when an - overtravel limit switch is detected. -
--- - First character of INIT string must be a '@'. -
-- - One or more characters followed by a terminating '@'; i.e., device directives - must have nonzero length. -
-- - A valid device directive; currently, only "DPM_ON". -
-New fields have been added to the motor record to support the Soft Channel
-device driver. The new fields are all database links associated with
-existing motor record fields. The new links and their associated fields
-are listed in the table below:
-
-
-
| Link | -Link Type | -Associated Field | -
| OUT* | -DBOUTPUT | -
- |
-
| STOO | -DBOUTPUT | -STOP | -
| DINP | -DBINPUT | -DMOV | -
| RDBL* | -DBINPUT | -
- |
-
| RINP | -DBINPUT | -
- |
-
+++ Case #2: The motor record is given a new position, which is in the same direction + as the current motor motion, but the new position is closer to the motor's current + position than the original target position. The motor is stopped after it + has gone past the new position; then a command is given to return to the new position. +
+
+++ Case #3: The motor record is given a new position, which is in the same direction + as the current motor motion, but the new position is further from the motor's current + position than the original position. After the motor reaches the original + target position and stops, a command is given to the new target position (Previous + motor record versions ignored the new target position.) +
+
- * - Not a new field, but a new function provided only by soft channel device - support. + The Driver Power Monitoring feature (available only with OMS VME58 controllers) + was erroneously and randomly being enabled. This resulted in the error message + Drive power failure at VME58 card# motor# appearing at the VxWorks console.
++ Soft Channel device support modifications
--The Soft Channel database links are only processed when the Soft Channel device -driver is selected. These links are ignored when using any other Motor -Record device driver. At this time, the above links are not -dynamically retargetable. -
- -
-The OUT, DINP and RDBL are monitored for value changes via a CA event task.
-Users must choose either a dial input link (RDBL) or a raw input link (RINP),
-but not both.
-
-
-
-- --
-- - When either user or dial travel limit values are entered, a validity check is - made using the travel limit values from the MM4000 control. User and dial - travel limit values are valid if they are within the travel limits set on the - front panel of the MM4000 controller. Attempting to enter a travel limit - outside the MM4000 controller's range results in the travel limit being reset to - the MM4000's value. -
-- - Servo support has been extended to the MM4000 controller. -
- -
- For the MM4000 For all OMS - controllers -- -
-It is difficult to enumerate the symptoms associated with this problem. -Sometimes they exhibited themselves intermittently, other times bad data stayed -in the record. Several symptoms are as follows: -
- -- --
-- - Erroneous motor stops being issued by the device support when changing motor - direction. +
- Prevent record processing before "interruptAccept" is true. This helps prevent + alarms.
+- If the readback is changing, but motion was not initiated by this record, then + reset the motor record's target to actual position (i.e., VAL/DVAL/RVAL = RBV/DRBV/RRBV) + after the move.
+- Lowered the priority of the "soft_motor task below the "dbCaLink"task. This + fixes the "DMOV processing before the last DRBV update" problem.
-
- - Backlash occurring when the motor is moving in the same direction as the sign of - BDST. -
-- - DVAL and RBV becoming out-of-synch. RBV would always be an old value from - the previous move. -
-
- 1. GAIN - Closed loop position response gain of the motor.
- 2. CNEN - Enable/disable closed loop position control request.
- 3. STEN - Closed loop position control status (i.e.,
- enabled/disabled).
-
-Currently, servo support is only available with OMS's VME58 device support (i.e., -VME58-[4S/8S/2S2/2S6/4S4/6S2] model boards). At driver initialization, the -driver automatically detects whether or not the underlying device supports the -use of the GAIN field and thereby classifies the motor as a stepper or a servo. -Bit#11 of the MSTA field is set on/off based on the results of this test. -If the device supports the GAIN field, then bit#11 of the MSTA is set on and all -of the above servo fields are enabled. Otherwise, they are disabled -and bit#11 of the MSTA is set off. When the servo fields are disabled, -they can still be read or written to without an error response. -
- --The VME58 device support allows the closed loop position gain of the motor to be -set directly through the GAIN field. For the VME58, setting the GAIN field -value results in the Combined Coefficient command (i.e., KK#) being executed -with the GAIN field value as the argument to the command. This command, in -turn, sets the PID loop parameter values (with the OMS VME58, gain changes do -not take effect until the command velocity is zero). -
- -
-The user can request that the closed loop position control be enabled or
-disabled by setting the CNEN field nonzero or zero, respectively.
-Likewise, the user can monitor the state of closed loop position control (i.e.,
-enabled/disabled) by reading the STEN field. See the OMS "VME58 Family
-User's Manual" for further details.
-
- 1. INIT - Sent at record initialization.
- 2. PREM - Sent before every command string that causes motion.
- 3. POST - Sent after a complete motion is finished.
-
-No error checking is done by the motor record or the device driver to insure
-that the command strings are valid. Command primitives that result in a
-response from the motion control board are valid, but the response is not
-processed.
-
-
-
+ Bug Fix for Array Holes in VMEbus based controllers
++ For VMEbus based motor controllers only (i.e., OMS), a hole in an array of + VME based motor controller boards caused the system to crash with a memory access + error on the address of the missing controller. For example, if oms58Setup(3, + 8, 0x4000, 190, 5, 10) was issued without a board at 0xFFFF5000, a bus error would + occur if the user attempted to move a motor on the missing board. +
++ This release allows holes in an array of VMEbus based motor controllers. +
++ RES Field +
++ With previous releases of the motor record, the RES field was set to either ERES + or MRES, based on whether or not the following statement was true; MSTA indicates + an encoder is present, AND, UEIP is set to YES. This state (i.e., MSTA indicates + an encoder is present, AND, UEIP is set to YES) resulted in the record converting + all position and velocity related values from EGU's to raw encoder counts before + sending them to the motor controller. This is the manner in which the OMS + controllers work (see OMS User's Manual, ER# command). +
+
+ With this release, all raw positions, velocity and acceleration are in terms of
+ motor steps. The RES field is preserved for backward compatibility only. With
+ this release, the RES field is always equal to MRES.
+
+
+ Previous motor record releases put both the "slew" and backlash correction moves + on the same motor controller command line. Some controllers (i.e., OMS) handled + this correctly by processing the slew move followed by the backlash correction move. + Other controllers (i.e, Newport) did not handle this correctly and processed the + commands immediately, resulting in the controller moving to the target position + without backlash correction, but at the backlash correction velocity.
++ With this release, backlash correction commands are not issued to the controller + until after the slew move is completed.
++ The MSTA field has been modified by providing separate +/- limit switch status bits. + The MSTA bits are defined as follows:
++++
+- DIRECTION: (0:Negative, 1:Positive)
+- DONE: motion is complete.
+- PLUS_LS: plus limit switch has been hit.
+- HOMELS: state of the home limit switch.
+- Unused
+- POSITION: closed-loop position control is enabled.
+- Unused
+- HOME: if at home position.
+- PRESENT: encoder is present.
+- PROBLEM: driver stopped polling.
+- MOVING: non-zero velocity present.
+- GAIN_SUPPORT: motor supports closed-loop position control.
+- COMM_ERR: Controller communication error.
+- MINUS_LS: minus limit switch has been hit.
+
+
+
++ New Features +
++ Advanced Control Systems and Mclennan device driver support +
++ Mark Rivers has added device driver support for the following motor controllers: +
++ Disable Travel Limits
++ The travel limits can be disabled by setting both dial high and low limits equal + to zero; i.e., DHLM = DLLM = 0. +
++ RVAL ignored error +
++ A problem was discovered with entering target positions through RVAL. 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. This error occured on releases + as far back as V3.4. +
++ Jog velocity and acceleration parameters
++ Two new fields (JVEL and JAR) were added to support jog velocity and acceleration + parameters. These fields are only supported with Oregon Micro Systems, Inc + device driver support. The JVEL field allows the user to change the jog velocity + of the motor on-the-fly. +
++ This release of the motor record is strictly a bug fix release; no new features + have been added.
++ STOP field hangs record +
++ An error was introduced into the motor record with the release of V4.2 (see README + file item #14 under V4.2 ). This error occurred if the STOP field was activated + when the motor was not moving (i.e., MIP = 0). The motor record would become + "stuck", and not respond to a move request (due to the internal state machine associated + with IP being set to the "stop" state), until the condition was cleared by either + a SPMG-stop or some other user action that forced the MIP field to zero. +
++ HIDEOS support removed +
+
+ HIDEOS is no longer supported. MPF is the only supported alternative to HIDEOS.
+
+
+
+ This release of the motor record is compatible with EPICS R3.13.2 and above.
+
+ !WARNING!
+
+ motorRecord.dbd has been modified. This requires you to 'rebuild' any and
+ all user trees (i.e., <ioctop>) that load the motor record (see README item
+ #20 for details).
+
+
+
+
+
+ Precedence between field pairs
++ At boot-up, if one field of a field pair (i.e., VMAX/SMAX, VBAS/SBAS, VELO/S, BVEL/SBAK) + is zero and the other field is nonzero, the nonzero field takes precedence. + If both fields of a given field pair are nonzero, the RPS member of the field pair + (i.e., SMAX, SBAS, S, SBAK) takes precedence. This requirement was lost with + the release of V4.0. +
++ Moving Off a Limit Switch with a Oms58 device +
++ An error occurs with the OMS VME58 when the user runs the motor into a limit switch + and then attempts to move away from the limit switch. If either an absolute + or incremental move is utilized to move away from the limit switch, the OMS VME58 + ignores the 1st move attempt. Subsequent moves work. In addition, the + user can jog off a limit switch. This error was hidden in most applications + if RTRY was nonzero. +
++ Separate motion commands for target and backlash moves +
++ The record level support assumed that the motor controller would accept two motion + commands on the same command line. This occurs when backlash compensation + is enabled. Since the IM483[PL/SM] controller does not have this capability, + support for a command line "record separator" character was added. The record + separator is defined as an ASCII (IS2) character = /x1E. Currently, only one + record separator is allowed in a command line. +
++ Errors introduced in V4.0 +
++ Unfortunately, several errors were introduced into the motor record with V4.0. + The following have been fixed: +
++ Newport PM500 device support
++ Device driver support for the Newport PM500 is available for this release of the + motor record. This device/driver is based on Mark River's PM500 V2.0 release. +
++ Intelligent Motion Systems, Inc. IM483 device support +
+
+ Device driver support for Intelligent Motion Systems (IMS) IM483[I/IE] is available
+ with this release. Two different device/drivers are available for the same
+ motor controller. The two device/drivers, IM483PL and IM483SM, correspond
+ to the two available IM483 communication modes, party line and single mode,
+ respectively (see the IMS Software Reference Manual for details).
+
+
+
+ Although the motor record software in this release is compatible with EPICS baseR3.13.1.1 + and above, the directory structure, the "make" files and the configuration files + are intended for the "unbundled" architecture of EPICS R3.13.2 and above.
++ Several errors in the OMS VME58 driver were found. All the errors caused the + same problem. Namely, erroneous retries occurred intermittently when multiple + axes were commanded to move on the same controller. This error occurred because + old position data was being passed back from the driver after Done was detected. + The erroneous intermittent retries occurred more often when the Oms setup parameters + called for a high frequency (e.g., 60 Hz) "polling" rate and OMS board interrupts + were enabled.
+
+ A problem with issuing a stop command (via either the STOP or SPMG field) was found
+ with all OMS boards and all versions of the OMS device drivers.
+ The root cause of this problem is a statement in the OMS manual that is not entirely
+ correct; the AC and VL commands are not completely queued.
+
+
+
+
+
+ Release 4.0 of the motor record is only compatible with EPICS baseR3.13.1.1 and + above. This document describes changes made to the motor record and its' associated + device driver support between versions 3.5 and 4.0.
++ Since the GAIN field is redundant (i.e., PID parameters can be set individually) + it has been removed.
++ Previous releases of the motor record had a potential problem associated with the + homing function. The motorx_all.adl V1.9 MEDM display sets the HOM[F/R] fields + on and off, corresponding to the user pressing and releasing the respective home + button. Depending on the pollRate defined in the st.cmd Setup + command and the speed at which the user toggled the HOM[F/R] buttons; the record + level software would turn off the DMOV field when the HOM[F/R] button was turned + off and a motor status update had not yet been received. As a result, when + the motor completed it's homing function the command positions (i.e., VAL, DVAL, + RVAL) were not updated.
+
+ All previous motor record releases contained the DMOV problem; the commanded position
+ update problem was limited to the previous release (V3.5). With this release,
+ a dbPutField to either HOMF or HOMR is valid on a FALSE to TRUE transition (i.e.,
+ 0 to 1), but a TRUE to FALSE transition (i.e., 1 to 0) will result in an error.
+ motorx_all.adl_V2.2 (which is included with this distribution) sets the HOM[F/R]
+ fields on when the user presses the homing button, but is does not set it
+ off when the button is released. The motor record clears the HOM[F/R] field
+ when the homing operation is done (i.e., completed or terminated).
+
+
+
+ If both the auto restore and controller target position values are non-zero at boot-up, + then DVAL will be initialized from the controller's value. In other words, + the controller's target position takes precedence over the autorestore value when + both systems have non-zero DVAL values. As before, it is assumed that a zero + target position from autorestore or the controller at boot-up are default values, + and hence, they are ignored in favor of a non-zero value.
+
+ Previous releases of the motor record allowed the auto restore to take precedence
+ over the controller when initializing the target position (i.e., DVAL).
+
+
+
+ In order to support the new VMAX/SMAX fields, the Access Security Level for the + following fields have been changed from one to zero:
++++
+- MRES
+- UREV
+- VBAS
+- SBAS
+
+ Although the previous motor record release (V3.5) had device driver support for + the MM4000, it is not recommended for use with either the MM4000 or the MM4005 + controllers. The following changes were made to the previous release to create, + what is now, the MM4000/5 device driver support:
++ Through an odd set of circumstances the Oms58 driver was not performing status updates + on PowerPC (PPC) platforms. All users of the OMS VME58 controller on a PPC + platform must upgrade to Motor Record version 4.0 for full functionality.
++ Newport MM3000 Device Support
++ Device driver support for the MM3000 exist for this release of the motor record. + Note the following differences between the MM4000 and MM3000 device drivers: +
++ With previous release, if the Oms or Oms58 driver was some how omitted from the + database, a "... card does not exist" error message would result. With this + release, an explicit error check and corresponding error message (i.e., "Oms[58] + driver uninitialized. ") is issued at record initialization if a required driver + is not initialized. (Because of the particulars of MM[3000/4000] initialization, + this is not an issue with Newport controllers.)
++ Maximum velocity fields have been added; VMAX in EGU/s units and SMAX in RPS units.
++ In order to support BURT, range checking is done in such a way that any minimum + (i.e., VBAS/SBAS) or maximum (i.e., VMAX/SMAX) value entered is valid. For + example, if the minimum is entered and it exceeds the maximum, then the maximum + is set to the new minimum value. Slew (VELO/S) and backup velocity (BVEL/SBAK) + fields are forced by the motor record to be within the range set by VMAX/SMAX and + VBAS/SBAS, inclusively. For example, if VELO is entered and it is less than + the minimum, then VELO is set to VBAS. +
++ To facilitate software upgrades, a zero VMAX disables maximum velocity error checking. + Those who use both BURT and VMAX (i.e., nonzero VMAX) should insure that VMAX and + VBAS are placed before VELO and BVEL in their BURT request files. VMAX/SMAX + have Access Security Level zero. +
+
+ motorx_setup_1.7.adl (which is included with this distribution) includes
+ support for the maximum velocity fields.
+
+
+
+ Release 3.5 of the motor record is only compatible with EPICS baseR3.13.1.1 and + above. This document describes changes made to the motor record and its' associated + device driver support between versions 3.4 and 3.5. Those changes are as follows:
++ This feature is available only with OMS VME8/44/58 or Newport MM4000 device support + (i.e., devOms, devOms58, devMM4000). Three motor record fields are available + to the user to send ASCII command primitives to the servo control board at fixed, + predefined, times. Each of the following fields is defined as a character + string:
++++ 1. INIT - Sent at record initialization. +
+
+++ 2. PREM - Sent before every command string that causes motion. +
+
+++ 3. POST - Sent after a complete motion is finished or when an overtravel limit switch + is detected. +
+
+ No error checking is done by the motor record or the device driver to insure that + the command strings are valid. Command primitives that result in a response + from the motion control board are valid, but the response is not processed.
++ The following unused motor record fields were deleted: MODE, TRAK, MDEL, ADEL, CVEL, + POSM, ALST, MLST
++ Device directive definition and processing:
++ + User I/O #0 <> X axis +
++ + " " 1 <> Y " +
++ + ..................... +
++ + " " 7 <> S "
++ The immediate goals for soft channel motor record device support were twofold. + First, to solve the problem of nonlinear position conversion in the data base, rather + than in the record. Second, to provide a more flexible motor record interface + for Table Records and SPEC.
+
+ New fields have been added to the motor record to support the Soft Channel device
+ driver. The new fields are all database links associated with existing
+ motor record fields. The new links and their associated fields are listed
+ in the table below:
+
+
+
+
+
| + Link | ++ Link Type | ++ Associated Field | +
| + OUT* | ++ DBOUTPUT | +
+
+ DVAL
+
+ |
+
| + STOO | ++ DBOUTPUT | ++ STOP | +
| + DINP | ++ DBINPUT | ++ DMOV | +
| + RDBL* | ++ DBINPUT | +
+
+ DRBV
+
+ |
+
| + RINP | ++ DBINPUT | +
+
+ RMP
+
+ |
+
+ * - Not a new field, but a new function provided only by soft channel device support. +
++ The Soft Channel database links are only processed when the Soft Channel device + driver is selected. These links are ignored when using any other Motor Record + device driver. At this time, the above links are not dynamically retargetable. +
+
+ The OUT, DINP and RDBL are monitored for value changes via a CA event task.
+ Users must choose either a dial input link (RDBL) or a raw input link (RINP), but
+ not both.
+
+
+
+
+
+ This is Mark Rivers MM4000
+ device support ported to the latest motor record release. The following are
+ the functional differences between Mark's version 1.01 and
+ this release:
+++
+- When either user or dial travel limit values are entered, a validity check is + made using the travel limit values from the MM4000 control. User and dial + travel limit values are valid if they are within the travel limits set on the front + panel of the MM4000 controller. Attempting to enter a travel limit outside + the MM4000 controller's range results in the travel limit being reset to the MM4000's + value.
+- Servo support has been extended to the MM4000 controller.
+
+ With this release there are two ways to set the motor controllers' PID parameters; + either through the Combined Gain field (i.e., GAIN) or through the individual + PID gain parameter fields (i.e., PCOF, ICOF, DCOF). Let the motor controller + PID parameters be represented by CKP, CKI and CKD; then the relationship between + these two methods is as follows:
++++ For the MM4000 For all OMS controllers +
+
+ Note that setting any of the individual PID record fields is notreflected + in the value of the GAIN field.
++ Device support for the Highland V544 is available with this release. This + version (i.e., version 1.3) is functionally the same as the earlier release (i.e., + version 1.2). No new features have been added. +
++ This document describes changes made to the motor record and its' associated device + driver support between versions 3.3 and 3.4. Those changes are as follows:
++ A design error was discovered in the OMS device drivers (drvOms and drvOms58). + The EPICS device driver support task (i.e., tmotor) would query the OMS motion controller + for status information immediately after a motion command. Since the state + of the controller board was in the midst of changing, this sometimes resulted in + inconsistent or conflicting status information being returned to the motor record. + This problem was remedied by enforcing a minimum time delay (16.67 ms) between a + motion command and a status query.
++ It is difficult to enumerate the symptoms associated with this problem. Sometimes + they exhibited themselves intermittently, other times bad data stayed in the record. + Several symptoms are as follows: +
++++
+- Erroneous motor stops being issued by the device support when changing motor direction. +
+- Backlash occurring when the motor is moving in the same direction as the sign + of BDST.
+- DVAL and RBV becoming out-of-synch. RBV would always be an old value from + the previous move.
+
+ The motor record classifies a motor as a servo if it has two features; an adjustable + closed loop position response gain and the ability to enable/disable closed loop + position control (i.e., motor torque). A motor lacking either of the above + two features is classified as a stepper and is supported by the standard motor record + features. The following three motor record fields support servo motors:
+
+ 1. GAIN - Closed loop position response gain of the motor.
+
+ 2. CNEN - Enable/disable closed loop position control request.
+
+ 3. STEN - Closed loop position control status (i.e.,
+
+ enabled/disabled).
+
+ Currently, servo support is only available with OMS's VME58 device support (i.e., + VME58-[4S/8S/2S2/2S6/4S4/6S2] model boards). At driver initialization, the + driver automatically detects whether or not the underlying device supports the use + of the GAIN field and thereby classifies the motor as a stepper or a servo. + Bit#11 of the MSTA field is set on/off based on the results of this test. + If the device supports the GAIN field, then bit#11 of the MSTA is set on and all + of the above servo fields are enabled. Otherwise, they are disabled + and bit#11 of the MSTA is set off. When the servo fields are disabled, they + can still be read or written to without an error response. +
++ The VME58 device support allows the closed loop position gain of the motor to be + set directly through the GAIN field. For the VME58, setting the GAIN field + value results in the Combined Coefficient command (i.e., KK#) being executed with + the GAIN field value as the argument to the command. This command, in turn, + sets the PID loop parameter values (with the OMS VME58, gain changes do not take + effect until the command velocity is zero). +
+
+ The user can request that the closed loop position control be enabled or disabled
+ by setting the CNEN field nonzero or zero, respectively.
+
+ Likewise, the user can monitor the state of closed loop position control (i.e.,
+ enabled/disabled) by reading the STEN field. See the OMS "VME58 Family User's
+ Manual" for further details.
+
+ Three motor record fields are available to the user that can be used to send ASCII + command primitives to the servo control board at fixed, predefined, times. + Each field is defined as a character string.
+
+ 1. INIT - Sent at record initialization.
+
+ 2. PREM - Sent before every command string that causes motion.
+
+ 3. POST - Sent after a complete motion is finished.
+
+ No error checking is done by the motor record or the device driver to insure that + the command strings are valid. Command primitives that result in a response + from the motion control board are valid, but the response is not processed. +