Perhaps the most used type of macro is the scan macros. In general terms, we call scan to a macro that moves one or more motors and acquires data along the path of the motor(s).
Note
Sardana provides a Scan Framework for developing scan macros so that the scan macros behave in a consistent way. Unless otherwise specified, the following discussion applies to scan macros based on such framework.
The various scan macros mostly differ in how many motors are moved and the definition of their paths.
Typically, the selection of which data is going to be acquired depends on the active measurement group and is not fixed by the macro itself (although there is no limitation in this sense).
Depending on whether the motors are stopped before acquiring the data or not, we can classify the scan macros in step scans or continuous scans, respectively.
Trend plot showing a step scan (ascan m_cp1_1 0 1000 8 .5) followed by a continuous scan (ascanc m_cp1_1 0 1000 .5). The line corresponds to the motor position and the blue shaded areas correspond to the intervals in which the data acquisition took place.
In a step scan, the motors are moved to given points, and once they reach each point they stop. Then, one or more channels are acquired for a certain amount of time, and only when the data acquisition is finished, the motors proceed to the next point.
In this way, the position associated to a data readout is well known and does not change during the acquisition time.
Some examples of step scan macros are: ascan, a2scan, ... dscan, d2scan, ... mesh.
In a continuous scan, the motors are not stopped for acquisition, which therefore takes place while the motors are moving. The most common reason for using this type of scan is optimizing the acquisition time by not having to wait for motors to accelerate and decelerate between acquisitions.
Note
The synchronization of movement and acquisition can be done via hardware or via software. Currently Sardana only provides an interface for software-synchronized continuous scans. An API abstracting the specificities of hardware-synchronized systems is being implemented too but it is not yet available for production.
The (software-synchronized) continuous scans introduce some constraints and issues that should be considered.
In order to address the first two issues, the scan framework attempts the following:
These two actions can be seen in the following plot of the positions of the two motors involved in a a2scanc.
Trend plot showing a two-motor continuous scan (a2scanc m_cp1_1 100 200 m_cp1_2 0 500 .1). The lines correspond to the motor positions and the blue shaded areas correspond to the intervals in which the data acquisition took place.
Both motors are capable of same velocity and acceleration, but since the required scan path for m_cp1_1 is shorter than that for m_cp1_2, its top velocity has been adjusted (gentler slope for m_cp1_1) so that both motors go through the user-requested start and stop positions simultaneously.
The same figure also shows how the paths for both motors have been automatically (and transparently, for the user) extended to guarantee that the user defined path is followed at constant velocity and that the data acquisition takes place also while the motors are running at constant velocity.
Some examples of continuous scan macros are: ascanc, a2scanc, ... dscanc, d2scanc, ... meshc.
See also
For more information about the implementation details of the scan macros in Sardana, see scan framework