Wrap the Opal Kelly dll with ctypes for flexible usage

[drogenlied]

Migration: trac#298.

The current version relies on the version of the swig wrapper, which is connected to a specific python version. By wrapping the ddl with ctypes, a more flexible behaviour coul be ensured.

[kay-jahnke]

The Opal Kelly implementation is currently only available and implemented in the private thirdparty-tools.

I think before we invest to much work, we should see if we can make it available here and see if the more general functionality is still needed. The current wrapper wasn't touched for 10 month.

[a-stark]

The Opal Kelly implementation is currently only available and implemented in the private thirdparty-tools.

That is true. This is the reason, why we should think about a wrapper which does not rely on the Opal Kelly swig solution, since the only thirdparty part will be the actual dll and we could include the wrapper in the qudi hardware files. Eventually, we are just using around 4 methods from the dll, therefore it should be actually pretty fast to implement it. Another reason why we should do a ctypes implementation is that this very module holds us back in setting the default python version in the conda env to python 3.5 or higher (the wrapper is build with swig and is only working for python 3.4.4) I do not consider swig as a good and flexible solution, ctypes is much better although it is 'low level python'. Within the next weeks I will start working on the setup. Then I can start implementing the wrapper.

[kay-jahnke]

Hi Alex, I will wrap the dll for you. I have the soft-/hardware not installed, however. So I will rely on you for testing.

Could you please send me any documentation on the dll you have, so I don't have to de-assemble the swig wrapper. If you have a certain delivery date, please let me know.

[a-stark]

Hi Kay, awesome :). The first point I would start from, is the API reference from Opal Kelly: https://library.opalkelly.com/library/FrontPanelAPI/index.html

A more detailed (general) documentation can be found here: https://docs.opalkelly.com/display/FPSDK/FrontPanel+SDK

The hardware file should eventually contain all relevant calls, which needed to be wrapped. The dll libraries should be included in the Frontpanel installation of Opal Kelly.

I guess also that @Neverhorst would be interested to test the implementation.

[Neverhorst]

@kay-jahnke: Wrote you an e-mail on your alumni address. Thanks for the effort.

[drogenlied]

See https://github.com/drogenlied/qudi/blob/ok-ctypes/hardware/ok_ctypes.py for the structs that the opal kelly dll uses.

[kay-jahnke]

Just did roughly the same thing on the OK-Wrapper branch: https://github.com/Ulm-IQO/qudi/blob/OK-Wrapper/hardware/opal_kelly_wrapper.py

But yours looks better. I think I'm trying to put to much in one class and it get to complicated. Splitting the code to multiple files for definitions and function wrapping seems a good idea.

@drogenlied : We should synchronize a bit more.

[drogenlied]

It turned out that ctypes did not work well in all situations and tended to produce segmentation faults.

I have started a new repository for the wrapper, https://github.com/Ulm-IQO/pyOKFrontPanel and implemented things far enough to produce a drop-in replacement for Opal Kelly's Python bindings that works with Niko's counter and pulser.

[drogenlied]

pyOKFrontPanel is on the pypi repository and can be installed via pip.

It supports a sufficient amount of functions for use with Qudi.

The qt5-migration branch contains corrected import statements.