Re: EPICS support for Fastech motors

[Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>]

Hi Rea,

Thanks for sharing that repository, that is very helpful.

I think I found the correct manual for your controller here:

https://fastech.co.kr/new/board/bbs/download_product_en.php?bo_table=sub010208_en&wr_id=0

I looked at EzS2PEAxis::move.  I see that it is building a binary structure and sending that to the controller with pC_->writeReadController().

However, I think I see an error in your code. Everywhere you define boiler[] similar to this:

    unsigned char boiler[] = {HEADER, 8, pC_->syncCounter, 0x00, SET_PARAMETER, param};

https://github.com/redomitro/motorFastech/blob/94b93b150501490cf9cf7ef77d4d4e3a6b0ad62f/fastechApp/src/EzS2PE_Driver.cpp#L146

However, the manual says the frame header is this:

① Header : 0xAA, Displays that the beginning of Frame

② Length : Length of Data after Length

    (Sync No. + Reserved + Frame type + Data)

③ Reserved : 1 byte Input as “ 0x00

④ Sync No. : The Sync number of the packet is used to c heck whether the command is executed

    in the drive module. The value should change every time when you send a new command.

⑤ Frame type : Specify the command type of the Frame. The types are listed below.

    Refer to  Frametypeand Data configuration 」

⑥ Data : The data structure and length of this clause are determined by the Frame type.

    The detailed structure refers to [Frametypeand Data configuration]  section below.

Note that the Reserved 0x00 byte is defined in the manual to come between the Length and the Sync Number byte.  But your code has the 0x00 after the Sync Number.  This seems wrong.

The communication is UDP based.  Once you fix the error above I suspect that write operations will succeed. 

However, I think that read operations will fail because you have created the L0 UDP port with the default value of noProcessEos=0.  This means that the UDP driver is doing EOS processing.  Although you have not defined input or output terminators, another thing that the EOS processing does is wait for the requested number of bytes to be received.  Since you have no way of knowing how many bytes will be received you need to request more than you will receive, and the read will time out. 

The solution is to change your startup script to this:

drvAsynIPPortConfigure("L0", "192.168.0.204:3001 UDP", 0, 0, 1)

That sets noProcessEos to 1.  That means that the driver will not wait for the requested number of characters but will return as soon as any characters are received, or after a timeout.

Cheers,

Mark

---

From: Rea Domitrović <rea.domitrovic at irb.hr>
Sent: Friday, June 26, 2026 8:44 AM
To: Mark Rivers <rivers at cars.uchicago.edu>; tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: EPICS support for Fastech motors

Hi Mark,

the source code is here: https://github.com/redomitro/motorFastech - the repository should be public. Thank you again for the help; it's the end of the week here so I'll dig into the debugging more come Monday. Best,

Rea

---

From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: Friday, June 26, 2026 3:15:45 PM
To: Rea Domitrović; tech-talk at aps.anl.gov
Subject: Re: EPICS support for Fastech motors

 

Hi Rea,

• Is it even possible to use the Model 3 framework to communicate with something that uses such a specific and non-standard byte stream, or will I have to find a different way? Kind regards,

Yes, definitely.  You can use the Model 3 framework to communicate with any type of motor controller API: ASCII strings, vendor library calls, Modbus, etc. 

The issue is the motorAxis->move() function that you have implemented in your derived class.  It is returning the error status -1.  You need to figure out why.  Is your code on a repository where we can see it?  If not can you share the code, or at least the code for the axis->move() function?

Here are 2 suggestions for debugging this:

• Enable asynTraceIODriver and ASYN_TRACEIO_ESCAPE for the underlying asyn communication port.  That will let you see the complete communication with the device.  Put these lines in your startup script right after you create the asyn communication port, which I have called $(PORT) here:

asynSetTraceMask($(PORT), 0, ERROR|DRIVER)

asynSetTraceIOMask($(PORT), 0, ESCAPE)

• Put debugging printf or asynPrint statements in your driver to see what is happening.

Mark

---

From: Rea Domitrović <rea.domitrovic at irb.hr>
Sent: Friday, June 26, 2026 2:50 AM
To: Mark Rivers <rivers at cars.uchicago.edu>; tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: EPICS support for Fastech motors

 

Hi Mark,

thanks for taking the time. I followed the debug instructions you gave here: https://epics.anl.gov/tech-talk/2017/msg00282.php - thanks for clarifying what is actually needed.

I suspect this message is what's wrong, i.e. the writes are not actually getting through to the motor:

2026/06/26 09:39:45.144 asynMotorController:writeFloat64 error, status=1 axis=0, function=1, value=-150000.000000
2026/06/26 09:39:45.148 devMotorAsyn::asynCallback: EXIT:zpos pasyn{Float64,Int32}->write returned

To me, it smells like the problem is in the fact the motor doesn't use ASCII-compatible strings to communicate - every message has to start with a five-byte header of the following structure: 0xAA, length, idempotence counter, 0x00, frame type. That null byte is presumably making communication difficult; that is why everywhere in the source code I used memcpy instead of sprintf to build the outString. A test IOC made with StreamDevice instead of Motor confirms the motor is responsive to that kind of communication; I was able to turn the servo on and poll it for position using StreamDevice, but not actually move it.

Is it even possible to use the Model 3 framework to communicate with something that uses such a specific and non-standard byte stream, or will I have to find a different way? Kind regards,

Rea

---

From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: Thursday, June 25, 2026 4:35:51 PM
To: tech-talk at aps.anl.gov; Rea Domitrović
Subject: Re: EPICS support for Fastech motors

 

H Rea,

You have set the asynTraceMask to enable lots of debugging.  That is OK, but it makes it hard to see the real errors from warning and informational messages.  For example these messages are printed with ASYN_TRACE_FLOW, they are not really errors.

2026/06/25 15:29:48.311 asynPortDriver:getDoubleParam: port=motorExit error getting parameter 9 MOTOR_ENCODER_POSITION, in list 0, value undefined
2026/06/25 15:29:48.311 asynPortDriver:getDoubleParam: port=motorExit error getting parameter 5 MOTOR_VELOCITY, in list 0, value undefined

This message

2026/06/25 15:07:46.444 asynMotorController:writeFloat64: Set driver motorExit, axis 0 move absolute to 0.000000, base velocity=500.000000, velocity=25000.000000, acceleration=245000.000000

is being printed here.  It is just an informational message.

https://github.com/epics-modules/motor/blob/f3d089bae20d04f8b9ed18fcfdc55274075d6a42/motorApp/MotorSrc/asynMotorController.cpp#L328

However, this message:

2026/06/25 15:07:46.445 asynMotorController:writeFloat64 error, status=1 axis=0, function=1, value=0.000000

is being printed here:

https://github.com/epics-modules/motor/blob/f3d089bae20d04f8b9ed18fcfdc55274075d6a42/motorApp/MotorSrc/asynMotorController.cpp#L428

Function=1 is a move absolute command, so it is consistent with the first message.  status=1 means that your driver's pAxis->move() function returned -1.  It was called from here:

https://github.com/epics-modules/motor/blob/f3d089bae20d04f8b9ed18fcfdc55274075d6a42/motorApp/MotorSrc/asynMotorController.cpp#L324-L325

If you set your asynTrace flags to ERROR|WARNING you will only see the more important messages.

Mark

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Rea Domitrović via Tech-talk <tech-talk at aps.anl.gov>
Sent: Thursday, June 25, 2026 8:53 AM
To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: EPICS support for Fastech motors

 

Hi all,

thanks so much for pointing me in the right direction so far. I've got to the point where I've got the structure of a driver based on the MCB4B driver and with inspiration from the SmarAct driver; however, at runtime, I'm getting errors that I'm struggling to diagnose. If someone could help me understand, I would be most grateful. Relevant info is below. Best,

Rea Domitrović

Institut Ruđer Bošković

Zagreb, Croatia

Source code is here: https://github.com/redomitro/motorFastech

IOCinit output:

2026/06/25 15:29:48.311 asynPortDriver:drvUserCreate: drvInfo=MOTOR_MOVE_REL, index=0
2026/06/25 15:29:48.311 asynPortDriver:drvUserCreate: drvInfo=MOTOR_MOVE_ABS, index=1
2026/06/25 15:29:48.311 asynPortDriver:drvUserCreate: drvInfo=MOTOR_MOVE_VEL, index=2
2026/06/25 15:29:48.311 asynPortDriver:drvUserCreate: drvInfo=MOTOR_HOME, index=3
2026/06/25 15:29:48.311 asynPortDriver:drvUserCreate: drvInfo=MOTOR_STOP_AXIS, index=4
2026/06/25 15:29:48.311 asynPortDriver:drvUserCreate: drvInfo=MOTOR_VELOCITY, index=5
2026/06/25 15:29:48.311 asynPortDriver:drvUserCreate: drvInfo=MOTOR_VEL_BASE, index=6
2026/06/25 15:29:48.311 asynPortDriver:drvUserCreate: drvInfo=MOTOR_ACCEL, index=7
2026/06/25 15:29:48.311 asynPortDriver:drvUserCreate: drvInfo=MOTOR_POSITION, index=8
2026/06/25 15:29:48.311 asynPortDriver:drvUserCreate: drvInfo=MOTOR_RESOLUTION, index=12
2026/06/25 15:29:48.311 asynPortDriver:drvUserCreate: drvInfo=MOTOR_ENCODER_RATIO, index=13
2026/06/25 15:29:48.311 asynPortDriver:drvUserCreate: drvInfo=MOTOR_PGAIN, index=14
2026/06/25 15:29:48.311 asynPortDriver:drvUserCreate: drvInfo=MOTOR_IGAIN, index=15
2026/06/25 15:29:48.311 asynPortDriver:drvUserCreate: drvInfo=MOTOR_DGAIN, index=16
2026/06/25 15:29:48.311 asynPortDriver:drvUserCreate: drvInfo=MOTOR_HIGH_LIMIT, index=17
2026/06/25 15:29:48.311 asynPortDriver:drvUserCreate: drvInfo=MOTOR_LOW_LIMIT, index=18
2026/06/25 15:29:48.311 asynPortDriver:drvUserCreate: drvInfo=MOTOR_CLOSED_LOOP, index=19
2026/06/25 15:29:48.311 asynPortDriver:drvUserCreate: drvInfo=MOTOR_STATUS, index=25
2026/06/25 15:29:48.311 asynPortDriver:drvUserCreate: drvInfo=MOTOR_UPDATE_STATUS, index=26
2026/06/25 15:29:48.311 motorExit 0 registerInterruptUser
2026/06/25 15:29:48.311 asynPortDriver:getDoubleParam: port=motorExit error getting parameter 9 MOTOR_ENCODER_POSITION, in list 0, value undefined
2026/06/25 15:29:48.311 asynPortDriver:getDoubleParam: port=motorExit error getting parameter 5 MOTOR_VELOCITY, in list 0, value undefined
2026/06/25 15:29:48.311 asynMotorController:readGenericPointer: MotorStatus = status34, position=425203751.000000, encoder position=0.000000, velocity=0.000000
2026/06/25 15:29:48.311 motorExit asynManager::queueLockPort locking port
2026/06/25 15:29:48.311 motorExit asynManager::queueLockPort created queueLockPortPvt=0x561069c8f7a0
2026/06/25 15:29:48.311 motorExit asynManager::queueLockPort created queueLockPortPvt=0x561069c8f7a0, event=0x561069c979e0, mutex=0x561069c97990
2026/06/25 15:29:48.311 motorExit asynManager::queueLockPort taking mutex 0x561069c97990
2026/06/25 15:29:48.311 motorExit asynManager::queueLockPort queueing request
2026/06/25 15:29:48.311 motorExit addr 0 queueRequest priority 0 not lockHolder
2026/06/25 15:29:48.311 motorExit schedule queueRequest timeout in 2.000000 seconds
2026/06/25 15:29:48.311 motorExit asynManager::queueLockPort waiting for event
2026/06/25 15:29:48.312 motorExit 0 autoConnect
2026/06/25 15:29:48.312 asynPortDriver:connect:, pasynUser=0x561069c83188
2026/06/25 15:29:48.312 asynManager::portThread port=motorExit callback
2026/06/25 15:29:48.312 motorExit asynManager::queueLockPortCallback signaling begin event
2026/06/25 15:29:48.312 motorExit asynManager::queueLockPortCallback waiting for mutex from queueUnlockPort
2026/06/25 15:29:48.312 motorExit asynManager::queueLockPort got event from callback
2026/06/25 15:29:48.312 EXIT:zpos devMotorAsyn::statusCallback new value=[p:425203751.000000,e:0.000000,s:22]
2026/06/25 15:29:48.312 asynMotorController:writeFloat64: Set driver motorExit, axis 0 encoder ratio=1.000000
2026/06/25 15:29:48.312 asynMotorController:writeFloat64:: axis=0, function=13, value=1.000000
2026/06/25 15:29:48.312 asynFloat64SyncIO wrote: 1.000000e+00
2026/06/25 15:29:48.312 motorExit queueUnlockPort
2026/06/25 15:29:48.312 motorExit asynManager::queueUnlockPort waiting for event
2026/06/25 15:29:48.313 motorExit queueUnlockPort unlock mutex 0x561069c97990 complete.
2026/06/25 15:29:48.313 devMotorAsyn::init_controller, EXIT:zpos set encoder ratio to 1.000000
2026/06/25 15:29:48.313 devMotorAsyn::init_controller, EXIT:zpos setting of position not required, position=425203751.000000, mres=0.000200, dval=0.000000, rdbd=0.0002002026/06/25 15:29:48.313 EXIT:zpos devMotorAsyn::update_values, needUpdate=1
2026/06/25 15:29:48.313 devMotorAsyn::build_trans: EXIT:zpos motor_cmnd=19, pact=0, value=375000.000000
2026/06/25 15:29:48.313 devAsynMotor::build_trans: calling queueRequest, pmsg=0x561069c97c40, sizeof(*pmsg)=24pmsg->command=14, pmsg->interface=1, pmsg->dvalue=375000.000000
2026/06/25 15:29:48.313 motorExit addr 0 queueRequest priority 0 not lockHolder
2026/06/25 15:29:48.313 devMotorAsyn::build_trans: EXIT:zpos motor_cmnd=20, pact=0, value=-375000.000000
2026/06/25 15:29:48.313 devAsynMotor::build_trans: calling queueRequest, pmsg=0x561069c97c90, sizeof(*pmsg)=24pmsg->command=15, pmsg->interface=1, pmsg->dvalue=-375000.000000
2026/06/25 15:29:48.313 motorExit addr 0 queueRequest priority 0 not lockHolder
2026/06/25 15:29:48.313 asynManager::portThread port=motorExit callback
2026/06/25 15:29:48.313 devMotorAsyn::asynCallback: EXIT:zpos pmsg=0x561069c97c40, sizeof(*pmsg)=24, pmsg->command=14,pmsg->interface=1, pmsg->ivalue=0, pmsg->dvalue=375000.000000, pasynUser->reason=17
2026/06/25 15:29:48.313 asynMotorController:writeFloat64: Set driver motorExit, axis 0 high limit=375000.000000
2026/06/25 15:29:48.313 asynMotorController:writeFloat64:: axis=0, function=17, value=375000.000000
2026/06/25 15:29:48.313 asynManager::portThread port=motorExit callback
2026/06/25 15:29:48.313 devMotorAsyn::asynCallback: EXIT:zpos pmsg=0x561069c97c90, sizeof(*pmsg)=24, pmsg->command=15,pmsg->interface=1, pmsg->ivalue=0, pmsg->dvalue=-375000.000000, pasynUser->reason=18
2026/06/25 15:29:48.313 asynMotorController:writeFloat64: Set driver motorExit, axis 0 low limit=-375000.000000
2026/06/25 15:29:48.313 asynMotorController:writeFloat64:: axis=0, function=18, value=-375000.000000

Output when attempting to caput absolute position:

2026/06/25 15:07:44.438 192.168.0.204:3001 UDP write 3
\xaa\v\a
2026/06/25 15:07:46.444 asynMotorController:writeFloat64: Set driver motorExit, axis 0 move absolute to 0.000000, ba                                                                                                                        se velocity=500.000000, velocity=25000.000000, acceleration=245000.000000
2026/06/25 15:07:46.445 asynMotorController:writeFloat64 error, status=1 axis=0, function=1, value=0.000000
2026/06/25 15:07:46.445 devMotorAsyn::asynCallback: EXIT:zpos pasyn{Float64,Int32}->write returned
2026/06/25 15:07:46.445 EXIT:zpos devMotorAsyn::update_values, needUpdate=1

---

From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: Wednesday, June 17, 2026 21:07
To: Torsten Bögershausen; tech-talk at aps.anl.gov; Rea Domitrović
Subject: Re: EPICS support for Fastech motors

 

Hi Rea,

•  I see that driver developers prefer to use octet-based communication rather than use the manufacturer-provided libraries. Is there a reason why that is the case, or is it simply that octet-based communicaton is more universal?

Manufacturer libraries will be provided for specific operating system and specific versions of those OS. That can restrict where they can be deployed.  They may restrict redistribution, which prevents including them in the motor Github repository.  They almost certainly won't be supported on real-time OS like RTEMS or vxWorks.

• Further, the Fastech controller allows both octet-based communication and library-based communication, but octet-based communication requires the master to send a one-byte "sync number" which serves as an idempotence token. I assume it would be necessary to implement that myself; could I be using some sort of global variable, and how do I make sure that I never land on the same number twice in a row?

Many protocols have something like that.  You just have a member variable in your driver class that increments by 1 on each message it sends, and wraps back to 0 after 255.

Mark

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Rea Domitrović via Tech-talk <tech-talk at aps.anl.gov>
Sent: Wednesday, June 17, 2026 8:34 AM
To: Torsten Bögershausen <tboegi at edom.se>; tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: EPICS support for Fastech motors

Hi Torsten,

thanks for pointing me in the right direction. I'm looking at the manual and the source for other submodules now (motorSmarAct and motorAcs); I see that driver developers prefer to use octet-based communication rather than use the manufacturer-provided libraries. Is there a reason why that is the case, or is it simply that octet-based communicaton is more universal?

Further, the Fastech controller allows both octet-based communication and library-based communication, but octet-based communication requires the master to send a one-byte "sync number" which serves as an idempotence token. I assume it would be necessary to implement that myself; could I be using some sort of global variable, and how do I make sure that I never land on the same number twice in a row? Kind regards,

Rea

---

From: Torsten Bögershausen <tboegi at edom.se>
Sent: Wednesday, June 10, 2026 1:49:41 PM
To: Rea Domitrović; tech-talk at aps.anl.gov
Subject: Re: EPICS support for Fastech motors

 

Hej Rea,

I haven't worked with them, no.
If you have Ethernet (not to be confused with EtherCAT),
I read the manual as if they use UDP for communication,
and knowing that you can write a simple model 3 driver, I think.
(Other suggestions are welcome of course)
/Torsten


On 2026-06-10 12:52, Rea Domitrović via Tech-talk wrote:
> Hi all,
>
>
> I'm working with some Fastech Ezi-Servo II Plus-E motors, and I was
> wondering if someone had already worked with them and/or made an EPICS
> driver or Motor submodule? This particular line of motors and
> drives uses an Ethernet interface. Kind regards,
>
>
> Rea Domitrović
>
> Institut Ruđer Bošković
>
> Zagreb, Croatia
>

Oprez: Ova poruka stigla je od vanjskog pošiljatelja. Prije otvaranja poveznica ili privitaka provjerite pošiljatelja. Caution:This email originated from an external sender. Please verify the sender before opening links or attachments.

Oprez: Ova poruka stigla je od vanjskog pošiljatelja. Prije otvaranja poveznica ili privitaka provjerite pošiljatelja. Caution:This email originated from an external sender. Please verify the sender before opening links or attachments.

Oprez: Ova poruka stigla je od vanjskog pošiljatelja. Prije otvaranja poveznica ili privitaka provjerite pošiljatelja. Caution:This email originated from an external sender. Please verify the sender before opening links or attachments.

Oprez: Ova poruka stigla je od vanjskog pošiljatelja. Prije otvaranja poveznica ili privitaka provjerite pošiljatelja. Caution:This email originated from an external sender. Please verify the sender before opening links or attachments.