[motion.kinesis] Organize Kinesis to support multiple devices

[natezb]

The Thorlabs Kinesis software can be used to control many devices, using many interrelated headers and DLLs. Each device-specific DLL depends on Thorlabs.MotionControl.DeviceManager.dll, which provides TLI_ functions for listing and getting info of all kinesis devices on the system.

Then there are the device-specific functions, e.g. those starting with FF_, ISC_, BMC_, etc. There are a number of device-specific functions that are the same (barring the prefix) across the drivers, as well as completely different functions.

I think a proper kinesis-wide driver would have a list_instruments() which doesn't require any of the device-specific driver wrappers to be built.

• [x] Create a mini-header that just contains the TLI_ functions and data structures
• [x] Separate mid-level libraries into their own modules
• [x] Separate DLL-specific drivers into their own modules

Other Considerations:

• [ ] Should minimize the amount of repeated code
  • [ ] Probably doesn't matter as much for the mid-level bindings, since Sigs are pretty compact, though it could be nice to have a central collection of all Sigs, which get selectively added to each mid-level class
  • [ ] Could reuse code in drivers either by using subclassing, or having a common collection of functions which can be selectively added as methods to each Instrument class.
• [ ] Might want some kind of "unsupported instrument" marker for ParamSets, so we can return ParamSets even for Kinesis devices we haven't yet written a specific Instrument class for.
• [x] Should move all kinesis files other than kinesis.py (and maybe _build_kinesis.py?) into a separate _kinesis subdirectory.

I'm working on this a bit now, in a separate branch which I'll be pushing shortly.

[drewrisinger]

@natezb What is the status of Kinesis support? Has there been any progress since Feb?

I've been looking at writing my own Kinesis drivers (plugging into the Thorlabs Kinesis C# DLLs and pythonnet to wrap them using C# classes instead of C/nicelib), and don't want to duplicate work.

Also, where did you find documentation on these FF_ and ISC_, etc functions? I looked at the Thorlabs APT and Kinesis documentation, and didn't find any references to those.

[natezb]

I hadn't seen pythonnet before, that's good to know about.

I haven't worked on the Kinesis support in awhile, but I just pushed some local changes from back in May into a new kinesis branch: see here.

On my machine, the docs are located at C:\Program Files\Thorlabs\Kinesis\Thorlabs.MotionControl.C_API.chm. If you expand the Modules category at the bottom of the navigation tree, it contains docs for those category-specific functions.

[drewrisinger]

Thanks. I'll look at contributing to this in the next week or so.

I found the C API documentation. I had missed that one and only seen the C# API. Do you have any thoughts about which API would fit better with the Instrumental code base?

On Thu, Oct 4, 2018, 11:42 PM Nate Bogdanowicz [email protected] wrote:

I hadn't seen pythonnet before, that's good to know about.

I haven't worked on the Kinesis support in awhile, but I just pushed some local changes from back in May into a new kinesis branch: see here https://github.com/mabuchilab/Instrumental/commits/kinesis.

On my machine, the docs are located at C:\Program Files\Thorlabs\Kinesis\Thorlabs.MotionControl.C_API.chm. If you expand the Modules category at the bottom of the navigation tree, it contains docs for those category-specific functions.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mabuchilab/Instrumental/issues/47#issuecomment-427237204, or mute the thread https://github.com/notifications/unsubscribe-auth/AJucI_Ew1gXOLjoTicf6kw6zHpJWui1lks5uhtU4gaJpZM4SRnrN .

[natezb]

I would say that the C API fits better, especially since we already have code wrapping it--both motion.kinesis and motion.filter_flipper wrap the C API using NiceLib. The tricky part of this, as I noted in the original post, is integrating all these similar drivers under one umbrella, which is the point of the in-progress kinesis branch.

In the general case, I wouldn't be opposed to C#-based drivers for instruments that are Windows-only.

Let me know if you encounter any issues or get confused, it's possible I left this branch in a fairly incomplete state. In particular, it may rely on NiceLib features which are not yet released, but can be obtained via the development version on GitHub.

[drewrisinger]

So, I was looking today at the C# vs C drivers. Before I found Instrumental, I had already written a working prototype to auto-import the C# drivers as individual classes (created by Thorlabs)

Pros:

• Take advantage of work Thorlabs has already done creating classes.
• Would replace manually writing "midlibs" as you call them, even if somewhat automated by Nicelib

Cons:

• C# doesn't run easily on MacOS/Linux. There are workarounds like Mono
• Using pythonnet for imports introduces additional dependency for Instrumental.

Neutral:

• Either case, still need to write higher-level drivers.

I'm primarily looking at writing drivers for Piezos (e.g. KCube Piezos), and then wrapping those to allow interfacing with a different control system. Just wanted to make my work available to more people, because there doesn't seem to be any python wrappers/drivers for any Kinesis hardware.