labscript-suite / labscript

The 𝗹𝗮𝗯𝘀𝗰𝗿𝗶𝗽𝘁 library provides a translation from expressive Python code to low-level hardware instructions.
http://labscriptsuite.org
BSD 2-Clause "Simplified" License
9 stars 48 forks source link

Labscript Device that manages lines from NI hardware #82

Closed jondoesntgit closed 3 years ago

jondoesntgit commented 3 years ago

I'm wondering if one of the devs can help with an implementation question.

We've assembled a box that contains a few pieces of hardware in it. The hardware is programmed over an SPI interface, where multiple components have a shared clock, shared data line, and their own respective chip-select lines. I'd like to make a BLACS tab for this box where we can enter in settings as AnalogWidgets and a worker thread programs the specific piece of hardware. This would make debugging and setting up experiments a lot easier.

I've tried looking through examples online and in the thesis, but I can't find something in labscript that does this right now. The closest thing is a Shutter, which extends an NI DigitalOut functionality, and runs either go_high or go_low with some configurable delay. But what I'm looking for is something that can take several NI DigitalOuts and we can say in BLACS "set the internal setting to 18 on device 3", and then does the following:

  1. cs3.go_low(t) (DigitalOut for chip select 3, line 13)
  2. Break the human-readable value of 18 into 0b011010
  3. Bit bang each bit out, by toggling clock.go_high(t+idelay); data.set_to_value(bit[i]); clock.go_low(t+idelay+hold_time); Let's say clock is a DigitalOut line 15, and data is another DigitalOut line18
  4. cs3.go_high(t+len(bit)*delay+hold_time)

I can do this just fine in an experiment.py file, but like I said, I'd love to be able to do this in BLACs.

So far, I've thought of two ways to do this:

  1. Give the box BLACS tab a reference to the NI instrument BLACS tab, and then the box toggles stuff on the front-panel by calling high-level API functions.
  2. Inside the box worker process, define DigitalOuts from the connection table and have two references to the DigitalOuts in BLACS (one in the box tab, and another in the NI tab)

Neither of these seems particularly elegant. Then again, bitbanging in general is not very elegant. I'm open to your wisdom.

philipstarkey commented 3 years ago

Hi Jonathan, before I comment in too much detail, is there a specific reason you are wanting to use NI digital lines to generate an SPI signal? Does the SPI command need to be precisely timed? Is a single digital trigger, to a custom microcontroller like a Arduino or raspberry pi Pico, that in turn sends an SPI command not sufficient for some reason (e.g. precise timing)?

jondoesntgit commented 3 years ago

The SPI command doesn't need to be precisely precisely timed. I imagine that using a microcontroller that runs an interrupt-service routine based on a psuedoclock input would be more than sufficient for our application.

We have an abundance of digital lines that we can use, and so I was thinking of looking into the bitbanging approach to save on installing additional hardware. However, it may be simpler in the long run to do as you're suggesting and solve the issue with additional hardware rather than hacked-together software.

philipstarkey commented 3 years ago

Cool, a microcontroller is definitely the way to go if you want manual control from a BLACS tab as well. I doubt that software timed control of digital outputs would be sufficient for sending SPI commands. So you would effectively be programming in a shot as part of a manual command. So rather than trying to control the digital lines manually, you would probably actually just need to compile and submit shots to send single SPI commands from a BLACS tab in manual mode....which is doable, but less elegant than using a microcontroller (and probably has a bunch of caveats)

FYI there is support for adding custom tabs to BLACS, it's just not documented. It's called a PluginTab - most details are in an archived pull request on the Bitbucket archive.

Despite that - I would still recommend the microcontroller route as it more closely follows the standard labscript-suite pattern.

jondoesntgit commented 3 years ago

Excellent. Thanks.