RE: Strange behavior with single stepping a motor with Galil controller

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

I have enabled asynTrace on the command socket from the driver to the controller.  I have found that the transition from 40 ms completion time to 500 ms is a function of the following:

• VELO field in motor record
• ACCL field in motor record
• Number of steps to move

 

This table list my observations.  Success means 40 ms completion time, Fail means 500 ms.

VELO	ACCL	Steps per move	Result
1.0	.2	1	Success
1.5	.2	1	Fail
1.0	0.174	1	Success
1.0	0.173	1	Fail
1.0	0.07	2	Success
1.0	0.06	2	Fail

 

It appears to me that there may be a problem in the Galil DMC-4183 firmware when making very short moves. If the computed value of the acceleration (AC command) is greater than a certain value (that depends on the number of steps to move), then the move takes about 500 ms, rather than 40 ms.

 

I am moving this thread to this Github issue: https://github.com/motorapp/Galil/issues/35

 

Mark

 

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Mark Rivers via Tech-talk
Sent: Tuesday, December 31, 2024 11:21 AM
To: tech-talk at aps.anl.gov
Subject: RE: Strange behavior with single stepping a motor with Galil controller

 

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