Hi, good morning.
I am a collaborator working for a third-party company (Setup) which is acting on the automation of beamline equipment at Sirius synchroton facility, in Campinas, Brazil
Currently, I am working with a slit device which showed oscillation problems in one of its axis. We tried to solve this issue in different ways, but one solution that was suggested to us was to drive the motor in open loop, at the motor controller level, and close the loop at EPICS level via its "move and retry" strategy, implemented by the RTRY and RDBD fields.
We were told we could implement such an approach by means of defining a virtual axis on the motor controller, which position would reflect the actual encoder reading.
So we did this on our startup script (.cmd):
In this image, axis 1 is the motor axis (which is configured in open loop), and axis 11 is the virtual motor with the encoder position associated.
Also, we setup our substitutions file as follows:
...
...
(in the images, MRES = 1/102400 mm/count)
We expected to see the following behaviour:
- Encoder initial position = e.g. 2.3mm
- We issue 3mm as the commanded position for m1
- m1 moves 0.7mm upwards, or 71680 counts
- epics compares the encoder position to the commanded position of 3mm
- if the encoder position is out of the range 2.7mm _ 3.3mm, a new movement is issued with an incremental quantity equal to the value on the DIFF field.
- The process repeats itself 100 times, or until the position is reached
However, what we observed is the following:
- Encoder initial position is at 2.3mm
- We issue 3mm as the commanded position for m1
- The motor moves until m1 position is at 307200 (that is 102400 *3), regardless of encoder (m11) position
- Encoder position is close to 2.5mm
- We can see DIFF is a positive value
- We can see RCNT is increasing slowly
- We can see that the motor controller "Inposition" flag is not active
- However, no movement is being issued, since m1 position is still at 307200, and the encoder valule is not increasing
It seems that EPICS is issuing "absolute" movements, instead of "relative". Commanded position of 3mm shouldn't result in a target of 307200 counts for motor 1, but should issue an incremental movement of 0,7mm (in this situation), or +71680 counts, and after that, the DIFF field should be considered in order to issue further movements
What can justify this behaviour? Did we implement this technique correctly?
Thank you for your attention.
![]() | Guilherme Jovanini Montagner +55 19 99806.9117 +55 19 2517.8911 |  Labview Certified Developer |
