I have a case with a 1048-TemperatureSensor 4-Input where I can attach the phidget using the P21 libs and then attach it with the P22 libs. There is no indication of trouble with the P21client, but I stop receiving update events. Attempts to detach and reattach the phidget fail. If I attach the 1048 to the P22 client first, I am unable to attach it with teh P21 client.
Question: Is this known behavior, and, if so, is there a work-around?
This shouldn't be possible- the P22 open() call should fail with an error saying that the device is already in use. Are you sure the P22 client is actually attaching and getting data from the 1048? What programming language are you using?
Being unable to attach with P21 while it's open in P22 is expected.
Ok... just verified. With the device unattached to anything, I can then attach it using P21. Then, using P22 I can also attach it and immediately see incoming data. Meanwhile, the P21 client does not get a detach event, so thinks it is still attached. But, gets no updates. Forcing the P21 client to try to attach results in the expected error reported in my original post.
I just tried to do the same thing using both our Phidget21 and Phidget22 python examples for the 1048 and got a "Timed out" exception from the Phidget22 program as expected. What version of each library are you running?
You can test again with our examples (TemperatureSensor.py for 21 and the example from the 1048's product page for 22) to replicate the same conditions I just used.
I am on Phidget22 - Version 1.7 - Built Jul 6 2021 11:31:54
The code is a plugin for another program so I am not running the code directly. However, I can reliably attach the device with the plugin version based on p21, and then attach with the new plugin based on p22. As previously noted, the opposite fails as expected.
If part of the code is baked into a plugin, it's going to be hard to know for sure what is happening.
On a hunch I tried opening the Phidget remotely in 21 and 22 using python while running either the 21 webservice or the 22 network server, but I still got the expected results.
The only thing I can think of that the plugin could be doing is perhaps it's constantly closing and reopening the channel (we've definitely had some users program this way, thinking that they need close the device in each iteration of their loop), so the 22 program has a chance to grab the channel right after it's closed. If the plugin isn't doing anything with error events or exceptions, it would make sense that it would just silently stop reporting data when it fails to reopen the channel in this case.
