Best Phidgets Practices

The purpose of this page is to provide you with a list of "Best Practices" to follow when writing code that uses Phidgets. These guidelines are especially important if your program is going to be used by people other than you, or on many different systems. If you follow these guidelines, you'll probably save yourself a few headaches in the future.

Keep Event Handlers Short

User events handlers are called from special dispatch threads within the Phidget library. Each channel maintains its own queue of events, and these events are processed in order and one at a time. If a user event handler blocks, or takes longer than the DataInterval of the channel, events will become 'stale', and eventually the system will begin throwing away events.

For example, if an Accelerometer channel has been configured to receive data every 20 milliseconds and the event handler averages 21ms to execute, the next change event will be ready before the previous one is finished being processed. Eventually the channel's event queue will fill and the library will begin throwing away events.

A common mistake is to update a GUI, or wait for user input from within an event handler. Most GUI APIs have support for dispatching updates to the GUI thread, and those should be used. Waiting for user input will block the event handler, and should never be done. Instead, a flag should be set and a loop in the main of the program (or another thread) should wait for the input.

Be Specific With Open()

When you use Open() to access a Phidget device channel, the library will first try to match a channel of the class that you're using. There are a number of other matching properties can be set to further filter which device channel is matched. For example:

• The serial number of a device or VINT Hub
• The port a VINT device is plugged into
• The channel number of a device channel, when a device has multiple channels of the same class
• If a channel is remote or is local
• The server name, if a device channel is being accessed over the Phidget Network Server

If none of the matching properties are set, the Phidget library will match the first channel of the same class. In simple cases this will be fine. For example, if a Phidget temperature sensor is the only device connected to a computer, opening a TemperatureSensor channel without setting any matching properties will match that temperature sensor; however, if a DC motor controller is connected to the computer, the on-board temperature sensor on the motor control may match. Setting the DeviceSerialNumber will force the channel to match the desired device channel.

Since there's no way to predict what other Phidgets may be plugged into a computer (or become available over the network), you should be as specific as possible before opening a channel.

When In Doubt, Open Remotely

When the Network Server is enabled, a channel can match both a local device channel and a remote channel. The end result is same as the same actual device channel would be attached; however, most remote channels support being attached to multiple clients, while a local device channel can only be attached once. Unless the desire is to only allow the device channel to be attached once, or performance is critical, it is more flexible to match the network channel.

See the IsRemote and IsLocal Phidget properties in the Phidget22 API.

Set Properties in the Attach Handler

An attach event will occur any time a channel is successfully opened. This makes the attach handler the perfect place to initialize all of your properties such as DataInterval, ChangeTrigger, gain values, and ranges. If you initialize elsewhere, in a situation where the Phidget briefly detaches due to electrical interference or power loss, you'll find that it will attach with the default settings on those properties.

Don't Forget to Close()

Calling Close() on a locally opened channel frees up the channel so that it can opened by another client. In most cases, it's not actually necessary to call Close() because as long as your program closes and the process ends, the channel will be freed up regardless. However, it's still a good practice to call Close() at the end of your program, because some programs and programming languages' processes will continue to run in the background and tie up the channel. For example in LabVIEW, the compiler merely interprets your program and runs the code under its own process. So if you open a channel without closing, the LabVIEW environment will continue to tie up the channel despite having stopped the program you're working on.

Further Reading

Phidget Programming Basics - Here you can find the basic concepts to help you get started with making your own programs that use Phidgets.

Data Interval/Change Trigger - Learn about these two properties that control how much data comes in from your sensors.

Using Multiple Phidgets - It can be difficult to figure out how to use more than one Phidget in your program. This page will guide you through the steps.

Polling vs. Events - Your program can gather data in either a polling-driven or event-driven manner. Learn the difference to determine which is best for your application.

Logging, Exceptions, and Errors - Learn about all the tools you can use to debug your program.

Phidget Network Server - Phidgets can be controlled and communicated with over your network- either wirelessly or over ethernet.