Should state be persistent when closing phidget channel or not?

Comments & issues
jochenparmentier
Fresh meat
Posts: 1
Joined: Wed Jan 10, 2018 3:40 am
Contact:

Should state be persistent when closing phidget channel or not?

Postby jochenparmentier » Wed Jan 10, 2018 4:13 am

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
Labview Developer
Posts: 15
Joined: Mon Nov 13, 2017 10:20 am
Contact:

Re: Should state be persistent when closing phidget channel or not?

Postby jdecoux » Fri Jan 12, 2018 11:41 am

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.

User avatar
Patrick
Lead Developer
Posts: 2987
Joined: Mon Jun 20, 2005 8:46 am
Location: Canada
Contact:

Re: Should state be persistent when closing phidget channel or not?

Postby Patrick » Fri Jan 12, 2018 12:33 pm

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


Return to “General”

Who is online

Users browsing this forum: No registered users and 2 guests