Add j120k flowswitch, insert flow switch in appropriate classes.

[nrwslac]

Description

• added new module digital_signals.py
• added new class J120K
• added J120K to SxrTestAbsorber, XPIM, IM2K0, PowerSlits
• created new class PPMCoolSwitch, WaveFrontSensorTargetCool

Motivation and Context

Where all devices in the happi database will get the cooling switch added J120K to the class. For devices who otherwise aren't all the same I inherited the base class.

How Has This Been Tested?

• Opened typhos screen from happi database where class name didn't change with local python environment and checked for flow_ok signal
• Opened typhos screens with manual module declaration where class name was different than happi database.
• All screens opened correctly.
• Opened a hutch python session with local python module and checked flow switch property reports:
• In [8]: sw.flow_switch.get_flow_ok
• Out[8]: 1

Where Has This Been Documented?

pcdshub/lcls-plc-kfe-motion#120
https://docs.google.com/spreadsheets/d/1UAVYuG5my1ic51wRrpq9xJfvT5X7NX-nF4QzPtAUaPg/edit#gid=0

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]

Is there a list of device that will have their device_class changed in happi? (will there be? I assumed so with the addition of new devices)

I went through and looked at devices whose class had the flow switch added, and the following didn't have active *:FLOW_OK_RBV pvs:

• im1l0
• im2l0
• im4l0
• sl1l0

[nrwslac]

Is there a list of device that will have their device_class changed in happi? (will there be? I assumed so with the addition of new devices)

I went through and looked at devices whose class had the flow switch added, and the following didn't have active *:FLOW_OK_RBV pvs:

• im1l0
• im2l0
• im4l0
• sl1l0

These aren't implement yet, but will be in a month or two. I guess this will break the PV connection temporarily.

[tangkong]

These aren't implement yet, but will be in a month or two. I guess this will break the PV connection temporarily.

This didn't prevent the devices from loading, so it's not a huge deal. It'll just fail if we try to wait_for_connection on the devices

[nrwslac]

Is there a list of device that will have their device_class changed in happi? (will there be? I assumed so with the addition of new devices)

I went through and looked at devices whose class had the flow switch added, and the following didn't have active *:FLOW_OK_RBV pvs:

• im1l0
• im2l0
• im4l0
• sl1l0

Entries for pf1k0 and im1k3 will currently need to be updated. Corresponding to WaveFrontSensorTargetCool and PPMCoolSwitch

[ZLLentz]

A few more thoughts, though I'm totally splitting hairs at this point:

• Why does this property exist? Is flow_ok.get() insufficient as an API? (I do see that it returns an int and not a bool)
• If there's a reason for it to exist, why is it a property and not a method?
• If there's a good reason for it to be a property, why is it named like a function? I think people in an interactive session will very likely do a get_flow_ok() call which will give an annoying "type bool is not callable" sort of error.

[nrwslac]

This is actually totally true, I did this myself. I'll delete it. I thought people would want a designated function, but in this case it should drop the property tag. I also did not think about the fact that you can just call get on the signal.

[ZLLentz]

ok, sounds good- I would have been fine with any outcome here, just trying to make sure we consider these small details

[ZLLentz]

looks good to me