Labscript maximum shot length

7 views
Skip to first unread message

Jack Sullivan

unread,
Oct 14, 2025, 3:26:14 PM (22 hours ago) Oct 14
to the labscript suite
Hi everyone, 

I'm currently trying to use Labscript to take pictures and need a shot to run for multiple minutes while I take pictures every ~10 seconds or so. However, I'm using Prawnblaster as a pseudoclock and based on the documentation and my own runs it seems that Labscript can't run shots for longer than 42.9 seconds since it causes an overflow with the pseudoclock.

I think part of my issue might be due to my still limited understanding of how the pseudoclock and Labscript work together, but I was wondering if Labscript is just not meant to be run on "large" timescales (such as multiple minutes), or if there is a way to run a shot for multiple minutes.

Thanks!

dsb...@gmail.com

unread,
10:39 AM (3 hours ago) 10:39 AM
to the labscript suite
Hi Jack,

Labscript can run shots at least out to 10 minutes. However, there is a transition from "short waits" to "long waits" when there are long delays between clock edges. This transition from short waits to long waits has a bug and does not function.


I've been meaning to make a pull request for the above, but, well...

I know that we fixed the issue for Prawnblaster too, but I do not see the commit on our fork. It will be some time before I have access to local code again, but I'll post it when I do.

Before we fixed the issue, we were able to use DO lines that were not connected to anything to keep long waits from occurring. I forget if that trick worked with our Prawnblaster as well.

dihm....@gmail.com

unread,
12:32 PM (1 hour ago) 12:32 PM
to the labscript suite
Jack,

Dan's right that waits are probably the best way to go for having very long periods between events (and I'd be very glad to see a PR that fixes an issue with them!). That said, I think your desired use case should be reasonably fine as-is. That 42.9 second limitation only limits how long you can go between state changes on the Prawnblaster itself. If you are doing something every 10 seconds which causes the Prawnblaster pseudoclock to tick at least once, you should be fine. You can even insert dummy instructions (to an AO for example that updates its static output to the same value) to break up longer periods into smaller chunks that respect the 42.9 second limitation. And to be honest, a separate pps heartbeat monitor for your shot probably isn't a bad idea anyway.

One thing you should be aware of (if you aren't already) is that the Prawnblaster internal clock is not particularly stable (in practice, it comes in around a couple ppm). For such a long sequence, you'll want to consider an external system clock with higher stability. And in case it matters, beware that DAQ analog inputs are not directly timed using the pseudoclock, so if you have AIs that need to be synchronous with other things over such long time scales, you'll want to provide a stable reference to the AI clock as well (described here).

-David

Reply all
Reply to author
Forward
0 new messages