I can reproduce this behavior using the SSCAN record to increment the RVAL field, rather than a script.
This is the configuration of the SSCAN record. It is incrementing RVAL by 1, with 101 points.

I monitor the time for the scan to complete with the EXSC field (1=scanning, 0=done)
If 13BMD:m29.VELO is 1.15 (920 steps/s) I see this when I do the scan twice
(base) [epics@corvette motor]$ camonitor -tc 13BMD:scan1.EXSC
13BMD:scan1.EXSC (2024-12-31 11:09:31.621315) 1
13BMD:scan1.EXSC (2024-12-31 11:09:35.525949) 0
13BMD:scan1.EXSC (2024-12-31 11:09:36.679780) 1
13BMD:scan1.EXSC (2024-12-31 11:09:40.585258) 0
It takes 3.9 seconds to complete each scan, about 25 points/s.
If 13BMD:m29.VELO is 1.16 (928 steps/s) I see this:
13BMD:scan1.EXSC (2024-12-31 11:09:59.694063) 1
13BMD:scan1.EXSC (2024-12-31 11:10:47.235558) 0
13BMD:scan1.EXSC (2024-12-31 11:10:54.149164) 1
13BMD:scan1.EXSC (2024-12-31 11:11:40.231517) 0
It takes 47 seconds to complete the scan, about 2 points/s.
So incrementing VELO from 1.15 to 1.16 increases the scan time by more than a factor of 10. Very strange, since in single-step mode the VELO field should be irrelevant.
Mark
From: Mark Rivers
Sent: Monday, December 30, 2024 1:37 PM
To: tech-talk at aps.anl.gov
Subject: Strange behavior with single stepping a motor with Galil controller
Folks,
I am seeing a very strange behavior when execute a set of single-step motor record moves from a script.
Configuration:
- EPICS base 7.0.7
- EPICS motor record, R7-3-1
- Galil DMC-4183 motor controller
- Galil driver V4-0-02
- Open-loop stepper motor with MRES=.00125
- Backlash distance BDST = 0.
I have a script that repeatedly moves the motor in single steps by incrementing or decrementing the motor record RVAL field by 1.
The script writes to the RVAL field with ca_put_callback, so it returns as soon as the move is complete, and then starts the next move.
In principle these moves should be independent of the motor record VELO and ACCL fields, since it is only moving a single step.
I observe the behavior by monitoring the done moving (DMOV) field, which is 0 when the motor is moving and 1 when a move is complete.
If I set the VELO field to 1.0 (800 steps/s) this is the camonitor result.
(base) [epics@corvette motor]$ camonitor -tc 13BMD:m29.DMOV
13BMD:m29.DMOV (2024-12-30 13:17:55.364647) 1
13BMD:m29.DMOV (2024-12-30 13:17:55.364896) 0
13BMD:m29.DMOV (2024-12-30 13:17:55.403801) 1
13BMD:m29.DMOV (2024-12-30 13:17:55.404055) 0
13BMD:m29.DMOV (2024-12-30 13:17:55.442796) 1
13BMD:m29.DMOV (2024-12-30 13:17:55.443167) 0
13BMD:m29.DMOV (2024-12-30 13:17:55.481823) 1
13BMD:m29.DMOV (2024-12-30 13:17:55.482166) 0
13BMD:m29.DMOV (2024-12-30 13:17:55.521032) 1
The time to go from 1(done) to 0 (moving) is less than 1 ms. This is the time after motion done callback for the script to begin the next move.
The time to go from 0 (moving) to 1 (done) is about 40 ms. This is the time for the driver to send Ethernet command to the controller to begin the motion, for the move
to complete, and for the driver to get the completion status from the controller, and to issue the CA monitors.
These timings make sense to me.
However, if I increase the VELO field from 1.0 to 1.5 (1200 steps/s) then this is the camonitor result:
(base) [epics@corvette motor]$ camonitor -tc 13BMD:m29.DMOV
13BMD:m29.DMOV (2024-12-30 13:26:33.994636) 1
13BMD:m29.DMOV (2024-12-30 13:26:33.995166) 0
13BMD:m29.DMOV (2024-12-30 13:26:34.502491) 1
13BMD:m29.DMOV (2024-12-30 13:26:34.502939) 0
13BMD:m29.DMOV (2024-12-30 13:26:35.010406) 1
13BMD:m29.DMOV (2024-12-30 13:26:35.010706) 0
13BMD:m29.DMOV (2024-12-30 13:26:35.518281) 1
13BMD:m29.DMOV (2024-12-30 13:26:35.518503) 0
13BMD:m29.DMOV (2024-12-30 13:26:36.026216) 1
13BMD:m29.DMOV (2024-12-30 13:26:36.026736) 0
The 1 to 0 time is still less than 1 ms.
But the 0 to 1 time is now about 508 ms. It has increased by more than a factor of 12 compared to the 40 ms when VELO=1.0.
This makes no sense to me. Why does changing the VELO field affect the time for a single-step move?
Is this a problem with the motor record, or with the Galil driver?
Thanks,
Mark