Hej LiangChih Chiang,
thanks for asking.
Before going into your questions, please allow one comment:
Using epicsPrintf (or even printf) should be forbidden in
these kind of driver code.
Please consider to us asynPrint instead.
Especially things like
#ifdef DEBUG
printf("Warning: un-handled param data format:
#endif
Could be better coded as
asynPrint(this->pasynUserSelf, ASYN_TRACE_ERROR,
"%s: Warning....\n",
__FUNCTION__);
}
(If you write Warning or Err: or something is more a matter of taste)
But in any way you want to know if things go bad much later,
after firmware updates, changes in the IOC, glitches here and the )
Having said that, finishing my review, which may read unintentionally
hard, lets digg into the questions.
1.
> In asynMotorController.h, the data type of motorPosition_
> and motorEncoderPosition_ are ints.
A call inside the axis class looks like this:
asynMotorAxis::setDoubleParam(pC_->motorPosition_, motorPosition);
pC_->motorPosition_ is an int,
saying which asynparameter we ar writing to.
motorPosition is a double, saying where the motor should be,
according to the controller.
motorEncoderPosition_ is the value coming from the sensor inside the
controller.
Example:
the MCS2 from Smaract reads motorPosition like this:
// Read the target position
snprintf(pC_->outString_,sizeof(pC_->outString_)-1,
":CHAN%d:POS:TARG?", axisNo_);
And encoderPosition like this:
// read the actual position as measured by the sensor
snprintf(pC_->outString_,sizeof(pC_->outString_)-1,
":CHAN%d:POS?", axisNo_);
3.
> The values of position and voltage from the controller are float values.
> When setting, say 2.1234...
This is depending on MRES in the motorRecord.
If you set it to 1.0 (or not at all, the the fallback is 1.0)
all values are rounded into integer.
The trick is to set MRES to 0.000001 or so and compensate
this in the driver (multipy with 1000000)
For the open-loop-voltage:
You probably want an own asyn-parameter for this.
/BR Torsten
On 2026-02-06 08:48, LiangChih Chiang via Tech-talk wrote:
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://urldefense.us/v3/__https://github.com/epics-motor/__;!!G_uCfscf7eWS!YNTu8W7mOOCA7i52E_eC8rbycrSF2Xg4TAoHeHp4o8cW8OxPEK0p3xRGwyU-ieXrfSiPucbZ8i-B99Ma_fI$
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://urldefense.us/v3/__https://github.com/epics-motor/motorSmarAct/blob/master/smarActApp/__;!!G_uCfscf7eWS!YNTu8W7mOOCA7i52E_eC8rbycrSF2Xg4TAoHeHp4o8cW8OxPEK0p3xRGwyU-ieXrfSiPucbZ8i-BJ49xEJ0$
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://urldefense.us/v3/__https://github.com/epics-motor/motorPIGCS2__;!!G_uCfscf7eWS!YNTu8W7mOOCA7i52E_eC8rbycrSF2Xg4TAoHeHp4o8cW8OxPEK0p3xRGwyU-ieXrfSiPucbZ8i-BKUbMHR0$ <https://urldefense.us/
v3/__https://urldefense.us/v3/__https://github.com/epics-motor/motorPIGCS2__;!!G_uCfscf7eWS!__;!!G_uCfscf7eWS!YNTu8W7mOOCA7i52E_eC8rbycrSF2Xg4TAoHeHp4o8cW8OxPEK0p3xRGwyU-ieXrfSiPucbZ8i-B0-8TfjQ$
YgABnMrr4ouWf_GcXAuVe7LU-96lfvWFNG96utdBA3mgcrk9dBsWVY7JQtxclFMQQYwD2Zz0RmrbQGad8OJXFPc$> ____
__ __
__ __
- Replies:
- Re: Support for piezo controller nanoFAKTUR EBD-060310 LiangChih Chiang via Tech-talk
- References:
- Re: Support for piezo controller nanoFAKTUR EBD-060310 LiangChih Chiang via Tech-talk
- Navigate by Date:
- Prev:
Re: EPICS support for Micro4 controller from World Precision Instruments Heinz Junkes (FHI) via Tech-talk
- Next:
Re: EPICS support for Micro4 controller from World Precision Instruments Neuman, Urszula (DLSLtd, RAL, CEO) via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
<2026>
- Navigate by Thread:
- Prev:
Re: Support for piezo controller nanoFAKTUR EBD-060310 Lutz Rossa via Tech-talk
- Next:
Re: Support for piezo controller nanoFAKTUR EBD-060310 LiangChih Chiang via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
<2026>
|