Convert from Phidget21 to 22

[StanGreen]

I have a 32bit Java application I am trying to convert to 64bit. The application allows for control of multiple "1014 - PhidgetInterfaceKit 0/0/4 Version 707". I make extensive use of the InterfaceKitPhidget class in Phidget21. It seems that this class has been removed in Phidget22.jar. I cannot find any documentation on how to make this conversion. The Phidgets control app still finds the devices so I know it can be done.

What is the way to convert from 21 to 22?

Thanks,
Stan

[LucasP]

This page should help: https://www.phidgets.com/docs/Upgrading ... _Phidget22

[StanGreen]

This is such a pain. Why not simply create a wrapper class so as not to break applications! I think the best thing for me to do is to write my own wrapper class. Again, I should not have to do this.

[Patrick]

phidget21 is still supported - why make the switch?

-Patrick

[hcfman]

I think because the Phidget21 code relied on a USB library that is no longer being distributed on Linux systems. I have the same problem.

[hcfman]

I have another question. The API show's how to attach call backs for various events and to create a digital output object. However, the example Java code does not make it clear what happens after a detach event. If a detach event is received for an interfacekit with a specific serial number, what happens to the call to change the output or this now detached interfacekit?

Also, what would happen if the interfacekit that was detached would suddenly because re-attached again? Is the previously received object still valid? Or would new ones need to be created? Are the callbacks that were set on the previous object automatically cleaned up so they are not called in the case that the interfacekit became reattached?

Kim Hendrikse

[mparadis]

If you try to get or set a property of a detached channel, you'll get the EPHIDGET_NOTATTACHED exception.

If a channel detaches and then reattaches (e.g. unplug and replug the USB or VINT cable), You'll get a detach event, followed by an attach event if you've registered the handlers for those events. The same software object used to talk to the old channel can continue to interact with the reattached channel. If you handle your attach and detach events cleanly, your program will be resilient to brief detaches that could be caused by interference or temporary power issues.

It's worth mentioning that you should be specific with your addressing parameters (serial number, port, channel) when you open, because if you're not, it'll match with the first channel it finds that fits, so you could have a situation where the channel detaches and then a different channel attaches to that object. Setting the addressing parameters will guarantee that you always have the same channel reattaching.

[hcfman]

Thanks. So if you get a re-attach event on the object, are the callbacks that you applies re-instated? I guess that's like asking if I haven't called a close on the object, will the callbacks still be active if that particular phidget re-attaches?

Can I call the close upon the detach event and then create a new object as a way of working? Which is also like saying does everything clean up upon the calling of a close on the object?

Note that now that the close call applies just to a single digital input or output object and the detach callback in principle happens to all jobs associated with a device does this not raised the possibility of a race condition whereby you have a detach event and you start to close all of the digital inputs and outputs associated with that device and then you get a re-attach, leaving the status for the complete device such that some digital inputs or outputs are closed and others are open and active?

Kim Hendrikse

[mparadis]

If a channel detaches and reattaches, any callback functions (event handlers) that you have assigned will still be there, because they're still associated to the software object you used to open the channel in the first place.

Think of it like this- when you declare the object and set parameters and callbacks, this is like making a house. When you call open(), you unlock the door so the channel can go inside and work in the house. Sometimes, the channel might detach and leave the house (USB unplugged, interference, etc). The house is still there and the door is open so it can reattach. When you call close(), you push the channel out of the house and lock the door. One of the big changes with Phidget22 is that there are houses for each input and output on the InterfaceKit, whereas in Phidget21 there is just one big house for everything on that board.

I hope this illustrates why there's no good reason to call close() from the detach handler only to go through the work of calling open() again.

Note that now that the close call applies just to a single digital input or output object and the detach callback in principle happens to all jobs associated with a device

Close() applies to a single channel, yes. The detach event handler can apply to a single channel, or it can apply to multiple depending on how you assign them. If you apply it to multiple, you can check the channel index of the sender using e.getSource() (where 'e' is the event args) to avoid doing things to the wrong channel. You can certainly have situations where some channels are open and some are not, and that's intentional in Phidget22.

[hcfman]

Thanks for the detailed explanation, it's clearer now. The main reason for closing them all and re-opening them all is to simply code that dynamically changes all characters relating to devices of interest/operations on those devices. Say in response to a gui operation that changes everything on the fly.

But now you have explained it, I can give thought to provide some kind of synchronization to avoid race conditions.

Kim Hendrikse