Piezo motion controller.

[MatthieuDartiailh]

I will need to implement shortly a driver for an Attocube ANC300 Piezo positioning electronic system. And to avoid doing it twice it would prefer to do it directly with lantz. Does anybody else use that kind of system ?
It should be noted that this electronic can be connected to different sort of motion controller which cannot be remotely identified hence it behaves like a mixed AC DC voltage generator and features will all be expressed in volts. I will do what I need to get it working and see if we can come up with any sort of standard.
Another interesting point is that it uses telnet for communication and hence will require a new backend for lantz_core, I will open the corresponding issue.

[arsenovic]

i had a class for a newport mulit-axis motion controller, https://github.com/scikit-rf/scikit-rf/blob/master/skrf/vi/stages.py#L21

i dont use this very often (or have access to it) but i just thought i would mention is in case there was a desire to have a linear axis controller mother class.

also, fyi i will be using the new lantz framework shortly, and am looking forward to it!

[hgrecco]

@arsenovic we have the same controller and a working Lantz Driver. I think is definitely a good idea. Let's try to come up with an API.

[MatthieuDartiailh]

Glad to see you back in the loop @arsenovic . I will try to give a look at your driver and the one found in lantz.

[MatthieuDartiailh]

@hgrecco I can't find the driver under the newport package (there is only a powermeter, could you please point me to it).

[hgrecco]

It is not there because it is not curated. We use it internally in our lab. I will put in a gist.

[MatthieuDartiailh]

Great !

[alexforencich]

I have four ThorLabs APT closed-loop piezo controllers that I have been mulling over writing a driver for. It might make sense to add an APT backend as well.

One thing that we should think about, though: it is possible to open multiple concurrent connections to a device via ethernet, but it is not possible to do this via USB, serial, etc. directly. It would be very cool to be able to have a manual adjustment application that can be paired with separate scripts to control the positioning stages (e.g. optimize position for highest power) so you can quickly switch between manual adjustments and automated adjustments. However, the ThorLabs APT units connect via USB to serial chips, so it's not possible to connect two different applications at the same time without adding an arbitration layer of some sort in between. It is also nice to be able to have an ipython session running with an active connection so the instrument state can be queried and various commands tested manually while not interfering with running automation scripts that use the same instrument (don't have to exit ipython to run a script). Works great with LXI devices or GPIB devices through a GPIB to LAN bridge, but it doesn't work for USB and serial devices. I'm not sure what sort of implementation might make the most sense here, or if this is a feature that anyone would require. It may be necessary to have some sort of a daemon running in the background in order for this to be possible. Thoughts?

[hgrecco]

The way we do that kind of things is having a control app on the background. The lantz app can be split into processes which communicate using pizco. Each process can control one or more (or all devices). A very common desire is to have the core application running in a process and the GUI in a different one. If the latter crashes, the core continues. This is really nice for long unsupervised experiments. For interactive experiments, multithreaded works better.

BTW: Pizco works fine but was just a work in progress, because it is more than a query-response. It can also notify clients.

So your proposal is also useful for this type of goals like having a detached/detachable GUI. It might be look again at the Jupyter project to see how they do it. I looked at the pre 1.0 IPython and the client/server part was too intertwined with the notebook code. Maybe now that Jupyter aims for different backends is better separated.

But, my suggestion is not to add this in Lantz-core, nor in Lantz-drivers. But we need to be sure that can be implemented easily. If you provide good introspection capabilities (as the current lantz has and we are planning for the next) it is easy to create a script that wraps a driver generating a client and a server. An example of such introspection capabilities is how the current test panel GUI that can be generated on the fly for any driver (This will be in a separate python package in the next lantz). Similar to this We could provide a way to generate other way of accessing this, such REST API that can be mounted easily in a web server.

[MatthieuDartiailh]

Having the possibilty to have a kind of server is definitively something I would like in the long run but I agree with @hgrecco that it will be by wrapping the existing driver.

[MatthieuDartiailh]

Looking on github for apt thorlabs yields many repos. It would make sense to try to get in touch with their maintainers.

[MatthieuDartiailh]

The card I need to interface is a open-loop positioning module, the rack can accept two other types of cards :

• one is an open-loop scanning module
• the other an open loop scanning and positioning module.
  I am not sure what are the main differences between open and closed loop and whether they need different bas classes or not. I will try to dig a bit more.

[MatthieuDartiailh]

Looking quickly at some of the driver for Thorlabs APT it seems that two approaches are possible either stick with what thorlabs gives us and have a windows only driver relying on a dll (easy using PyCLibrary), or go the hard way and use libftdi (another kind of usb driver) and manage the communications ourselves (this is what is done by pyAPT project and it seems doable as Thorlabs provide a document describing low level communications see https://www.thorlabs.de/software_pages/ViewSoftwarePage.cfm?Code=APT). One issue will be documenting the installation of libftdi for our users.

[alexforencich]

I think the libftdi method is the way to go for the APT controllers as it's not limited to windows.

[MatthieuDartiailh]

I looked a bit more at how my system works and compared it to the Newport one mentioned by @arsenovic and also what can be done in thorlabs apt. The Newport is a closed loop system (or so it seems to me) and hence quite far from my own need, the apt capabilities are large (doing it will a tremendous work) and even if an open-loop stepper motor might look like my system I am not sure it will be the same.
As I need to interface my system to at least do some testing, I will post my work and see whether or not we can build a standard from there. And this way you will see why it does not fit well with other motion controllers.

[alexforencich]

I'm wondering if it might be feasible to implement the interprocess arbitration layer seamlessly in lantz. I'm thinking that what we could do is provide a daemon script that can be run separately (perhaps even as a system service) when this functionality is required. Whenever a script tries to connect to an instrument, it will attempt to connect to the daemon first and then it will fall back on opening the connection to the instrument directly if the daemon is not running. This would allow seamless sharing between control/monitoring UIs and other automation scripts without having to write wrapper scripts. It could be extended to allow scripts to connect to a daemon running on a different computer, so instruments that do not support a network based protocol could be shared. Thoughts?

[MatthieuDartiailh]

I just opened a new issue concerning the use of a central server to avoid crowding this issue with unrelated discussions LabPy/labpy-discussion#15.

[alexforencich]

For the APT controllers, building on top of pylibftdi may be the way to go. Looks like that is a decent cross-platform libftdi wrapper library.

[MatthieuDartiailh]

We shoukd also look at pyAPT https://github.com/freespace/pyAPT and see if we can build on top of it.

[alexforencich]

I actually took a look at that one a while ago when I was thinking about automating these stages, but it seems to be missing most of the APIs for the piezo controllers - it only seems to have APIs for the stepper motor controllers. Either way we will have to implement the piezo controller API.

[vascotenner]

Currently, I have a Lantz driver for the newport ESP300/301 units. It is working with Lantz0.3.

Furthermore, I am using thorlabs PRM1 rotation stages via pyAPT. pyAPT now also runs under python3. I did not create a lantz wrapper for pyAPT, mainly because the current status of lantz and the repositories is rather vague.