Introduction of a scannable laser interface#132
Conversation
|
Dear all I drafted up something now for the laser scanning interface and wrote (very minimal) dummy modules. |
|
Really cool @LukePiewalker ! I like the idea of having the stabilization as a mixin. It should allow us to cover a large variety of lasers. |
| @dataclass(frozen=True) | ||
| class ScannableLaserConstraints: | ||
|
|
||
| scan_limits: Tuple[float, float] |
There was a problem hiding this comment.
Why not use also ScalarConstraint here? This would make things more consistent and it comes with built-in checker methods.
There was a problem hiding this comment.
Was originally intending to do so, but then got a bit confused on using two scalar constraints for such a thing with upper and lower limits.
Just went for two floats out of convenience, because I thought its easier for such a simple concept.
There was a problem hiding this comment.
We would only need a single scalar constraint here though, right? I understand the scan limits as the minimum and maximum value that the scan "position" in terms of scan units can reach. The constraint then includes the two floats for the upper and lower bound.
| scan_range: Tuple[float, float] | ||
| scan_speed: Union[int, float] | ||
| scan_mode: Union[LaserScanMode, int] | ||
| initial_scan_direction: Union[LaserScanDirection, int] |
There was a problem hiding this comment.
Personally I can't think of a situation where this is useful. May just be me though.
There was a problem hiding this comment.
Are you referring to the initial_scan_direction part only?
One could use that to change the direction during a "running scan" and therefore overscan some sub part multiple times on the fly without needing to change the scan range.
Used it that way in the lab some time already, therefore thought might be helpful.
There was a problem hiding this comment.
I see, I guess this is mostly relevant for very slow scans?
|
|
||
|
|
||
| @dataclass(frozen=True) | ||
| class ScannableLaserSettings: |
There was a problem hiding this comment.
I don't think that introducing a class for the scan settings is of advantage here. Other than in the scanning probe toolchain, we don't need to save the settings together with data, right? I would go with keyword arguments for the various parameters instead.
There was a problem hiding this comment.
Was just a fan of having things consistent. Then also one could possibly include some things such as type checking, range clipping etc in the settings class already.
3 participants
Introduction of a scannable laser interface and dummy modules, which mimic the intended functionality.
Description
This interface could be used to access scannable laser within a proper tool-chain for e.g. PLE measurements.
It consists of
ScannableLaserInterfaceand theStabilizationMixinwhere the Mixin could be used for scannable lasers which have some hardware capability to stabilize themselves.In order to also incorporate, that some lasers require some working points to be set, which can be either a simple setpoint, such as a motor/grating position, or actively controlled parameters, such as a temperature or current, multiclassing with
ProcessSetpointInterfaceandProcessControlInterfaceis used in the respective dummy module.The
ScannableLaserInterfaceincorporates non-abstract properties, to check if the laser supports the respective features.Motivation and Context
So far scannable lasers are typically only accessed by the respective interfaces the vendor provides and having them implemented in qudi could enable additional speed up and automization of measurements.
How Has This Been Tested?
No real test but Dummy modules have been introduced.
Types of changes
Checklist:
/docs/changelog.md.(syntax, indentation, mutable default values, etc.).