Implementing ramp/speed control for actuator movement in daq_move

[malik-irain]

Hi everyone! With @seb5g, we've been thinking about a feature that could be really useful for controlling actuators in daq_move It would be great to implement a "ramp" or speed control mechanism that ensures a smooth and controllable movement between two positions.

Instead of jumping directly from one position to another, the actuator would gradually ramp to the new position while emitting and saving its position.

It would be the first step of a "fast scan" mechanism where some measures are acquired while an actuator "ramps" to its new position. Data from both sources, marked with timestamps would then be interpolated/reconstructed to be visualized.

Does anyone have specific use cases, comments or ideas related to this?

[rgeneaux]

Hi! Very interested in this. Our use case is pretty much what you mention: set up a continuous movement on a stage (rotation or sinusoidal translation for example), with the actual position being read out synchronously with another daq viewer. Then the positions are sorted into bins with user-settable size, and the viewer data averaged for each bin.

One thought is that several motors have hardware methods to produce a continuous movement e.g. on the ones I use:

• for PI piezos you can generate a movement profile with a dedicated tool, store it into the controller and apply it continuously;
• for rotation stages you have commands that set it to move at constant velocity

Are you thinking of imlementing such commands as extra methods for a daq_move? (like a "jog" method?)
Or would the feature rely on constructor hardware to set up the movement, and just deal with the "measure position together with data and then bin data" part? This already would be useful to some experiments.

[seb5g]

I already implement something along these line using PI motors and their build in "waveforms". This exists also for other such as Smaract. On simpler systems I used a constant velocity to map linearly timestamps and position. But I did this wihtin custom plugins and interplay between displacement and analog acquisition with a DAQ. It would be difficult to generalize it.

The proposal would be to implement it software wise and on the fly. But depending on the available features of actuators, it could rely on internal features (like can you set the velocity? can you perform a waveform).