Codecov Report

Merging #902 (d59149d) into master (5165d2d) will increase coverage by 0.00%.
The diff coverage is 18.18%.

@@           Coverage Diff           @@
##           master     #902   +/-   ##
=======================================
  Coverage   11.30%   11.30%           
=======================================
  Files         624      624           
  Lines       71803    71811    +8     
=======================================
+ Hits         8117     8121    +4     
- Misses      63686    63690    +4     

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5165d2d...d59149d. Read the comment docs.

Note there is a small bug in current protocol.py in setting z position since the step size add on doesn't include the direction, so if you are doing a top-down stack you won't get the last slice

In [4]: np.arange(0, 5 + 0.95, 1)
Out[4]: array([0., 1., 2., 3., 4., 5.])

In [5]: np.arange(5, 0 - 0.95, -1)
Out[5]: array([5., 4., 3., 2., 1., 0.])

In [6]: np.arange(5, 0 + 0.95, -1)
Out[6]: array([5., 4., 3., 2., 1.])

now also addressed in this pr

@David-Baddeley any status updates here?

See latest iteration of #799. Needs a bit of testing / refinement, and maybe another iteration to remove some of the gross aspects. Should however give nice easily called endpoints for both action queueing and webui.

Major un/semi-resolved design choice as follows:

Should the z dwell time be part of the stack settings, or the spooler settings? Current version of the #799 opts for the worst of both worlds and lets it be either with significant grossness as to who takes priority for default values.

Arguments for the dwell time to be part of the stack settings:

• seems like a logical place for it
• tidy, easy to grasp as an endpoint for an end user

Arguments against (effectively the status-quo where the z-dwell settings are a property of localisation series rather than z-stepping):

• you are unlikely to want to share it between different modalities (i.e. the chance of wanting the same z-dwell for a localisation series and a widefield stack of the same structure is virtually nil, whereas sharing other stack parameters is quite likely/common/desirable if you want to do any form of correlative or multi-channel imaging.)
• putting dwell time in the stack settings means that you can't easily share stack settings between modalities (or if you do you end up with garbage spaghetti logic like I have in py3 (and other) fixes for pymeacquire web ui #799.

I think there are are some pragmatic short-term things which would let us get #799 in though (even if this is a bit of a brain fart)

Have a pragmatic interim solution to the above.

should be redundant to changes in #799