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.

Check Results

Almost every method in the Phidget22 API returns a result code, or throws an exception if the language supports exceptions. The result code must be checked, and any exception caught, to ensure each operation is successful. Ignoring results will in the best case cause programs to crash, and in the worst, lead to invalid or unexpected behavior.

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 Addressing

When you open a Phidget channel, the library try to attach a channel matching all the addressing properties that have been set. 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. If your program deals with multiple Phidgets, it is always wise to be specific.

For example, if a Phidget temperature sensor is the only device connected to a computer, opening a TemperatureSensor channel without setting any addressing properties will attach to that temperature sensor; however, if a DC motor controller is connected to the computer, the on-board temperature sensor on the motor controller might attach to the channel instead. This could be prevented by setting a DeviceSerialNumber or Template:HubPort.

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 functionally the same; 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 as other clients will still be able to attach to the device 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 temporarily, those properties will revert to defaults during the next attach. 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 a program exits, the channel will be released; however, it is good practice to close the channel when you are finished as some environments will not release the channel automatically. For example in LabVIEW, the runtime environment executes a program internally, so if Close() is not called, the LabVIEW environment will continue to tie up the channel despite the program having been stopped.

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.