RE: How to support a new stepper motor controller?

[Mark Rivers <rivers@cars.uchicago.edu>]

I have been communicating with Paramveer Jain about this for several weeks.  I have suggested that he use the model 3 driver, and pointed him to the simplest one I know of, the ACRMotorDriver.cpp to use as a model.  He only has to implement about 6 functions to get a working driver, changing the ACR syntax to the syntax for his controller.

Mark

________________________________________
From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of Pete Jemian [jemian@anl.gov]
Sent: Tuesday, February 07, 2017 9:28 AM
To: tech-talk@aps.anl.gov
Subject: Re: How to support a new stepper motor controller?

This is possible, to make a new device support independent of other
motor support and has been demonstrated previously.

But I suggest supprting this controller using the asyn motor 3, as
previously described.  By supporting a new motor controller within the
motor record, the new controller becomes available to additional tools
that meet the motor record API.  First off are the tools in the IOC that
report how many motors in this IOC are in motion and provides a single
PV to STOP ALL motors in this IOC.  These features come for "free" (as
in no additional work necessary) and are valuable in the management of a
facility with many IOCs providing motor records.  Then there are the
many client tools that operate motors: the sscan record, SPEC, BlueSky,
PyEpics, just to name a few.

Pete



On 02/07/2017 08:45 AM, Maren Purves wrote:
> Coming from the EPICS of 20 years ago, I still would do the same
> only with more modern drivers/device support (we're still using
> drvAscii, drvSerial, tnetIo from when we implemented ours):
>
> it's just a device on a serial line, it an be controlled with analogout-s
> or stringout-s, and similar for input, strings being put together or
> split apart in gensub-s/asub-s.
>
> Being faced with a similar problem, what is/are today's serial line
> on terminal server/CMS drivers of choice?
>
> Maren
>
> On Mon, Feb 6, 2017 at 11:53 PM, Ralph Lange <ralph.lange@gmx.de
> <mailto:ralph.lange@gmx.de>> wrote:
>
>     Dear motion specialists,
>
>     I am writing on behalf of Paramveer Jain (in CC) who has contacted
>     me with this issue, but as I have never done motion control
>     integration with EPICS, I'd rather throw this ball up than send him
>     into the wrong direction.
>
>     He is being tasked with developing EPICS support for a locally
>     developed motor controller.
>
>     The hardware setup can be summarized as:
>
>       * Moxa embedded TCP-to-serial converter (NE4110S)
>       * Serial connection (RS-232)
>       * Homemade motor controller (based on an AT89C52)
>       * Ark Motion AMS 3630 stepper motor driver.
>
>     The controller software talks ASCII in command/response fashion, e.g.:
>
>       * Read position (rotary encoder)
>         Command: STX U <CR>
>         Response: STX U pppppp <CR>
>         pppppp = six digit hex (divide by 640 to get millimeter)
>       * Go to position (rotary encoder)
>         Command: STX P1 sss pppppp <CR>
>         Response: \06 (ACK)
>         sss = three digit hex (speed in mm/s multiplied by 240)
>         pppppp = six digit hex (millimeter multiplied by 640)
>       * ...
>
>     What's the best/easiest way to do this? What are the caveats?
>     Is there a tutorial he could follow?
>     Is there existing support for another motor that he could start from?
>
>     Thanks a lot for your help!
>     ~Ralph
>
>