Best Phidgets Practices

The purpose of this page is to provide a list of "Best Practices" to follow when writing code that uses Phidgets. These "Best Practices" are designed to eliminate common mistakes made when using the Phidget22 API, and to help maintain an stable structure while build more complicated systems.

Use Event Handlers

The Phidget library supports both polling channel properties to determine state and to get current data values, and the library supports firing events when states change and data is received. Reading channel properties directly is useful to determine the state or current data value at a point in time, but is difficult to implement correctly. Event handlers are more predicable and easier to implement correctly. Unless a program has a specific and obvious reason to access properties directly, event handlers should be used.

Keep Event Handlers Short

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 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. After the class, 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 hub 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 would be the 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 each time a channel is matched. This makes the attach handler the perfect place to initialize properties such as DataInterval, ChangeTrigger, gain values, and ranges. If properties are initialize elsewhere, in a situation where the channel detaches those properties will revert to defaults. Setting properties within the attach handler ensures they are always the expected values.

Don't Forget to Close()

Calling Close() on a channel releases the channel so that it can be matched again. In most cases, it's not technically necessary to call Close() because when your program exits, the channel will be released; however, it is good practice to close a channel when you are finished with it as some environments will not release the channel automatically. For example in LabVIEW, the runtime environment merely interprets your program, so if you do not call Close(), 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.