1 / 8

Motor drivers for asyn motor device support

Motor drivers for asyn motor device support. Mark Rivers GeoSoilEnviroCARS, Advanced Photon Source University of Chicago. Problems with existing support. Complex Device and driver support need to be written for each new controller

nydia
Télécharger la présentation

Motor drivers for asyn motor device support

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Motor drivers for asyn motor device support Mark Rivers GeoSoilEnviroCARS, Advanced Photon Source University of Chicago

  2. Problems with existing support • Complex • Device and driver support need to be written for each new controller • Interaction of common (device-independent) device and driver support vs device-dependent code is not clear • One thread per controller type, not per controller • Multiple serial controllers of same type block each other • I/O is driven by device support, not atomic • Conflicts if other software talks to controller simultaneously • No way to have other records communicate with the driver • Can’t exploit controller-specific features that motor record does not know about • Non-standard interface between device and driver support

  3. Current Status • Working drivers for Newport XPS and MM4005 controllers done at APS. Delta Tau PMAC done at Diamond. • Continuing to refine the API, devMotorAsyn, drvMotorAsyn based on this experience

  4. Newport XPS • Architecture and features • Ethernet TCP/IP socket interface • Can drive steppers, DC, wide variety • Lot of auxilliary I/O. 48 bits of digital I/O, 4 A/D, 4 D/A • vxWorks on Intel internally • TCL/Tk interpreter • No good device/driver support using “old” model • Success in using asyn generic device support to set parameters not supported by motor record • Success in using asyn generic device support to read fields with I/O Intr scanning • Will be doing coordinated motion soon • Probably first outside of new API using SNL program • Then extend API to handle coordinated motion

  5. Newport XPS – Auxilliary I/O • Done on separate sockets • Uses asyn generic device support • Rapid polling, I/O Intr scanned record

  6. Newport XPS • Generic device support to read readback, and control jerk times • Uses asynInterposeInterface for asynDrvUser interface grecord(ao,"$(P)$(R)MIN_JERK_TIME") { field(DESC,"Min jerk time") field(PREC,"3") field(VAL,".01") field(DTYP, "asynFloat64") field(OUT,"@asyn($(PORT))MIN_JERK_TIME") } grecord(ao,"$(P)$(R)MAX_JERK_TIME") { field(DESC,"Max jerk time") field(PREC,"3") field(VAL,".03") field(DTYP, "asynFloat64") field(OUT,"@asyn($(PORT))MAX_JERK_TIME") } grecord(ai,"$(P)$(R)READBACK") { field(DESC,"Readback") field(PREC,"4") field(DTYP, "asynFloat64") field(SCAN, "I/O Intr") field(INP,"@asyn($(PORT))POSITION") }

  7. Newport MM4005 • Simpler than XPS. Serial or GPIB • Converted in about 1 day • Now can have EPICS interface to features motor record does not support • Already have coordinated motion (“trajectory scanning”) with SPEC macros to use it • Re-do this as a standard API in the future • Given MM4005 support should be less than a day each to convert other serial drivers to asyn device support

  8. Summary • 2-3 times fewer lines of code • 2-3 times fewer files • New features and flexibility • Path forward to take advantage of new controller features • Plan motor record enhancements/fixes after new asyn interface matures

More Related