Should state be persistent when closing phidget channel or not?

[jochenparmentier]

Hello

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.

[jdecoux]

The intended behavior for Phidgets in Phidget22 is to return to an "off" state after they are closed.

This mode of operation allows you to keep track of a Phidget's state at all times while it is in use.

We will make a note of this change in our documentation for future reference.

As for a solution to your specific problem, it sounds like you may want to try using the Phidget Network Server. This would allow you to open a Phidget as many times as necessary, while the state of a device will persist so long as one copy of it is open on the network server.

https://www.phidgets.com/docs/Phidget_Network_Server

In essence, to start you could use a master thread to open a local instance of a Phidget Network Server and open all your devices as "remote" at the start of your program to keep them open. Once the devices have been established you can then open them again from another process, make your changes, and close the Phidget in that process, while the Phidget remains open (keeping its state) in the master thread.

[Patrick]

phidget22 resets device state both during open, and during close. This is to ensure that the state of a device is predictable when you open it. We may in future offer an API to disable this functionality, to make phidget22 more like phidget21.

It's not generally a good idea to count on the state of a Phidget that you don't have explicitly opened, because unexpected detaches can happen at any time, and these should be handled by your code. Closing a device also has the possibility of another program opening it. In reality, these may be non-issues, but it's still a good idea to keep your handles open as long as you need an output set.

What issues are you having with phidget21? This older API is still being supported, and there is generally no reason to move to phidget22 unless you want to start using VINT devices.

-Patrick

[skeelaj]

"phidget22 resets device state both during open, and during close. This is to ensure that the state of a device is predictable when you open it. We may in future offer an API to disable this functionality, to make phidget22 more like phidget21."

Patrick,

Any updates or place I could monitor for "We may in future offer an API to disable this functionality"?

[Patrick]

Hi,

This is still on the todo list but I don't know when it will be ready. I'll post here if we have updates in the future.

-Patrick

[xsdg]

I'm using the 16-way SSR to control power to some devices. I need the outputs to generally be on (connected), and I'm making a power-cycle script to set them off, wait for a bit, set them on again, and exit.

I'm using the Python API, and found that if I use "finalize" when I want to freeze the output state, it seems to do what I want. It prints an error message on exit, but that seems to only be cosmetic.

So in short if I modify the demo app in this way, it does what I need (with the understanding that the output reset on opening the output is inconsequential for my usecase, even though that might be non-ideal for other usecases):

Code: Select all

# powercycle script
def main():
        digitalOutput0 = DigitalOutput()

        digitalOutput0.openWaitForAttachment(5000)

        # digitalOutput0.setDutyCycle(1)
        digitalOutput0.setState(False)

        # try:
        #         input("Press Enter to Stop\n")
        # except (Exception, KeyboardInterrupt):
        #         pass
        time.sleep(5)

        digitalOutput0.setState(True)
        #digitalOutput0.close()
        digitalOutput0.finalize(0)