I am a software developer working for a consultancy company and we have been using your Phidgets in our projects for a while now.
We're using configurations where we combine up to 12 phidget controllers in one setup.
Up until now, we were using the Phidget21 driver and accessing the Python API to drive the phidgets.
Because we've been experiencing some stability problems with the phidgets, we wanted to try the Phidget22 driver and evaluate whether the stability was better.
However, we've ran into a couple of issues during the migration and I have some questions for you guys.
The intended way of using a phidget object seems to be the following:
1: Create an object (for example DigitalOutput())
2: Specify the serial number and channel of the destination phidget
3: Open the channel and wait for attachment
4: Set the desired state of your output channel or read from your input channel
5: Close the channel/object
This seems to imply that closing a channel will not affect the state of the output (ie, the state is persistent).
In the Phidget21 documentation, this behavior is even mentioned:
"Also note that a device should be put into a known state before calling close. For example, if a motor controller is driving a motor and close is called, it will continue to drive the motor even though the application has exited. This may or may not be what you want. This is a result of the fact that all Phidgets boards will maintain their current state until they are powered down (physically detached from the computer), even when they are closed by the current application."
Source: https://www.phidgets.com/docs21/General ... he_Phidget
In the documentation of Phidget22, this behavior isn't mentioned any longer but it also isn't documented that it would lose its state.
Actual tests on our end have verified that the behavior of the phidgets is to release their state and revert to their initial state after closing the phidget object.
This means that when we set a DigitalOutput to state 1 that it reverts back to state 0 after closing the phidget object.
I want to know whether this is the intended behavior of the phidget controllers. Since we are using so many phidget controllers (and thus objects) in one project, handling the phidget objects becomes more complicated. It seemed like using the suggested workflow (first opening the channel, setting the state and afterwards closing the channel) would simplify this for us.
Because the phidgets don't hold their state after closing and we need the controllers to have a persistent state, we are now opening all of the channels that we expect to use, keep them opened and attached for the lifetime of our application and close them when exiting the application.
We have a feeling that this is not how the phidget objects were meant to be used and it creates the complexity of handling these opened channels as shared resource between threads (since a channel can only be opened once).
Could you give us some support here? What is the expected behavior of the phidget controller when closing a channel? Should it keep its state or shouldn't it?
If it shouldn't keep its state, what is your suggested way of handling all of these opened channels within our application? We are now storing each of them in a singleton with controlled access to prevent different threads from accessing them at the same time but we're still experiencing some instability and PhidgetExceptions.
Our use case for the Phidgets are test automation projects that we implement for clients. Complete stability and reliability is our first priority so if I'm being honest this whole situation is starting to make us doubt wheter Phidgets are a suitable product for our use case. Hopefully you guys have some pointers for us so that we can get this sorted out.