Re: Support for piezo controller nanoFAKTUR EBD-060310

[Lutz Rossa via Tech-talk <tech-talk at aps.anl.gov>]

Hallo LiangChih Chiang,

You should create you own C++ classes and extend "asynMotorController"
and "asynMotorAxis". You could look into existing code, the EPICS motor
record knows many working implementations for other devices.
You should override some of the functions, at least "poll", "move",
"moveVelocity", "home" and "stop", but as needed other functions too.
The functions should not wait for any move to finish, the "poll"
function is called in regular intervals to check for status and more.

1. The mentioned "int" is not the position, its the asyn index used
   for the "setDoubleParam" call of the underlying asynMotorController
   class, that it maps the position correctly. Do not forget to call
   "callParamCallbacks" after any of the "set...Param" functions.

2. This depends, what unit do you want to control. Often the users
   would control the position, which would make more sense. You could
   make additional PVs to provide the actual voltage too.

3. If you use "setDoubleParam" together with "motorPosition_", you can
   use the whole range of the data type.

4. In your own class, which extends "asynMotorAxis", you should override
   "poll". Read the actual positions and some status information of the
   device and use "setDoubleParam" or "setIntegerParam". Write to the
   pointered flag, if this axis is active (which influences the cycle
   time for polling) and call "callParamCallbacks" before returning.

5. From my point of view, the closed-loop mode fits good for controlling
   the position, but you might implement other modes too. Please look
   into other controller implementations.

The parameter indexed by "motorEncoderPosition_" should be written with
the actual encoder position. The parameter indexed by "motorPosition_"
is for the actual motor position for a system, which makes a difference
between motor and encoder. If there is none, use could write the encoder
position here.

A binary protocol is no problem for asyn, variants (text or binary)
exist in the world.

Best regards,
Lutz

Am 06.02.26 um 08:48 schrieb LiangChih Chiang via Tech-talk:
> Hello, EPICS mates,
>
> I started to implement the “Model 3” driver for nanoFaktur EBD-060310 
> piezo controller.
> The attached files(.cpp and .h) are the work-in-progress source code. 
> Not finished yet.
> I have some questions.
>
> 1.
> In asynMotorController.h, the data type of motorPosition_ 
> and motorEncoderPosition_ are ints.
> But in derived class of asynMotorcontroller(like 
> smarActMCSMotorDriver.cpp and ACRMotorDriver.cpp),
> the function setDoubleParam is used to set the above parameters.
>
> Why is that?
>
> 2.
> I can read the position(unit um, range 0 to 40) and voltage(unit volts, 
> range -30 to 130) from the controller.
> But which one should I set to motorPosition_and motorEncoderPosition_?
> I don't quite understand.
>
> 3.
> The values of position and voltage from the controller are float values.
> When setting, say 2.123456, to motorEncoderPosition, it will become 2 
> (which is an int).
> How to handle this situation?
> Should I do some kind of transformation? For example, multiply by 1000,000?
>
> 4.
> In the member function: asynStatus poll(bool* moving_p),
> I need to set the moving/done status of the stage to moving_p 
> and motorStatusDone_.
> But there is no such exact suitable command provided by thhe controller.
> A possible candidate is "get on-target status" meaning in closed-loop 
> mode(servo ON),
> whether the position(from sensor) approached the set target or not.
>
> 5.
> The controller has two modes:
> closed-loop mode(servo ON), users set the desired potion(unit um).
> open-loop mode(servo OFF), uses set the voltage(unit volts).
>
> What should I set to motorPosition_?
> I think it should be something like "motor pulse".
>
> what should I set to motorEncoderPosition_.?
> I think it should be something like "encoder value".
>
>
> ps
>
> The controller uses binary communication protocol.
> The following example is to read the position(in um) of channel 0:
> hexadecimal bytes in little-endian:
> 10 00 01 20 02 00 20 00 00 ac 01 00 00 00 00 fe
>
> 10 00: total length, 16 bytes
> 01 20: command ID, 0x2001 means "get position"
> 02 00: custom ID, used to distinguish different client programs.
> 20: option, 0x20 means "read"
> 00: sequence number, Used in very long responses. Not used in commands.
> 00: interface id, RS-232 or USB or Ethernet. Not used in commands.
> ac: header checksum
> 01: data format, 01 means 32-bit unsigned int
> 00 00 00 00: data, channel 0
> fe: checksum
>
> The  response:
> 13 00 01 20 02 00 10 00 01 b8 00 00 02 70 74 6a 3e
>
> 13 00: total length, 19 bytes
> 01 20: command ID, 0x2001 means "get position"
> 02 00: custom ID, used to distinguish different client programs.
> 10: option, 0x10 means "final, no more".
> 00: sequence number,
> 01: interface id, 0x01 means RS-232.
> b8: header checksum
> 00: data format, 00 means 8-bit unsigned int
> 00: data, channel 0
> 02: data format, 02 means float
> 70 74 6a 3e: data, 0.228960 (position in um)
> 3e: checksum
>
>
> Any suggestions and responses are appreciated.
> Thank you.
>
>
> On Thu, Apr 24, 2025 at 5:31 AM Mark Rivers <rivers at cars.uchicago.edu 
> <mailto:rivers at cars.uchicago.edu>> wrote:
>       * I think I would need to write the EPICS motor driver module for
>         it.____
>
>     __ __
>
>     That is correct.  You should write a “Model 3” driver, meaning it is
>     a C++ driver derived from the base classes asynMotorController and
>     asynMotorAxis.____
>
>     __ __
>
>     I just looked at the manual for the nanoFAKTUR EBD-060310.  It uses
>     a non-standard binary communications protocol, not ASCII strings. 
>     That is unusual, most controllers use ASCII communication.____
>     __ __
>
>     The driver you suggested as a model,
>     https://github.com/epics-motor/motorPIGCS2
>     <https://urldefense.us/v3/__https:/github.com/epics-motor/motorPIGCS2__;!!G_uCfscf7eWS!YgABnMrr4ouWf_GcXAuVe7LU-96lfvWFNG96utdBA3mgcrk9dBsWVY7JQtxclFMQQYwD2Zz0RmrbQGad8OJXFPc$>  is fairly complex because of the class hierarchy, so you might want to start with something simpler as your example. ____
>
>     __ __
>
>     https://github.com/epics-motor/motorSmarAct/blob/master/smarActApp/src/smarActMCSMotorDriver.cpp <https://urldefense.us/v3/__https://github.com/epics-motor/motorSmarAct/blob/master/smarActApp/src/smarActMCSMotorDriver.cpp__;!!G_uCfscf7eWS!YLctRUSDiyz4K-t8_BzT33ew7q6EOnMR2oSaoEqf7fY5hpd5mII4cyq4pP6Gt3vwMPp1s38VSS7kXyY4shD2qrU$>____
>
>     __ __
>
>     That uses ASCII communication, but it should not be too hard to take
>     the concepts and use binary communication.____
>
>     __ __
>
>     Mark____
>
>     __ __
>
>     __ __
>
>     __ __
>
>     __ __
>
>     __ __
>
>     *From:*Tech-talk <tech-talk-bounces at aps.anl.gov
>     <mailto:tech-talk-bounces at aps.anl.gov>> *On Behalf Of *LiangChih
>     Chiang via Tech-talk
>     *Sent:* Wednesday, April 23, 2025 1:41 AM
>     *To:* tech-talk at aps.anl.gov <mailto:tech-talk at aps.anl.gov>
>     *Subject:* Support for piezo controller nanoFAKTUR EBD-060310____
>
>     __ __
>
>     Hello, EPICS mates,____
>
>     __ __
>
>     I need to control a piezo sage with the controller nanoFAKTUR
>     EBD-060310.____
>
>     This is my first time using this controller.____
>
>     I searched and couldn't find the EPICS support module for it.____
>
>     __ __
>
>     I think I would need to write the EPICS motor driver module for it.____
>
>     __ __
>
>     What module code would you recommend me to use as a starter
>     reference?____
>
>     For example, something like ____
>
>     EPICS motor drivers for Physik Instrumente GCS2 (General Command
>     Set) compatible controllers____
>
>     https://github.com/epics-motor/motorPIGCS2
>     <https://urldefense.us/v3/__https:/github.com/epics-motor/motorPIGCS2__;!!G_uCfscf7eWS!YgABnMrr4ouWf_GcXAuVe7LU-96lfvWFNG96utdBA3mgcrk9dBsWVY7JQtxclFMQQYwD2Zz0RmrbQGad8OJXFPc$> ____
>
>     __ __
>
>     __ __

Attachment: smime.p7s
Description: Kryptografische S/MIME-Signatur