FIX: patch over positioner limits = (None, None) issue

[klauer]

Description

• obj.limits can be (None, None) in some (perhaps?) disconnected/misconfigured devices.
• These limits may not have an associated component, and may be derived directly from the control layer (i.e., EPICS CA PV low/high limits)
• This PR detects the presence of None and currently hides the limits

For discussion: on connection, it's possible those limits could go to an actual not-None value. In that scenario, this PR would have already hidden the limit widgets and they would not be displayed later.

Motivation and Context

Aims to close #565

How Has This Been Tested?

With the "all device screenshot test" mentioned in side channels

Where Has This Been Documented?

Issue and PR text

[klauer]

Any thoughts on what we should do here, @tangkong @ZLLentz ?

[ZLLentz]

I'm doing a short investigation to understand why and in which cases this would be explicitly (None, None) instead of just None or (0, 0)

[ZLLentz]

OK, I see it now- we hit (None, None) if all the PVs in a PVPositioner are disconnected, or if at least there was no limits arg passed and the setpoint is disconnected. In a vanilla EpicsMotor we raise a DisconnectedError instead, in our EpicsMotorInterface class this ends up being (0, 0) because we do some post-normalization.

[ZLLentz]

One more important piece of context information: this is also just a fallback for when we don't have signals that directly report the low and high limit values.

[ZLLentz]

It might be possible to have one more fallback that is subscribing to the setpoint PV's metadata callback- but other than that, there's not that much more we can do if we want to rely on an attribute instead of a signal.

[klauer]

I think you're right. What gave me pause mostly was the fact that we hide the limit widgets in this scenario - perhaps we just say "well, show the widgets at least so they can be set"

... In typing the above, though, I think there's no method for setting .limits with these widgets (in the fallback scenario you accurately described in this comment) - right? Or am I missing it?

[ZLLentz]

Right, these widgets are read-only. I think they are just the little text tags that go under the limit switch indicators.

[tangkong]

This looks right to me, pending pre-release notes.

I wonder if there are similar portions of typhos that have issues with unfilled/un-initialized signals/values. I suppose we'll find them as we go