HPInc / HP-Digital-Microfluidics

HP Digital Microfluidics Software Platform and Libraries
MIT License
3 stars 1 forks source link

Better handle system component unavailability #193

Open EvanKirshenbaum opened 8 months ago

EvanKirshenbaum commented 8 months ago

Mark noted (#192) that it's possible for the OT2's ProtocolManager to determine that it can't actually talk to the robot. Since this happens when the ProtocolManager (a Thread) is started within OT2.join_system(), we can't simply raise and catch an exception. We could wait for some sort of signal, but it may well be that the protocol we're running doesn't actually use the robot and so won't care, so there's no point in complaining (other than perhaps a message), much less dying, unless we have to.

For this specific case, we could add a property to ProtocolManager that's a Delayed[bool] that gets set to True or False based on whether it succeeds in establishing contact with the robot. Then, in OT2.join_system(), we could use its value (which waits) to ensure that it will work, likely raising an exception if necessary.

More generally, we may want to have a settable property on SystemComponent that tells whether the join succeeded, or, more generally, whether the component is available. This could either be a Delayed[bool] or, if we think that an available component could become unavailable, a more general tri-state or monitored property.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Aug 10, 2022 at 2:18 PM PDT.