integrating attocube piezo stepper stage for Z-axis, not through NI card

[seizagirre]

Hello, I'm trying to write a hardware module to communicate with an Attocube piezo controller, which will be used as the Z channel during confocal scanning. The XY are through a scanning mirror through analog channels via the NI card (so works fine), but the Attocube controller is connected via USB to the computer, not through the NI card.

If I do not put a third line in the scanner_voltage_ranges and scanner_position_ranges under config>hardware>ni_card, I get some errors (cannot find confocal logic can't find xy_image etc), but if I leave these as some dummy I can scan my sample no problem, just without any real Z control.

I wanted to ask what might be the best approach to rewriting this so that the NI card analog inputs are for X and Y but the Z can be through a separate hardware channel, and how far into the various logic files I might need to go to adapt this. I checked through the various pull requests and documentation here and on the old discussion but could not find anything to this effect, hence why I'm asking here. All suggestions welcome! Thanks :)

[LukePiewalker]

Dear @seizagirre,

thanks for posting this question here. Could you maybe be a little more specific to the errors you get?
Since only 2D scans should be supported and work.

However I'm also currently running into issues I would need to further look into however these are as far as I can see gui related. So loading the modules just on the logic side with only an x and y axis configured works for me and I do not get errors which sound related to your descriptions.
Can you maybe post the snippets of your config here such that I can see what might go wrong?

And regarding your second question, I would like to also ask for further details on what you would like to achieve:
Just 2D scans with potentially one axis being the attocube (stepper, I suppose?) or also cursor movements?

My first thought about this would be to interfuse together a 2D ni_scanning_probe with code which sends commands to your attocube control. So it would basically be another interfuse layer.

[seizagirre]

Hi @LukePiewalker thanks for your reply

I think it was a GUI error but I didn't play around with the logic too much, temporarily I fixed this by setting my third scanner AO channel to be one that I am not using, set the voltage parameters to be very low (I'm not sending any commands to it anyway) and added a 50 Ohm terminator on the DAQ. I think as you say, removing the Z axis from the logic would be the right thing to do, glad to hear that it works for you, and I will implement this soon (I was just trying to check that other aspects of my hardware were working in the meantime).

In terms of what I want to do, I simply want to use the Attocube stepper as my Z focus. I don't mind so much not being able to control the Attocube through the GUI, so having a 2D GUI with xy corresponding to the scanning mirror is fine, but I need to be able to run a Z optimiser that uses the Attocube stepper. My current approach was going to be to modify the Z optimiser to write a new function so that it sends a command to the controller than moves the stepper, instead of sending a voltage to an AO channel.

I would ideally want to run the Z optimiser function while using the automatic POI finder, hence why I want to be able to integrate it through Qudi. Perhaps I am mistaken though and it would be enough to write a purely python function (without having written a Qudi-compatible hardware class for the Attocube) that I could call Qudi to run instead of the Z optimiser? Would it relatively straightforward to add this to an automation loop?

[LukePiewalker]

We just discussed again internally and another option would be to not rely on the already present interfuse and write one which just interfaces with your attocube stepper and the 'NIXSeriesFiniteSamplingIO', because in this way it might be easier to handle the timing of a scan, e.g. attocube steps, 'NIXSeriesFiniteSamplingIO' does a line scan and then repeat.

For "simple z-optimization" I am not to sure how you would handle the timing from your attocubes tepping and the data acquisition of your signal, which I suppose is still happening with your Ni card?

The PoiManager toolchain is designed to be connected to a 'ScanningProbeLogic' instance (and 'ScanningOptimizeLogic', which however is also connected to the 'ScanningProbeLogic') and in the end the 'ScanningProbeLogic' is the sole connection to the hardware.

So the easiest way to intercept is on the hardware level, which in the end is why qudi abstracts away hardware and is designed like it is from the start ;)

Completely separate I cannot really come up with a solution right now. From my experience, even though there might be options to have some "purely python functions" this is typically a rather hacky approach which typically don't age well and can in the end cause more headaches then just writing a hardware module.

[timoML]

It's only touching this discussion slightly, but: We discovered during internal testing that the scanning toolchain had a bug that prevented configuration of a single optimization step, eg. in the config optimizer_plot_dimensions: [2] for a pure 2d optimization. I puhsed a hot fix to this problem.

[seizagirre]

Thank you both for your comments on this thread.

The attocube stepper I want to use requires using a .dll library to communicate through python via USB connection, so for now I've written a communication library that I've installed as a package within the qudi environment, allowing me send commands via python/jupyter within the qudi kernel. This means that I can write an optimisation function that can run inside the Qudi kernel that makes use of these custom attocube functions and the Qudi nicard get_counter().

I am currently using the confocal scanning just to do xy, and optimise just xy with the native qudi optimisation logic, and later on in a Qudi jupyter notebook I can run whatever measurements on where I place my crosshair or on saved POIs that I import. In this way I can alternate between using the qudi functions and my custom attocube optimisation function in the notebook. That's all the functionality that I need right now, I will probably integrate it into the qudi optimisation logic later on so it's not so "hacky" and I'll post it here if I do, but for now this works to run my experiments!

In case anybody reading this later on is trying to communicate through python to an Attocube ECC100 three axis motion controller using the dll library here are the communication functions I wrote: https://github.com/seizagirre/ecc100-python-dll