[New Feature] NI interfuse: no support for uncalibrated, bare voltages

[qku]

Feature Description

It should be possible to use the NI scanning probe interfuse without a calibration of the scanner axes to meters.

Related Problem

The scanning probe interface can be used in other scenarios than a confocal scanner. A laser frequency is usually scanned in bare volts as calibration is much more difficult here due to mode hops etc.

Considered Alternatives

It is possible to just set the "position_ranges" to the full voltage range of the underlying NI IO and AO modules in the config option. This mimics the intended goal but is not clean as the unit in the constraints is still 'm'.

Additional Context

I am working on this and considering to post this as a separate PR (not combined with the other scanning probe toolchain changes).

Contact Details

No response

[qku]

@timoML @LukePiewalker After considering that the NI interfuse was never intended to be used for something else than moving physical scan hardware, do we even want this integrated?

I could also imagine to write a separate hardware module for what I want for PLE: scanning bare voltages, moving directly and not with a slowed down speed, etc. The scanner for confocal could potentially even inherit from such a simpler module.

[Neverhorst]

As far as I recall, the existing scanning hardware module utilizes NIXSeriesFiniteSamplingIO with the FiniteSamplingIOInterface to perform the voltage scanning with data acquisition. Is that not exactly what you need @qku ? Or do you want this but without the data acquisition part?

[LukePiewalker]

I think @qku does mean it with respect to the interfuse, if position_ranges is not there. Because right now the ScannerAxis unit ('m') is hardcoded in the interfuse and _position_ranges is a mandatory parameter.

Having "uncalibrated" axis, so basically just voltage instead of meter using the Ni interfuse, would hence translate to making _position_ranges optional and using voltage, when it is not specified. That would make sense. However, that would need probably also some additional checks when setting up the scan data and translating back and forth from position to voltages.

Most general would be, if each axis is handled separately can have different units / translation to voltages and also bare voltages etc. are handled accordingly. That is in principle the idea, yet the first implementation I did is rather dirty, I agree 😞

[qku]

@Neverhorst I guess my logic for PLE could also be based directly on the finite IO interface, yes. The scanning probe interfuse adds a lot of convenience functionality though which I thought would be useful. I do need data acquisition.

I am now considering to write a separate interfuse which connects to the finite IO, something like a "PLE scanner". Especially because I want to add extra functionality later which is interesting for PLE but not at all for confocal scanning.

@LukePiewalker I do have an implementation ready though for supporting bare voltages in the current NI interfuse. I could open a draft PR.

[qku]

@Neverhorst @LukePiewalker here is a design question to you: why did you decide to create the ScanningProbeInterface and the NI interfuse instead of directly connecting with a logic to the FSIO and AO? Because there is complete scanning probe hardware out there which can directly satisfy the ScanningProbeInterface?

Should I connect directly to a FSIO hardware if my logic is very specific to FSIO? I think it would be useful to have an intermediate logic between a FSIO hardware and a main logic in many cases. I wonder when it makes sense to create this middle layer as an interface plus interfuse, and when a logic module is better.

[Neverhorst]

@Neverhorst @LukePiewalker here is a design question to you: why did you decide to create the ScanningProbeInterface and the NI interfuse instead of directly connecting with a logic to the FSIO and AO? Because there is complete scanning probe hardware out there which can directly satisfy the ScanningProbeInterface?

You answered it mostly yourself. Giving out analog voltages (or any other "physical output") per pixel is something that narrows down the scanning hardware quite a lot. The ConfocalLogic in the old qudi repository worked like this, more or less. This has been the main reason to re-design the scanning probe toolchain. There are a lot of scanning probe systems out there in labs where you have no full per-pixel control over the hardware. Or you want to combine several scanners into one... there are a lot of use cases.

So we got a ton of user feedback (mainly why they can not use the ConfocalLogic) in the past and decided the ScanningProbeInterface should be fairly general and "high-level". The two extremes for a hardware module that implements this interface would be:

• A commercial confocal microscope system with an API that acquires an image as a configurable "black box" (Very lightweight hardware module implementation)
• The typical colorcenter use case where you send analog voltages to a nano-positioner. (Very heavy hardware module implementation with interfuses and several "low-level interfaces")

Should I connect directly to a FSIO hardware if my logic is very specific to FSIO? I think it would be useful to have an intermediate logic between a FSIO hardware and a main logic in many cases. I wonder when it makes sense to create this middle layer as an interface plus interfuse, and when a logic module is better.

The answer to this is certainly not binary. It depends... I would say, if the sole purpose of this intermediate logic is to structure the code and enable other (not yet developed) toolchains to reuse it in the future, then go for interfuse. If this logic is actually orchestrating an experiment on its own, it should be a logic module. In the end it does not matter much from a code perspective. It just decides where this module lives in the package structure of qudi.