Position Based Flyscanning on p99

[gkalua]

• Refine plan
• Connect PVs
• Find out if it is possible to remotely reboot the PandA - Not possible
• Bring p99 up to date - launching phoebus
• Containerise and redeploy pmac IOC
• Add issue for calculating/validating velocity and positions from plan (add to ophyd-async)
• Add Issue for revising error message in velocity profile.

[gkalua]

Blocked - because the PVs are not connecting properly.

[gkalua]

• Seen that the argocd image references a pandablocks ioc, should be a fastcs one
• Previously fixed issue was not merged
• Merge request created

[gkalua]

I discovered that manually rebooting the PandA made it discoverable again.
When running a scan for the first time, remember to set the OutDataset PV to have a text.

[gkalua]

An error where the offset and scale are being read from the read back value rather than the actual value is still persisting even after checking out the right branch.

The PCAP not activew issue is persisting, tried to observe the connections on the beamline to see if I could make any changes, will speak to TC about it. Need to properly define the problem

[gkalua]

• Need to have visibility on the pmac & panda

[gkalua]

• Noticed that pvget et al don't work all the time
• Is the Pva tool meant for just some PVs?
• Why does it timeout sometimes but not other times

The total points are not being passed to the Pmac (BL99P-MO-STEP-01:TotalPoints_RBV) is not being updated and the PCAP of the panda as well. It is the same problem.

• I need to see a list of PVs associated with a process

• Is PVI table restricted to certain devices?

• Learnt that using 'launcher' ssh'd onto P99's network, you can have access to the edm screen

• TC advised to use copilot to locate the bob files of interest (kubernetes -> ingress)

• Only containerised IOCs can be accessed via phoebus and PVI (pvatools)

• The goal afterwards is to containerise P99

• The reason for the Pcap active error and the pmac_trajectory error might be because of speed, or wrong axes, edm screens will help

• Error messages should be noted and synchronised in ophyd-async

• Panda waits forever and does not go back to idle when trajectory fails because a motor stalls

• Does the duration refer to each collection window? or the total collection windoW?

• Was able to do a snaked scan when I reset the duration

[gkalua]

Successfully performed a flyscan - Line.

Steps:

• Opened VSCode in the imaging bluesky repo
• Wrote the plan ensuring to import dependencies and the devices
• Writing the PVs properly
• 'Physically' prepped; PandA and Pmac.
• Rebooted the panda and set at least one of the datasets to have a name.
• checked the pmac's limits (and saw the error was because it was moving too fast)
• PosOutError does not affect runtime

[gkalua]

Identified the same issue of pcap not being active. Does not make any sense.

Also realised the importance of validating a spec based on the hardware limits. Think that something like this should lie in the plan level for now

[gkalua]

Spoke to TC about the hardware limits issue.
Before this, I was able to trace the error to the velocity profile file.
The checks are happening for the run-up and for the gaps, but does not take the collection window velocity limits into consideration.

It makes sense to revise the velocity profile error message to include the values, might help with troubleshooting

It also makes sense to add logic to Pmac Generation and its predecessors for the velocity and positions, to ensure that the limit isn't being hit.

PmacMotorInfo should also expose the limits of the motor, since we are gathering the info, might as well kill two birds with one stone. Use verbose error messaging to make it clear to the 'user' what to update.

[gkalua]

• Connect the pandabox to the panda using FMC 24V
• Now we might need to pass two specs, because of synchronisation. Will be addressed in scanspec 2.

[gkalua]

Restarting the panda Ioc (& the panda?) seems to reset the datasets PV and makes them nameless.
It is essential that the datasets have a name before a scan is run - when declare a stream is called.

This is currently fixed by setting any of the PVs manually, this should be done automatically by adding this to panda_settings in the plan.

Eventually, all this will be addressed in the in the design of pandas; determining the deadtime based on the spec and the detector, and the restoration/loading of panda settings.