pganssle/Magnetometer-Controller — Issue #15: Calculate length of programs, on-the-fly time estimates
Author: pganssle
Created: 2012-01-25 02:54:55+00:00
State: open
Labels: Features, Low, PulseBlaster, UI

It would be very convenient to be able to know how long a program is supposed to take and how long it's actually taking. Since you specify the timing for everything, it seems like it would be simple, but it can actually get kind of complicated (which is why I have yet to fully implement it).

The issues are thus:
1. You need to take into account loops, loops-within-loops, branches, etc. When you never use JSR or any other complicated thing, a Branch, if reached, would set the "time" of a pulse program to be infinite, this is an absurd situation, and so branches should probably be ignored. I don't fully understand the behavior of JSR/RTS, so I don't have a great sense of how to account for them in the time.

.
2. Assuming you get all the loops and loops-within-loops right for any given experiment, in general this feature is *most* useful for complicated multidimensional programs where instructions change within each loop. The naive algorithm would be to write a function that gets the time for a given instruction, then load each different configuration that will be seen in the entire (ND) experiment and add up the time. That may be OK, but I think there may be a simple algorithm which takes into account the sparsity of the changing portion of the matrix - similar to the way the pulse programs themselves are stored as a "sparse" array.

.
3. Even though you set the timing and such, you usually don't know how long something is *actually* going to last, because of all the shit that goes on between running the program (loading/unloading data, etc). This is especially clear when a WAIT instruction is present. This is where the "on-the-fly" estimates come into play. I would recommend that a Timer() is initialized at the beginning of the first experiment, and at each step in the process, you should calculate the total time that your experiment "should" take, then calculate the difference between the amount of time that your experiment has taken and the ideal time to generate a running average of the time between transients.

Keep in mind that can't simply say "expected total time = 1000s in 50 transients, I am on transient 20, so it should have taken 400s" - in most cases, you'll be looking at a non-linear function which dictates the program-running-time until you're done and a linear function (constant time) which dictates the inter-transient time, so you really need to keep track of the two things separately.