I have an RTD Phidget (ID: TMP1200_0) that I control using Python 3.8.5 and Phidget22==1.6.20200921.
I have it reading the resistance of a 2-wire thermistor (nominal resistance of 2252 Ω) around room temperature. In software, I have its RTDWireSetup = Phidget22.RTDWireSetup.RTDWireSetup.RTD_WIRE_SETUP_2WIRE. The hardware has the EXC+ jumpered to RTD+, and EXC- jumpered to RTD-. It works great in the nominal case.
When I disconnect the thermistor, via the error event handler, I can see it properly raises an Error event with the code 0x1009 (EEPHIDGET_SATURATION).
What is most desirable for me is to avoid using the error handler. I try calling getResistance() while the thermistor is unplugged. What currently happens is the PhidgetException thrown has error code 0x33 = EPHIDGET_UNKNOWNVAL. I think the difference lies in ErrorCode (0x33) vs ErrorEventCode (0x1009).
Here are my questions:
[*] Is ErrorCode 0x33 == ErrorEventCode 0x1009 for TMP1200? In other words, when I get ErrorCode 0x33, can I conclude that it means there's a Saturation event happening?
[*] Is there some way to get any active error events with a method call? I looked at the Phidget API, and didn't see anything particular.
getResistance() returns EPHIDGET_UNKNOWNVAL since due to saturation, the device doesn't know what the resistance is. The device will return this error any time it is polled and doesn't have a recently calculated resistance. This is usually during a saturation for the TMP1200, but also can happen when the device has been opened but has not yet calculated the resistance before being polled.
EEPHIDGET_SATURATION is thrown by the error handler to let you know that the device is in a saturated state.
So to answer your Qs,
1. They are not equal, but are related most of the time. It's not safe to assume all EPHIDGET_UNKNOWNVAL return codes are due to saturation, but I would say it's safe to say most are, under normal operation.
2. To the best of my knowledge, there aren't any methods that provide all current errors. Definitely not on a per-channel basis in the API. But you could use the error handler to keep a running state of recent errors and make your own method to poll for those.
But it's possible there's another way to poll for errors I'm not aware of...
Thank you @fraser for the response, and for informing of other possible causes of EPHIDGET_UNKNOWNVAL.
I ended up implementing something that entails:
1. Recording the most recent error event with a timestamp
2. Upon getResistance, if it throws EPHIDGET_UNKNOWNVAL, then look at the recorded error event
3. If the timestamp was sooner than the Phidget's data interval, and the code was EEPHIDGET_SATURATION, then one can throw an exception tailored to a saturation event.
