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

Event handlers (specifically the ones that handle data "change" events) are constantly being put on the stack as data comes in on your typical Phidget program. The purpose of these handlers is to give you an opportunity to process each point of data that comes in. For example, you might convert a temperature reading from Celsius to Kelvin, or you might perform a rolling average on data coming in from your load cell. However, problems can arise if you try to do too much in your event handler. Actually, it has less to do with the amount of code and more to do with the type of code that's in your handler.

Imagine you have an accelerometer that's sending acceleration data every 20 milliseconds. If your change handler takes 21ms to execute, the next data point will be ready before the previous one is done being processed. Now, occasionally going over-time is not a problem, since the Phidgets drivers will queue up to 500 data points before it starts dropping (ignoring) data points. But if your handler consistently takes longer than your sensor's data interval, you're not going to be able to keep up.

You can keep the execution time of your event handlers down by avoiding the use of notoriously time-expensive tasks, or by using a separate thread to handle these aspects. Some such tasks include:

Updating GUI elements
Waiting for user input
Writing to a file

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.

Personal tools

Views

More

Tools

Best Phidgets Practices

Contents

Keep Event Handlers Short

Be Specific With Open()

When In Doubt, Open Remotely

Set Properties in the Attach Handler

Don't Forget to Close()

Further Reading

Navigation menu