add smarpod as a device

[patoppermann]

Description

Add a new device class for smarpod and detailed UI.

Motivation and Context

We have a new device from SmarAct, this time a SmarPod.

How Has This Been Tested?

IOC connection was tested.

Where Has This Been Documented?

Doc in the Code

Pre-merge checklist

• Code works interactively
• Code contains descriptive docstrings, including context and API
• New/changed functions and methods are covered in the test suite where possible
• Test suite passes locally
• Test suite passes on GitHub Actions
• Ran docs/pre-release-notes.sh and created a pre-release documentation page
• Pre-release docs include context, functional descriptions, and contributors as appropriate

[tangkong]

I think this looks mostly good aside from styling issues. Try running pre-commit checks locally: Confluence page

(dev) $ pre-commit install  # run this only once
(dev) $ git add pcdsdevices/my_device.py   # add new things to the staging area
(dev) $ pre-commit run  # manually run pre-commit

[klauer]

This class will not play nicely with bluesky for the purposes of scanning as you've implemented it as a generic ophyd.Device.

There needs to be a Positioner somewhere for the smarpod.

More details here: https://confluence.slac.stanford.edu/display/PCDS/How+to+Create+an+Ophyd+Device#HowtoCreateanOphydDevice-PVPositioner

Consider the upstream source of this SmarPod IOC implementation and its corresponding ophyd device: https://github.com/NSLS-II-HXN/profile_collection/blob/d724c469b8c4ac1784ca755b40b1992b3e5d0640/startup/15-zp.py#L15-L38 (and further down where it's being used as a sub-device)

[ZLLentz]

Interesting, it looks like NSLS-II splits this kind of device into many different 1D positioners

[patoppermann]

PVPositioner was chosen as the class.
from ophyd import PVPositioner

[klauer]

Have you given this a try, @patoppermann? Like running it in Python and instantiating a SmarPod instance?

I ask because PVPositioner requires some components to be defined, which I don't see here: https://confluence.slac.stanford.edu/display/PCDS/How+to+Create+an+Ophyd+Device#HowtoCreateanOphydDevice-PVPositioner

PVPositioner should raise an exception if those are not set: see here

I'm not sure if a single PVPositioner will work for the SmarPod, since it has 6 DOF (x/y/z/rx/ry/rz) to check. Normally PVPositioner works with scalars, but maybe...

[klauer]

All of this is still really jumbled together. Consider that it might make more sense to shove status-related things into a SmarPodStatus device, which could then be instantiated with a Cpt(SmarPodStatus, ":STATUS") much like how I was talking about the poses.

[klauer]

There's SmarPod above and Smarpod here - two different classes.
The above one has everything but the poses. I think these should be merged somehow?

[klauer]

By the way, we have a page here: https://confluence.slac.stanford.edu/display/PCDS/How+to+add+a+device+to+pcdsdevices#Howtoaddadevicetopcdsdevices-Testing

Which goes through at least a bit of the process of instantiating your device and trying it out

[ZLLentz]

Hi, I have two minor suggestions.

It won't be possible to use this in a normal scan, but it's good that you've accumulated all the PVs. Perhaps in a follow-up we can add scanning behavior.

[ZLLentz]

I think you should remove this file unless you're planning to make a screen

[ZLLentz]

This should be good to go
There may be more adjustments later for various hutch needs as they arise but there is no reason to let it sit for another year