Problems implementing DMD in Labscript

[Pedro Henrique Cook Cunha]

 Hello,

I've been implementing labscript in our experiment for some time now, and recently decided to integrate our DMD (ViALUX ALP-4.2, STAR-07) into the setup.

However, I'm having a lot of trouble because there doesn't seem to be much documentation, examples, or FAQs that I can use as a guide. So far I haven't even been able to set the DMD in the connection_table to use it or call it with BLACS.

Has anyone managed to do this? Are there any current limitations for this device? Thanks in advance for any help.

Best regards,

Pedro

[Philip Starkey]

Hi Pedro,

We have support for the LightCrafter DMD (see labscript_devices). You will likely be able to adapt that for your specific device (e.g. copy/paste it to a new labscript_device file and use it as a starting point) assuming it is similar. I believe this DMD allows you to program a set of images over a network socket, and then step through them using a digital trigger. Hopefully yours is similar? Unfortunately there isn't much guidance beyond what is already online (e.g. generic advice on adding a device, auto-generated documentation for the LightCrafter DMD or my thesis). Was there a specific problem you were having? Or an error message?

Cheers,

Phil

[Karthik Chandrashekara]

Hello Pedro, Philip (and others who might be reading this!)

I wanted to check in to see if there has been any progress regarding the adaptation of the Lightcrafter DMD class for the ViALUX module. Additionally, I'm curious if anyone else within our community has been working on this or if there's a minimal working implementation available. Any insights or assistance would be greatly appreciated as we have now begun working on the same problem!

On a related note, I am wondering if it would be possible to establish a separate public repository specifically for the Labscript community. This repository could serve as a centralized hub for sharing code that has been developed and proven to work to some extent but may not yet be polished enough for inclusion in the official distribution. As we often find ourselves in need of implementing new devices, I believe such a repository would significantly reduce development time for all of us.

Over the past couple of years, we have greatly benefited from the contributions of fellow community members. Often, we've had to search for Labscript code scattered across various public repositories of other research groups, if it's available at all, or rely on the generosity of those who have shared their work here and elsewhere or are willing to on request, that is of course if we know they have managed to put together something in the first place! Now, we have some code of our own that we believe could be valuable to other Labscript users, but we're uncertain about where or how to make it available.

I am not entirely sure how one could go about this, I'm sure others here already know of a great way to do this. What I am hoping for through this is to lower the barrier for community contributions, as I am not entirely sure how much contribution there has been over the years to the official suite.

If something like this already exists, please let us know (goodness how have we missed it!?) but if not, I sincerely hope that Philip, Chris, and others within the community will consider this proposal. I am confident that, for those of us in the same boat, this will prove to be immensely beneficial!

Cheers,
Karthik

[dihm....@gmail.com]

Karthik,

I can't speak to the DMD, but I can speak a little to the rest. In short, we know this is an issue.

Right now, all we have is this very abbreviated list buried fairly deep in the docs of user_devices repos that are maintained by individual labs. ¯\_(ツ)_/¯

This is probably the place to start for sharing code. 

That said, the barrier to contributing devices to labscript-devices is likely not as high as people think. ATM that barrier is basically broader interest for the device and a thorough code-review from me to ensure some level of robustness and good practices (and not bringing in a bunch of random dependencies by default). If you have reliable code for common instrumentation, do consider making a PR to the main repo. At the end of the day, a lack of new devices in labscript-devices is probably a broad confirmation that most grad students don't have time or interest in the extra effort contributing code back upstream requires. Something I am equally guilty of, BTW!

For a longer term solution, there has been a proposal, described here, that is likely a necessary step in the direction you want to see; namely lowering the bar for getting device code up on github in a way that is easy to install alongside other user-generated devices. Converting to namespace packaging in a backwards compatible way will be something of an undertaking that hasn't made it to the top of my list, but I am interested. If someone were interested in doing some legwork, I'd be happy to help and make something happen as we really could use a better system.

-David