Experimental Physics and
| |||||||||||||||
|
Hi Mark, Yes, I agree with the introduction of PROFILE_MOVE_MODE. I've still to convert the Galil driver to use this, as it still has GALIL_PROFILE_MOVE_MODE which I put in prior to the release of motorR6-9. Functionally, I think it's identical. After re-reading some of the motor record code, I agree with you. It appears motor doesn't call device support when those fields change. Also, I believe you kindly showed me how to get this information in the driver using CP links. It may not be clean, but it works ok. With PREM, and POST, I also typically used it to turn amplifiers on before move, and off afterward. I've since introduced an auto amplifier on/off feature with independent on and off delay times. Since that time, I've maintained PREM/POST capability in the driver, but I don't know anybody using it. I've not had a chance to provide feedback to you on the profile move architecture as a whole, so I thought I should mention it worked well with the Galil. Also, I found it easy to treat coordinate system motors just as real motors. The real motors are effectively channel 0-7, and the cs one's are 8-15. The Controller poller calls Controller::poll, Axis::poll and finally CSAxis::poll each cycle. Inside CSAxis.cpp is where the forward and reverse transforms happen using the scalc engine. When a CSAxis wants to move, it uses the "deferred moves" facility. For the CSAxis the developer can use any coordinated move mode on the controller they wish, I choose linear interpolation mode. I thought this solution may be of interest to the group, as it's rather consistent with the model 3 architecture. I've included some screenshots, to illustrate some of the other attributes that would be useful in the future. In the end, I think there are many new attributes that would be useful. Best wishes, Mark _______________________________________ From: Mark Rivers [[email protected]] Sent: Thursday, 4 June 2015 22:21 To: Mark Clift; [email protected]; [email protected]; [email protected]; [email protected] ([email protected]) Subject: RE: Draft requirements document for enhanced EPICS motor support Hi Mark, > Also, profile move modes relative, and absolute should be included too. That is present, it is a parameter called "PROFILE_MOVE_MODE" and this enum: enum ProfileMoveMode{ PROFILE_MOVE_MODE_ABSOLUTE, PROFILE_MOVE_MODE_RELATIVE }; It was added in SVN commit 17443, so it is present from R6-8-1 onwards. The XPS profile move now implements it. > Also, It is not the motor record that is the cause of some of the missing fields in model 3 (eg. DIR, POST), > but rather the asyn interface that’s been defined for it. I'm not sure that is true. The problem is that the motor record does not call device support when those fields change. So if I want to be sure that the values in the driver are up-to-date with the record how do I do that? I can do it by defining additional records that have a CP link to those motor fields, and have those records push the value to the driver, but that is not clean. Mark ________________________________ From: Mark Clift [[email protected]] Sent: Thursday, May 28, 2015 5:30 AM To: Mark Rivers; [email protected]; [email protected]; [email protected]; [email protected] ([email protected]) Subject: RE: Draft requirements document for enhanced EPICS motor support Dear All, I too find the motor record interface has been a consistent element that we can build on, and that it has served well. Recently, I added a motor driver for Galil products to the EPICS module support page, and this software has many of the features involved in this discussion. Whilst developing this model 3 software, I found it was possible to implement most, if not all, of these high end features. The issues I found with model 3 were: - Lack of output compare architecture - Lack of coordinate system selection architecture - Certain motor record parameters are needed in the driver, and they not present in the asyn interface to the motor record, or are not initialized early enough . eg. DIR, PREM, POST, OFF - (Work-arounds exists for the above) - No clear defined way to implement pseudo motors, virtual motors, coordinate system motors. (eg. Slit width) I did successfully implement: profile motion, coordinate system motors (eg. Slit width), output compare facility, coordinate system selection facility using the model 3. I was not able to implement coordinate motion across multiple 8 axis controllers (eg. 16 motor profile move). With a Delta Tau, this does look possible. Given that the current model 3 seems capable, I am not certain the effort is justified yet. With a thin layer motor record, the software above the record would not break. Model 3 drivers below the state machine would also be easy to adapt, and would in most cases reduce driver code complexity. Would the model 1 interface still be supported? Also, It is not the motor record that is the cause of some of the missing fields in model 3 (eg. DIR, POST), but rather the asyn interface that’s been defined for it. Using model 3, It’s possible to build pseudo motors, or coordinate system motors as I call them in the following way: The coordinate system mechanism is built on top of the “Deferred moves” mechanism. The usual <Controller>Axis.cpp was adapted for coordinate motors and became <Controller>CSAxis.cpp. The CSAxis.cpp contains coordinate transform methods that use the scalc engine. Using asynParamList, I added kinematics to the database in the following way: 8 forward equations per controller. Which means there is 1 forward equation per CS motor as 8 CS motors are supported per 8 axis controller (eg. I=(A+B)/2) 8 reverse equations per CS Motor that represent real motors A-H. Which means 64 reverse equations per controller in total as there are 8 CS motors (eg. A=I-J/2) The engineer can change the kinematics at runtime. Above the CS motors is the motor record, so the CS motors look and feel real. When the user moves a CS motor the system selects a free coordinate system, puts the controller in “deferred” moves mode, gives the motors the set points via transform, then releases deferred moves. It happens all very fast, and you can tweak the CS back and forth using JOGF, JOGR, etc. The coordinate system on the hardware is released at the end of the move and again becomes free. I found the profile motion architecture in model 3, that has been defined based on the Newport XPS-C8, works well for the Galil controllers too. This structure will also work for the Delta Tau PMAC2 (eg. GBLV). The mutex locking in the profile execution code is a little painful, but that’s life when the system is running a lengthy profile, as the user may want to move independent motors. Perhaps model 3 just needs a few minor additions, for output compare, and coordinate system selection for manual “deferred” moves ? Also, I’d like to see profile execution mode added with the base choices being: linear, and pvt. Linear and pvt would require different methods to actually run the profile. Also, profile move modes relative, and absolute should be included too. Best wishes, Mark Clift. Dr. Mark Clift Senior Controls Engineer Australian Synchrotron 800 Blackburn Road Clayton 3168 Ph: +613 8540 4264 Fax: +613 8540 4200 Mail: [email protected]<mailto:[email protected]> Attachment:
galil_csmotor_kinematics.png Attachment:
galil_ctrl_extras.png Attachment:
galil_motor_extras.png Attachment:
galil_ProfileMove.png Attachment:
profileMove_StripTool.png
| ||||||||||||||
ANJ, 16 Dec 2015 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |