Test on SANS instrument

[Tom-Willemsen]

LOQ could be a useful candidate as a SANS beamline which also does continuous-motion scanning (for the laser) and also isn't usually 100% scheduled as far as I know so may be easier to get beamtime on.

Acceptance criteria

• Make sure we have tickets for any requirements needed by that test, which we haven't yet covered
• Make sure the above tickets get proposed in good time before the relevant test
• Arrange the testing time
• Go to the beamline and do the test
• Write up any relevant issues/feedback in further tickets

[Tom-Willemsen]

Split this ticket into 2, keeping this one as sans test and muon test in #85

[Tom-Willemsen]

According to RD:

• Should be able to schedule time on LOQ to test with neutrons during cycle 2024/5, but no definitive date yet
• Want to test sample changer scans, which will give a top-hat or trapezoid style fit

[rerpha]

script used on LOQ:
bluesky_test.zip

screenshots of scans:
\\isis\shares\ISIS_Experiment_Controls\data for tickets\ibex_bluesky_core_80\screenshots

[Tom-Willemsen]

Test on LOQ with L. Ca. (SANS group):

• Generally went very smoothly, test was mostly run by @rerpha and @jackbdoughty with minimal input from me. Feedback from scientists included:
  • "very happy" (in relation to making continuous scans get decent statistics much faster)
  • "that's very useful for many different types of scan" (in relation to adaptive scans)
• Tested:
  • Continuous-motion laser scan - worked well, comparing to a 6-7 minute continuous motion scan previously, we can get equivalent statistics in about 30-40 seconds using bluesky (mostly due to more efficient CA & matplotlib usage, meaning we sample more points from the galil). Tested this on sample changer and aperture axes, worked well in both cases using a trapezoid fit.
  • Step scans with neutrons - worked fine
  • Adaptive scans with neutrons - worked fine
• Issues spotted:
  • Bluesky CoM callback didn't work well with one of the continuous scans - may have either been getting confused with non-constant point spacing, or with negative intensities or similar. Need to debug this offline and either fix upstream or write our own (prefer to fix upstream if possible)
  • Logging re-appeared again, different cause to last time, but we might need logger.propagate = False which is bad practice generally but 🤷 might be the best we can do...
  • DAE on LOQ seemed much slower than CRISP to pause/resume/change periods, not sure if this is just a DAE2 thing. Means that neutron step scans are quite painful even counting for relatively few frames.

Will show to a couple of other members of SANS group tomorrow - but general feedback from this test is that this is covering SANS use-cases well so far (excluding the spin-echo/polarization use-cases, mostly on larmor)

[FreddieAkeroyd]

CRISP is DAE2 like LOQ. Was the CRISP scan done in histogram rather than event mode? A PAUSE is probably faster in histogram mode, just due to the fact that the ICP downloads remaining events before saying the command is complete - it probably doesn't need to do this, even if you change period the previous period number should still have been written in unread events.

[Tom-Willemsen]

Ah I didn't think to check histogram/event. On LOQ today looks like we were running in histogram though, using tables ending _wiring8.dat so don't have the usual _event.dat...

[Tom-Willemsen]

We did try briefly with just one time bin set in TCBs but that didn't seem to help significantly (on LOQ).

[FreddieAkeroyd]

in icp pause took 2 seconds, resume was 1, period change itself i think was quick, theer are just gaps between these commands being executed. were you moving motors etc or expecting to run one command after the other?

[Tom-Willemsen]

Here's an example for pausing:

2024-12-03 17:38:07,475 (9892) ibex_bluesky_core.devices.simpledae.controllers controllers.py [line:92] INFO stop counting
2024-12-03 17:38:12,840 (9892) ibex_bluesky_core.devices.simpledae.reducers reducers.py [line:173] INFO starting reduction

The only things that happen between those two log messages are:

        await dae.controls.pause_run.trigger(wait=True, timeout=None)
        await wait_for_value(dae.run_state, RunstateEnum.PAUSED, timeout=10)

i.e. a put with completion callback to PAUSERUN and then wait for RUNSTATE pv to catch up.

---

I tried with just a caput and camonitor just to eliminate any bluesky stuff, and see similar behaviour, about 4.5 seconds between writing to PAUSERUN and getting to a PAUSED runstate (on LOQ just now):

c:\Instrument\Apps\EPICS>camonitor IN:LOQ:DAE:RUNSTATE IN:LOQ:DAE:PAUSERUN
...
IN:LOQ:DAE:PAUSERUN            2024-12-03 21:32:30.267985 1
IN:LOQ:DAE:RUNSTATE            2024-12-03 21:32:31.787433 PAUSING
IN:LOQ:DAE:RUNSTATE            2024-12-03 21:32:34.732146 PAUSED

RESUME is a bit less but still almost 2 seconds between poking RESUMERUN and getting into RUNNING:

IN:LOQ:DAE:RESUMERUN           2024-12-03 21:35:49.410770 1
IN:LOQ:DAE:RUNSTATE            2024-12-03 21:35:49.411022 RESUMING
IN:LOQ:DAE:RUNSTATE            2024-12-03 21:35:51.197903 RUNNING

[FreddieAkeroyd]

Do you need to wait for runstate? The completion callback on pause should be enough?

[FreddieAkeroyd]

if you don't do anything other than change period between pause and resume, the attached PR may be quicker

[Tom-Willemsen]

We also move the motors during pause as well as changing periods currently

[FreddieAkeroyd]

i guess it would do for a continuous scan

[Tom-Willemsen]

Yes, that icp/isisdae change you linked probably would help with continuous scans, though we should probably talk about continuous scanning with DAE in-person sometime if we want to do it & decide how we want to do it... I'm not quite clear yet on exactly what a DAE continuous scan would look like in our current model.

[Tom-Willemsen]

Going back to your previous question about whether we need to wait for RUNSTATE, I think it's actually the completion callback that is the slow bit. not waiting for the runstate pv:

From genie_python:

st = time.time();g.pause();sto = time.time()
** Pausing Run 00111436 at 22:09:01 03/12/24 
sto - st
Out[33]: 5.069547176361084
st = time.time();g.resume();sto = time.time()
** Resuming Run 00111436 at 22:09:19 03/12/24 
sto - st
Out[35]: 3.183854579925537

Which is just doing self._set_pv_value(self._get_dae_pv_name("resumerun", base=not prepost), 1, wait=True) and not waiting for the runstate PV as it's only substantive line - so similar timings again.

[Tom-Willemsen]

Also now shown to SK on LOQ, who very much liked this and said it's "very nice that it's so much faster than previous scans" (and although I didn't demo a neutron adaptive scan to Steve, he seemed to like the concept of that too).