Loop recognition

[philipstarkey]

Original report (archived issue) by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

---

Loops in experiment scripts should get recognized an not waste Pulsblaster commands. If we do something like the following code we quickly reach the maximum commands of the Pulsblaster this is suboptimal.

#!python

start()
t = 1
for i in range(2000):
    digitaloutput_name.go_high(t)
    t += 1
   digitaloutput_name.go_low(t)
    t += 1

stop(t + 6)

[philipstarkey]

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: pstarkey).

---

What device is the digital output on? If it is an output on a device (such as an NI card) that is clocked by a PulseBlaster, then you can use the repeat_pulse_sequence method.

Unfortunately I don't see anyway to do this simply on a direct output of a PulseBlaster since managing intersecting ramps between clocklines and the direct output is going to be really hard, if not actually impossible.

[philipstarkey]

Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

---

Yes it's a NI card, I'll take a look at repeat_pulse_sequence definitely sounds good hadn't seen that function before.

But I was thinking of a more general solution. Maybe some sort of syntax to analogous to "for" in python to indicate loops. Or a pattern recognition on the pulsblaster instructions that reduces them at the cost of compile time.

[philipstarkey]

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: pstarkey).

---

Yes, a pattern recognition algorithm to minimise PulseBlaster instructions is something we've thought about before, but never found the need to implement. If you want to go down that route you are welcome. We've found it easier to add another PulseBlaster or PineBlaster in order to increase the number of independent pseudoclocks which ultimately cuts down on instructions, rather than write the optimisation algorithm!

Personally, I think many PineBlasters are the future of PseudoClocks and PulseBlasters will be used in just standalone mode (which saves significant instructions since you don't need to tick any clocks and is already supported!), if used at all, but don't let that stop you!

[philipstarkey]

Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

---

• changed title from "Loop recocnition" to "Loop recognition"

[philipstarkey]

Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

---

I gave repeat_pulse_sequence a try and it seems to do what I want it to but is sadly not as user friendly as for loops are.

Out of curiosity and a bit off topic: As you mentioned Pineblasters why don't they support direct digital outputs like Pulseblasters do? (we don't have any atm but I'm thinking about getting one as you made a good point earlier)

I could imagine there being great benefit in using direct pulsblaster/pineblaster outputs for the purpose of loops as they support them and Ni cards just get overloaded with instructions.(depending in the amount of samples and loops) You already mentioned problems with things intersecting the loop but besides those issues are there other things that could cause problems?

[philipstarkey]

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: pstarkey).

---

Mainly the lack of support is because we've just never needed to do a repeated pulse sequence. The few times we have done something with sequential digital pulses, we've typically ended up wanting to do something non-linear in time which then rules out any sort of looping (at least with the standard set of hardware we support),

There is a version of the PineBlaster called the BitBlaster, which has 8 digital outputs, but it doesn't support looping and has yet to have a labscript_devices interface written for it. I've also begun merging the code-base for the PineBlaster and BitBlaster (along with support for a better spec'd ChipKit device) in the PineBlasterv2 project. This one again doesn't have a labscript_devices interface, needs comprehensive testing around trigger timing (had some issues where assembly instructions weren't executing with the same timing due to instruction caching in the CPU which I've hopefully fixed, but isn't tested enough of my liking) and doesn't bring additional looping functionality (the main advantage of the newer chipkit board is additional memory for more instructions, faster timing in bitblaster mode and it's easier to externally reference it to 10MHz).

You could also construct a dummy intermediate device in labscript (I may have code for something like this somewhere...) that you attach to a PineBlaster clockline in order to generate the required set of pulses on the pineblasters single clockline output, and then just use that output directly. Doing this avoids the issue of intersecting loops since each PineBlaster only has one output (although you may run into issues with synchronisation since they are running off crystals and it's non-trivial to reference the original PineBlaster to 10MHz).