Question about the Prawnblaster, instruction limit, and repetitions

[Cody B]

Hi everyone,

I have a project that is using labscript in such a way that there are several shot executions within a for loop. Naturally, we are being limited in how many loops we can perform due to the 4000 instruction limit of the Pulseblaster. We are looking to upgrade to the Prawnblaster, and I had a few questions that I couldn't find answers to anywhere else. 

In the Prawnblaster page, it states that the device has 30,000 instruction limit, with 2^32-1 possible repetitions. What exactly constitutes a repetition in labscript, and how, in the labscript suite, can I take advantage of this?

Is there any disadvantage of putting multiple devices on the same clock line, to avoid dividing the instruction limit? For example, having two NI DAQ devices and a Novatech DDS on the same line that shares 30,000 instructions, rather than 3 lines that have 10,000 each, which will be heavily underused on some lines?

And lastly, I'm not too sure if this is a silly question or not, but is it possible to have multiple Prawnblasters as dedicated pseudoclocks for each device (so that each device has a 30,000 instruction limit), and possibly with a synchronized clock shared between them?

[Philip Starkey]

Hi Cody,

Each instruction for the PrawnBlaster contains information on the frequency of the clock ticks (we store it as the length of time for the half-period - e.g. the length of time a clock tick should be in the logical high state assuming symmetrical pulses) and the number of times the clock should tick at that frequency. It's the latter that is referred to by the term "repetition". A repetition of "1" would mean a single clock tick, "2" would be two clock ticks, etc. The labscript suite will take advantage of this whenever you use a ramping function on an analog quantity. For example, if you used, on the Novatech device channel, something like dds_1.freq.ramp(t, duration, initial, final, rate), then labscript would generate a single PrawnBlaster instruction that ticked for the requested duration at the requested rate. Of course it gets a lot more complicated once multiple channels are in the mix. The requested rate for a ramp is the minimum rate - labscript may increase the rate if something else happening at the same time has requested a faster rate. And if there are overlapping ramps or constant value changes on other channels, then the ramp may be broken across multiple PrawnBlaster instructions. But the general idea is that any output command that involves a duration is the best way to take advantage of the repetition functionality that reduces the instruction count.

The disadvantage of putting multiple devices on the same clock line is that you may run out of instructions in those devices. For example, I think the Novatech DDS devices only have around 16,000 instructions? So they can only handle 16,000 clock ticks regardless of whether that comes from one PrawnBlaster instruction that ticks 16,000 times, or 8,000 PrawnBlaster instructions that tick twice each. As such, the devices with limited instruction memory should be placed on their own clockline.

In hindsight, it's unfortunate that I didn't think to allow the number of instructions per pseudoclock to be configurable on the PrawnBlaster...I don't think there is any fundamental reason why we couldn't have allowed 28,000 instructions on one pseudoclock, and 1,000 on two others. I just chose to equally segment the RAM. I might look into how feasible it is to add that now (and you are welcome to do the same if you have an interest in embedded programming). Another alternative would be to try and source the just released Raspberry Pi Pico 2 (it needs to be the official one, not a 3rd party board, which has limited stock at the moment). I have some experimental firmware up in a pull request on GitHub that should double the number of instructions on the Pico 2, but I can't get a hold of the board to test!

Finally, yes, you can absolutely have multiple PrawnBlasters. Not a silly question at all. Labscript, and the PrawnBlasters, support the concept of "secondary pseudoclocks" - which are pseudoclocks triggered by a device on the primary pseudoclock. So you go PrawnBlaster -> NI card (with digital outs) -> PrawnBlaster -> Other devices. Each PrawnBlaster can of course have anywhere between 1-4 pseudoclocks and any number of devices attached in whatever configuration makes sense to you. We don't currently support tertiary pseudoclocks, but you can have as many secondary pseudoclocks as you like! It is strongly recommended to ensure all PrawnBlasters (or other pseudoclocks) are synchronised via a common external reference. The PrawnBlaster documentation here has some further information on that. If you don't do this, the two pseudoclocks may drift over the course of each experiment, resulting in inconsistent synchronisation between outputs from shot to shot.

You may also want to consider building a breakout board for the PrawnBlaster: See https://github.com/QTC-UMD/PrawnBlaster_Breakout_Connectorized/tree/main

I'm happy to answer any other questions you have!

P.S. It's probably worth pointing out that due to the way the PulseBlaster works, the effective number of pseudoclock instructions are actually half the PulseBlaster's instruction limit. So a labscript experiment that fits in a 4000 instruction PulseBlaster would actually only use 2000 instructions in the PrawnBlaster. Thought I'd mention it in case that factor of 2 makes the 10,000 PrawnBlaster instruction limit (assuming 3 pseudoclocks) sufficient as I think it would be 5 times what you have now (or 10 times if you can get a Pico 2). You could then add secondary pseudoclocks/PrawnBlasters later should you need to move some devices off onto their own.

Cheers,

Phil