Adds except for caget failure

[jlashner]

Adds exception for epics channel access get failure in pysmurf-controller check-state. I believe this should make the check-state function more robust by preventing the behavior seen in #575 .

Description

Excepts caget failures in check_state

Motivation and Context

#575

How Has This Been Tested?

Not tested yet

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[BrianJKoopman]

This looks fine to me for catching in the check_state process, but seeing bias steps occasionally see similar behavior (https://github.com/simonsobs/daq-discussions/discussions/59) makes me wonder if this handling is needed throughout. Maybe that goes in a separate PR, but I'd be interested to hear your thoughts.

Also, this adds pyepics as a direct dependency of socs when dealing with the pysmurf controller agent. We should add it to setup.py. I'm happy to do that bit if you'd like. Either way it should be done before merging.

[jlashner]

Ya... I think we want other operations to fail though in the event of an epics failure, where we don't really ever want the check_state process to stop running, so I don't think we should change the other tasks until we understand the source of the issue.

pyepics was already a dependency through sodetlib and pysmurf, so I don't think this actually adds any new dependencies... Dependencies for this agent were all handled because it is run in its own docker that is built on the so-smurf stack, rather than through setup.py

[BrianJKoopman]

pyepics was already a dependency through sodetlib and pysmurf, so I don't think this actually adds any new dependencies... Dependencies for this agent were all handled because it is run in its own docker that is built on the so-smurf stack, rather than through setup.py

Right, but now that we're directly importing it in socs code it makes sense to track here, rather than rely on it being pulled in by another dep. I added it with the needed docs in c7792e6.

[jlashner]

If that's the case, should we also uncomment the pysmurf, sodetlib, and sotodlib reqs?

[BrianJKoopman]

If that's the case, should we also uncomment the pysmurf, sodetlib, and sotodlib reqs?

In the setup.py file? Direct references can't be packaged like that. If pysmurf, sodetlib, and sotodlib publish to PyPI we could.

[jlashner]

Ok, I'm fine w/ merging this but am still pretty confused by it. Maybe it makes sense for tracking / docs, but

pip install -U socs[pysmurf]

will never really be sufficient for running the agent outside of the docker

[BrianJKoopman]

Ok, I'm fine w/ merging this but am still pretty confused by it. Maybe it makes sense for tracking / docs, but

pip install -U socs[pysmurf]

will never really be sufficient for running the agent outside of the docker

True, that's why there's the dependencies section on the agent page: https://socs--576.org.readthedocs.build/en/576/agents/pysmurf-controller.html#dependencies

This is pointed to from the installation page. I agree it's not ideal. But the best solution is to get those packages to publish to PyPI.