PrawnDO

[dihm]

This is the labscript device code for using the PrawnDO, a companion digital output device for the PrawnBlaster that is also based on the Raspberry Pi Pico. The firmware is available here. Combining a PrawnBlaster with a PrawnDO fully replicates the capabilities of a PulseBlaster or PineBlaster, with much cheaper hardware and often better performance.

[philipstarkey]

I have thought of two solutions to this, though neither is especially elegant:

I haven't looked if this is the same, bit we do something similar for the PulseBlaster by overriding get_child_from_connection_table on the BLACS class. Could be worth a look to see if it's applicable in this case too?

[carterturn]

@philipstarkey 's solution seems good. Just need to add

def get_child_from_connection_table(self, parent_device_name, port):
        return self.connection_table.find_child(f'{self.device_name:s}__pod', port)

(And also remove the leading "0x" from the BLACS tab ports)

[dihm]

@carterturn Thanks for taking a closer look at this. Obviously I hadn't gotten around to a more thorough look/test of the code. I believe the two commits I just put up fix the biggest problems, but I haven't tested (on vacation at the moment).

In both cases, do_prop keys should be changed from 0x{:01X} to {:01X} for consistency with the labscript device. This also requires a corresponding change to _int_to_dict in blacs_workers.

This is probably a more subtle issue. Currently, I tried to be cute and allow for an extremely flexible specification of channels in the labscript_device (it allows any string so long as it ends with a space and the correct hex digit). I'm guessing that cuteness has broken some of the automated BLACSTab functionality. In any case, I had intentionally chosen to be inconsistent here since the bare character labels weren't great on the Tab (in my opinion). Assuming they have to be made consistent, I'm more inclined to change the internal labels to be 0x{:01X}. Thoughts/opinions?

[philipstarkey]

This is probably a more subtle issue. Currently, I tried to be cute and allow for an extremely flexible specification of channels in the labscript_device (it allows any string so long as it ends with a space and the correct hex digit). I'm guessing that cuteness has broken some of the automated BLACSTab functionality. In any case, I had intentionally chosen to be inconsistent here since the bare character labels weren't great on the Tab (in my opinion). Assuming they have to be made consistent, I'm more inclined to change the internal labels to be 0x{:01X}. Thoughts/opinions?

I haven't look into this, but I don't think you should have to enforce what the labscript channel is? You will have to decide on what the prefix should be in BLACS (you can't have it dynamically determined from what it was in the connection table because it might not be in the connection table). But it should be fine to match the BLACS channels to something in the connection table so that the output name (not channel) matches what it is in labscript? Pretty sure we do that with some devices already (maybe pulseblaster or novatech DDS)

---

I noticed this line in the PrawnDO firmware repositories README today:

(23,000 inside Labscript due to ZMQ timeout)

Why is the instruction count limited by labscript? Is that something we need to dig into more? I can't see why ZMQ is implicated in instruction count and we regularly have other devices with more instructions...

[dihm]

The ZMQ timeout comment was due to the slower programming. The default ZMQ timeout was 30 seconds, so 23k instructions were the max you could write before the call would timeout. With binary programming, that is no longer an issue. We should remove that comment.

[dihm]

@carterturn I've finally gotten around to testing and fixing the widget creation. I've decided to go for the simplest approach possible that needs the fewest hacks. Hardware channels are specified using strings like 'do10'. I went ahead and ditched the hex channel specification since the GPIOs are numbered in decimal and converting between hex and decimal is unnecessarily annoying.