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 gain access to a channel on a Phidgets device, it will try to find a channel of the object type that you're using (e.g. VoltageInput). There are also a number of properties you can set to narrow down which channel gets opened. For example:

• The serial number of the device or the VINT Hub that it's connected to
• The port it's connected to (if it's connected to a VINT Hub)
• The channel on the device, if it has multiple channels of the same object type
• Whether the channel is remote or is local
• The server name, if the device is being accessed over the Phidget Network Server

If you don't set these properties before calling Open(), the Phidgets software will grab the first channel that matches. In many cases, this will work just fine. For example, if I have a Phidget temperature sensor connected to my computer, and I try to open a TemperatureSensor object without setting any of these properties, it will still find and open the correct channel. But what if you also have a DC motor controller connected to your computer? If the motor controller has an on-board temperature sensing chip for safety purposes, opening a TemperatureSensor object could open either one.

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

When In Doubt, Open Remotely

When you use Open() to gain access to a channel on a Phidgets device, you can either open it locally or remotely (if you have the Network Server enabled). If a channel is opened locally, it can't be opened by any other client for as long as it remains opened. But if a channel is opened remotely, any number of clients can simultaneously connect to it (with the exception of certain devices like motor controllers). Because of this, it's advisable to open your channels remotely in most cases. This way, you'll always be able to open the channel, even if another instance of your program is running.

In cases where data rate is crucial (e.g. control loops or other time-sensitive processes) you may want to stick to local connections, since data rate is a bit lower over the network.

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.