Best Phidgets Practices: Difference between revisions
No edit summary |
|||
Line 39: | Line 39: | ||
== Don't Forget to Close() == | == Don't Forget to Close() == | ||
Calling {{Code|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 {{Code|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 {{Code|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 [[Language_-_LabVIEW|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. |
Revision as of 19:11, 3 May 2017
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.