View of contributions

[alexshkarin]

View of contributions

[AlexShkarin]

Hello!

Thank you for you kind words! It is nice to see that the library is being used by somebody!

Yes, of course contributions are welcome! However, I haven't thought about how exactly to do this. I think, for administrative and license reasons it would make the most sense to have a separate package (e.g., pylablib-contrib), which would transparently integrate with the main package. This way the code written by me and by contributors exist in different repositories and packages, and the code ownership and responsibilities are a bit more clear.

Regarding the completeness of implementations: generally, I try to include all of the core functionality, and some of the auxiliary methods that could be helpful for the users within their scripts. The idea is to give all of the tools to automate relatively complex behavior, but not necessarily to completely replace the manufacturer-provided software or physical controls. Naturally, if users feel like some important functions are missing, they can contact the developer to see if it's possible to add them. However, I generally do not implement any functions which I can not test on a device (e.g., because it is only available on a different model): in my experience, relying just on the manual does not always give correct results, and testing on the actual devices is necessary.

For a more concrete example, consider translational stages. Whenever possible, they should implement methods for jogging, stopping, checking status (movement, limits, etc.), waiting until movement is done, moving by a given number of steps and/or to the given position, getting the current position, and homing. It is also helpful (although not really necessary) to provide basic parameter control: settings velocities, limit switch behavior, homing parameters, etc. At the same time, more obscure functions which are only rarely used, e.g., setting display parameters or communication details, do not need to be implemented. Usually these are used very rarely and explicitly, so they can be done with manufacturer software and/or physical device controls.

Regarding the way forward: in the next week or two I will look more into how to organize the contributions and how other projects manage them. Once I figure it out, I will post an update here and will also add the relevant repository info (e.g., contributing guidelines). Most likely, I would set up a separate repository and some templates, and the code contribution will follow the standard GitHub flow. This process involves code review, in which I'll try to make sure that the interfaces, the behavior, and the documentation are consistent with already existing devices. Each contribution will, of course, include the name of the contributor.

I would also appreciate if you let me know in advance which devices you want to add before spending your time on reorganizing the code to fit the pylablib structure. Sometimes I might be already working on it myself, or it might be similar enough to the existing devices that more care would be required to integrate it (for example, a new Thorlabs APT device would, probably, heavily rely on the existing Thorlabs code, rather than being a completely independent class). If this is the case, I will try to provide some guidance for how exactly to implement the particular device.

Thanks again for your offer! Hopefully, I'll let you know in the next couple of week how to proceed.

Sincerely,

Alexey.

[roesel]

Hi! Sorry for the late answer. What you propose sounds good to me, I also think that the contributions need to respect existing structure above all else and separating them sounds like it could make things easier for you.

One thing I would like to add is that while I would like to contribute to the efforts, I cannot promise that I will be able to do so - either for lack of time or for lack of skill required to do so properly. So please make sure that any time you invest in enabling community contributions is time you would be happy contributing even if I was not able to contribute myself.

As for your questions about devices, the things we are using python to control are a few Thorlabs Elliptec devices (sliders and rotators), a XYZ/P stage from ASI imaging, and a Princeton Instruments camera (via an ugly DLL hack of Lightfield, controlling the provided software rather than the camera itself). I assume the order in which I listed them is also the order of usefulness of an implementation for other people due to the number of such devices out in the wild. (I exclude things like interfacing with an Arduino which signals an LED lamp power source via coax, as this kind of thing sounds too specific.)

I'm happy to answer any other questions that come up and I look forward to the next steps. Thanks again! David

[AlexShkarin]

Hi David!

Sorry for the late reply. I've been recently occupied with different tasks, so, unfortunately, I could not yet find time to figure out the contribution structure. Hopefully, I will find time in the next 2 or 3 weeks... I believe, this is something worth doing in any case, and once I am done, I would be greatful if you could try it out and see if it works for you and it is not too confusing or annoying.

Regarding the devices:

• Elliptec stages would definitely be useful! It looks like the communication protocol is different from APT, so it should not interfere with the existing code. I will keep this device in mind when writing the guidelines and examples.
• ASI imaging stages also seem interesting. Could you elaborate a bit more which stages and controller you have implemented?
• I have recently implemented Princeton Instruments Pixis camera (via PICam interface), though it is not yet released. Therefore, I do not think this would be a priority. Nevertheless, if you have a different camera, I would be greatful if you could at some point try it with pylablib implementation and see if there are any issues.

Sincerely,

Alexey.

[roesel]

Hi Alex,

• I am already working on an Elliptec library that would cover at least 3 of the available devices. For now, this will probably be a shutter, a multi-positional slider, and a rotator. Then I will have a look if it's possible to extend the functionality to other devices, but I have my doubts I could reliably do it without having the device in my hand and being able to test it. Maybe when I am done with those three, we could look into how it could potentially fit with pylablib?
• Regarding ASI Imaging, I have access to a PZ-2000FT Series XYZ stage, as well as an LS-50 linear stage. In our case, all of these are controlled via a MS-2000-WK controller, which is the device my code is communicating with when moving things. I repeat that for the ASI stages, I have "implemented" (if you can even call it that) only the bare minimum required to do what I need, which is probably in the single digit percentages of what the protocol of the stage defines.
• As for Princeton Instruments, our lab uses PI-MAX cameras, and I have access to models 3 and 4. I have never tried controlling them via PICam, since our workflow is covered very well by their LightField program. So for now, the only thing I do is start LightField through a Python wrapper and then use some python/dll black magic which only emulates user actions in the LightField interface. This comes with (among other things) the joy of not being able to catch errors, so LightField crashes every time there is a problem and takes multiple minutes to start every time I think I fixed it and want to try again. Before sharing this code in any form, I assume I would first need to find someone who could help me do it right, or at least better (if it's possible).

If you'd like, I'd be happy to try your code on the camera without LightField, if it's compatible with our model. Feel free to let me know what exactly you would be interested in me trying.

I'm looking forward to talking more!

David

[AlexShkarin]

Hi David,

I apologize again for dragging my feet with coming up with proper guidelines. Now that the holidays are coming, I will hopefully have a bit more time to dedicate to it. Regarding your specific points:

• Yes, that would definitely be a good idea. Hopefully, by the time you're finished I can at least set up the repository, so that you could submit a push request there, and then we can discuss the necessary interface modification with a more concrete example. For now, I would just ask you, if possible, to make the interface similar to other similar devices (e.g., Thorlabs, Trinamic, or Attocube) in terms of method names, arguments order, etc. However, it's not super necessary: once the code is there, you or I can slightly alter it before submission to better conform to the overall interface.
• I looked a bit into the documentation, and it does seem to have a ton of methods. However, I wouldn't fret too much over it right now. If whatever you've implemented is enough for you, it will be enough for some other people as well. As long as it's at least modestly useful (i.e., can be autonomously used to perform the most basic operations such as moving, stopping, and getting some basic status info), and can be potentially expanded to other commands, it's worth adding.
• The new Princeton Instruments code is available with the newer library versions, starting with 1.3.0. It does require installing PICam, but it is freely available, so hopefully it's not a large burden. I have tested it with a PIXIS 400 camera included in a spectrometer, and it seemed to work fine. I would appreciate it if you could check it with your setup and confirm that it does not crash and can grab frames. But, depending on your specific requirements, it might not be enough: it communicates only with the camera, so it can not, for example, control other optical elements in your LightField system (mirrors, gratings, slits), and it does not have access to pixel-to-wavelength calibrations.
  As long as I still have access to a LightField-controlled spectrometer, I can try to look into whether there are well-defined SDKs to implement at least some parts of the missing functionality. If so, I will try to include it into one of the next library releases. If not, we can together look into your current solution and see how we can improve it.

Thank you again for your cooperation and your patience! Hopefully I'll post an update soon!

Sincerely,

Alexey.