|
|
| (7 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| [[Category:Troubleshooting]] | | [[Category:Troubleshooting]] |
| __TOC__
| | __NOTOC__ |
|
| |
|
| ==Getting Started==
| | Although Phidgets are designed to be easy to use, they are actually a complex system with many levels of interfacing between the Phidget, cables, possible networking, operating systems, USB ports, the Phidget libraries, and ultimately your code. |
| ===Why you're here===
| |
| Although Phidgets are designed to be easy to use, they are actually a complex system with many levels of interfacing between the Phidget, cables, possible networking, operating systems, USB ports, the Phidget libraries, and ultimately your code. | |
| ===Not sure where your problem is?===
| |
| ====Code Issues====
| |
| If you are having issues with writing your own code, the first place to look is the {{Phidget22API}}.
| |
|
| |
|
| Otherwise, make sure your Phidget libraries are up-to-date. After installing the latest libraries, run one of our provided examples:
| | The easiest way to find the problem in your system is to run through some simple tests to rule out certain parts of the system. |
| *If the example works, check your code: [[#Code Troubleshooting|Code Troubleshooting]].
| |
| *If the example doesn't work, you may have a platform issue.
| |
| ====Platform Issues====
| |
| Plug in your Phidget and check the device manager or system logs:
| |
| *If the Phidget appears, see [[#Operating System Troubleshooting|Operating System Troubleshooting]].
| |
| *If the Phidget unreliably appears, you may have a communications issue.
| |
| ====Communication Issues====
| |
| Plug in your Phidget and check the device manager or system logs:
| |
| *If your Phidget sometimes appears in your system logs, see [[#Communications Troubleshooting|Communications Troubleshooting]].
| |
| *If it never appears, you may have a hardware issue.
| |
| ====Hardware Issues====
| |
| Use this process to debug the Phidget on a different computer. If it does not work on any computer, see [[#Device Troubleshooting|Device Troubleshooting]].
| |
|
| |
|
| ====Network Server Issues====
| |
| If you think you are having a Network Server issue, try running the Phidget locally. If the Phidget works locally, see [[#Network Server Troubleshooting|Network Server Troubleshooting]]
| |
|
| |
|
|
| |
|
| ==Code Troubleshooting==
| |
| To determine whether the problem is in your code, '''you should run the provided examples''' for [[Software Overview#Language Support|your programming language]].
| |
|
| |
|
| * If the examples run, the problem is within your code.
| | ==== Step 1: Test in Phidget Control Panel ==== |
| * If the examples do not run, the problem is at a lower level in the system. Read on to the [[#Operating System Troubleshooting|operating system troubleshooting]] section below.
| | [[Image:TMP1000_Panel.jpg|link=|right|300px]] |
|
| |
|
| '''If the problem is in your code:'''
| |
| :*Syntax help can be found in the {{Phidget22API}} and code snippets for [[Software Overview#Language Support|your programming language]]
| |
| :*High-level concept help (logging, catching errors, using the API) is on the [[General Phidget Programming]] page
| |
| :*Compiler help (linking libraries, running code) can be found on the [[Software Overview#Language Support | page for your language]]
| |
| :*Ensure you wait enough time for the Phidget to respond to your requests, such as when switching between ratiometric and non-ratiometric sensing, or to get and set device data.
| |
|
| |
|
| To download and run the examples, visit the page about [[Software Overview#Language Support | your programming language]]. The API section on the product page for your device [{{SERVER}} on our main website] will tell you the software object -- and thus example file name -- for your Phidget. Make sure to use either that object-specific example or the '"HelloWorld" example if one is available.
| |
|
| |
|
| When debugging, it helps to extract from your code what is known as a '''Minimum Reproducible Unit''' (MRU). This is the minimum lines of code that can reproduce the issue. We can help with this. An MRU will allow you to find what part of your use of Phidgets in code is causing the problem. Extracting an MRU is a powerful process which can not only isolate the problem, but also allow you to examine and organize your code. Also, it helps us debug your problem faster if you can show exactly what the problem is in the part of your code that deals with Phidgets.
| | Plug your Phidget into the computer test it using the [[Phidget Control Panel]] as outlined in the [[User Guides|User Guide]] for your device (For Linux users, just proceed to the step 2 instead). Choose the section that best matches the result you get and click on '''"Expand"''' to the right: |
| | <br clear="all"> |
| | ---- |
| | {{Collapse |
| | |The Phidget doesn't show up in the control panel |
| | |This often indicates an issue with your computer's operating system or the Phidget's hardware. First, go to the [[OS Troubleshooting]] page to make sure the Phidget can be seen on the USB, and then visit the [[Hardware Troubleshooting]] page. |
| | }} |
| | ---- |
| | {{Collapse |
| | |The Phidget shows up but the text or row is coloured red |
| | | |
| | [[File:Controlpanel_mac_firmwareupgrade.png|link=|300px|right]] |
|
| |
|
| If you have found problematic lines and want to see what is wrong, you can turn on '''Phidget logging'''. Logging can save and display many different levels of messages (errors, debugging, or even individual Phidget library actions) to either a file or the program console. You can find help to turn logging on and off in the [[Logging,_Exceptions,_and_Errors | Logging, Exceptions, and Errors]] page.
| | On MacOS, the red text means that a firmware update is available for your device. In older versions of the Windows control panel, the row may be red for the same reason (newer versions show a blue arrow instead). Double-clicking on the red bar or text will download and install the update, which should take less than a minute. If the firmware update fails, you may need to download the latest version of the Phidget drivers and try again. Once the device is updated and working, you can proceed to [[#Step 2: Test with our Sample Code|step 2]]. |
|
| |
|
| '''Note:''' We do not offer services to debug general (non-Phidgets) programming projects, or to develop code from scratch. We do, however, support any and all questions and suggestions about Phidgets and their use. So, if you have ideas for helpful examples, more documentation, or other useful material we could provide, we welcome them!
| |
|
| |
|
| ==Operating System Troubleshooting==
| | }} |
| To determine whether the problem relates to your operating system, you should check whether your system detects the Phidget by following guides below for your operating system.
| | ---- |
| ===macOS===
| | {{Collapse |
| First, make sure you have followed the [[OS - macOS#Getting Started with macOS|getting started]] guide on the macOS page.
| | |When I open a channel on the device it says "Attached: Nothing" or "Resource Busy" |
| | |A Phidget can only be opened in one program at a time, including the Phidget control panel. This behaviour usually means another program or process already has that channel open. Try closing all other programs, and if that doesn't work, go into the task manager and shut down any processes by other programs that use Phidgets. Rebooting may also work if the other program using the Phidget doesn't launch on startup. |
|
| |
|
| You should now have the latest Phidget software installed and have the Phidget Control Panel running. If your device is not listed in the Phidget Control Panel, verify that your computer has detected the Phidget via USB. To do that, follow these steps:
| | If the problem persists, try testing the Phidget on a different computer if possible. If it still has the same problem on multiple computers, {{ContactUs|contact support}} . |
| | }} |
| | ---- |
| | {{Collapse |
| | |I can't find the Control Panel [[File:Ph.jpg|link=]] icon in my system tray |
| | |For Windows users, navigate to <code>C:\Program Files\Phidgets\Phidget22</code> and run <code>Phidget22Manager.exe</code>. For MacOS users, you can run the Phidget Control Panel from the Applications list. |
|
| |
|
| 1. Navigate to the Apple Menu and select About This Mac
| | If you find that you need to manually open the Control Panel like this every time you start up your computer, you should open the options and make sure the setting for automatic startup is checked. |
| [[File:OSX About This Mac.png|link=|alt=macOS About This Mac|center]]
| |
|
| |
|
| 2. Click on the System Report button. Find your Phidget in the USB section.
| | If you can't find the control panel in the places listed above, your Phidgets drivers may not have installed correctly. Go to the [[Operating_System_Support|page for your OS]] and follow the instructions to install the drivers. |
| [[File:OSX USB Devices.png |link=|alt=macOS Attached USB Devices|center]] | | }} |
| | ---- |
|
| |
|
| If you can see your Phidget in the USB list even though it does not show up in the Phidget Control Panel take a moment to check the basics:
| |
| * You are using macOS X 10.5 or newer
| |
| * No other programs, drivers, or processes are using that USB port in software (including other programs trying to use Phidgets)
| |
| * Your Phidget libraries are up-to-date
| |
|
| |
|
| ===Windows===
| | Once you've successfully tested with the Control Panel, you can rule out most hardware and operating system issues. Next we'll try some sample code. |
| First, make sure you have followed the [[OS - Windows#Getting Started with Windows|getting started]] guide on the Windows page.
| |
|
| |
|
| You should now have the latest Phidget software installed and have the Phidget Control Panel running. If your device is not listed in the Phidget Control Panel, verify that your computer has detected the Phidget via USB. To do that, follow these steps:
| |
|
| |
|
|
| |
|
| 1. Open the Device Manager by accessing the start menu, and searching for ''Device Manager''. Under the Human Interface Devices heading there should be a HID-compliant device and a USB Input Device entry for every Phidget. Simply disconnect/connect a Phidget to verify which one it is on the list.
| |
|
| |
|
| [[File:Windows_DeviceManager.PNG|link=|alt=Windows Device Manager | center]]
| | ====Step 2: Test with our Sample Code==== |
|
| |
|
| 2. Another place you can see attached Phidgets is "Devices and Printers" which you can also open by searching for it in the start menu.
| | You can find our sample code downloads on [{{SERVER}}/?view=code_samples this page]. Select your desired programming language from the drop-down menu and select the object type that matches one used by your Phidget. Then go to the [[Programming_Resources|language page]] for your programming language and run through the instructions for running code in your chosen development environment. |
|
| |
|
| [[File:Windows_DevicesAndPrinters.jpg|link=|alt=Devices and Printers | center]] | | ---- |
| | {{Collapse |
| | |The Phidget channel fails to open / I get a timeout error |
| | |Make sure you're setting all of the matching parameters correctly. You can learn more by reading our page on [[Addressing Phidgets]]. Also make sure that the channels you're trying to open aren't already opened in another program (including the Phidget Control Panel). |
| | }} |
| | ---- |
| | {{Collapse |
| | |I get a compiler error when I try to run the code |
| | |If the code sample doesn't compile, there's probably something wrong in the build settings or a certain file may be in the wrong location. Double check the instructions on the language page to ensure that you've set everything up properly. If you still get compiler errors, {{ContactUs|contact us}} with a screenshot or copy+paste of your error and tell us what operating system, code sample, and Phidget you're using. |
| | }} |
| | ---- |
| | {{Collapse |
| | |I get a runtime error when I try to run the code |
| | |If the error is reported by the Phidget library, you can find it on the {{Phidget22API}}. If it's being reported from basic functions in your language, try searching the exact text of the error on google to see if other users have had the same one. If that doesn't work, {{ContactUs|contact us}} with a screenshot or copy+paste of your error and tell us what operating system and Phidget you're using. |
| | }} |
| | ---- |
|
| |
|
|
| |
|
| If you can see your Phidget in the USB list even though it does not show up in the Phidget Control Panel take a moment to check the basics:
| |
|
| |
|
| *You are using Windows 7 or newer.
| |
| *You have .NET framework 3.5 or higher. Unsure how to check? This is covered directly below.
| |
| *No other programs, drivers, or processes are using that USB port in software. Some drivers or software will sometimes mistakenly claim Phidget devices when waiting on some hardware to be connected. Please see the section: third party software prevents communications with Phidgets for more information.
| |
| *The Phidget libraries are the latest version (visit the getting started section to download them)
| |
| *Check the common problems section below, some specific combinations can cause problems
| |
|
| |
|
| | Once you get our sample code working, you can be assured that your drivers and development environment are set up properly and your Phidget working as intended. If you're still having problems, have a look at our other troubleshooting topics: |
|
| |
|
| Unsure which versions of the .NET framework are installed on your computer?
| | * [[OS Troubleshooting]] |
| *click on start menu and run "regedit"
| | * [[Code Troubleshooting]] |
| *navigate to {{Code|HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP}}
| | * [[Hardware Troubleshooting]] |
| *The folder names under NDP indicate the version numbers you currently have installed. | | * [[Network Server Troubleshooting]] |
| If you are unable to install .NET framework 3.5 or higher, you can still use Phidgets. However, you won't be able to use the installer, and will have to manually install the Phidget libraries. Please see the [[OS - Windows#Advanced Information | Windows Advanced Information]] section.
| | * [[Troubleshooting Common Issues]] |
| | |
| | |
| If you don't see the Phidget in either list, try the following things:
| |
| | |
| *If the Phidget is connected to your PC through a USB hub, try connecting it directly to a USB port on your computer.
| |
| *If your Phidget requires an external power supply, make sure that a supply of the correct voltage is connected.
| |
| *If you're using an old USB cable, try switching it out for one you know is working.
| |
| *Try switching to a different USB port on your computer.
| |
| *Try connecting the Phidget to a different computer, especially if you have one that has worked with other Phidgets previously. | |
| | |
| ===Linux===
| |
| First, make sure you have followed the [[OS - Linux#Getting Started with Linux|getting started]] guide on the Linux page.
| |
| | |
| You should now have the latest Phidget software installed and have the HelloWorld C program running. If your device is not listed when the program runs, verify that your computer has detected the Phidget via USB. To check this, you can use the kernel log reader {{Code|dmesg}}. Pipe the output of {{Code|dmesg}} into the utility {{Code|tail}} to read the last ten lines of the log:
| |
| | |
| <syntaxhighlight lang=bash>
| |
| $> dmesg | tail
| |
| ....(3 lines)....
| |
| [337.189132] usb 1-2: new full-speed USB device number 5 using ochi-pci
| |
| [337.464709] usb 1-2: New USB device found, idVendor=06c2 idProduct=0034
| |
| [337.464714] usb 1-2: New USB device strongs: Mfr=1, Product=2, SerialNumber=3
| |
| [337.464718] usb 1-2: Product: 1024_0
| |
| [337.464721] usb 1-2: Manufacturer: Phidgets Inc.
| |
| [337.464724] usb 1-2: SerialNumber: 388624
| |
| [337.491426] usb 1-2: hid-generic 0003:06C2:0034.0004: hiddev0,hidraw1: USB HID v1.01 Device [Phidgets Inc. 1024_0] on usb-0000:00:06.0-2/input0
| |
| </syntaxhighlight>
| |
| | |
| The number between the [ ] is the system time in seconds since the last boot up, so you can tell whether the event was recent or not. (This will also tell you the interrupt type of Phidget that is registered by the USB interface, see the [[#Common Problems and Solutions | common problems section below]] for more information on what this means.)
| |
| | |
| The Phidget should both connect and disconnect properly, so unplugging it should result in an additional line at the tail:
| |
| | |
| <syntaxhighlight lang=bash>
| |
| $> dmesg | tail
| |
| ....(9 lines)....
| |
| [744.558055] usb 1-2: USB disconnect, device number 5
| |
| </syntaxhighlight>
| |
| | |
| If you can see your Phidget in the USB list even though it does not show up in the Hello World C program take a moment to check the basics:
| |
| * No other programs, drivers, or processes are using that USB port in software
| |
| * You are running the example program as root (or your udev rules have been set properly)
| |
| * You are using libusb 1.0 (not the older 0.1 release)
| |
| * You have compiled versions of libphidget22.a and libphidget22.so in your system library location (usually {{Code|/usr/lib}})
| |
| * The Phidget libraries are the latest version
| |
| * Your Linux kernel version is 2.6 or later (type {{Code|uname -r}} in a terminal to get your kernel version)
| |
| * Check the [[#Common Problems and Solutions|common problems]] section below, some specific combinations can cause problems
| |
| | |
| ==Communications Troubleshooting==
| |
| | |
| To determine whether the problem is a communications problem, '''check operation using the shortest, most direct connection you can''', including both:
| |
| *Data connections, and
| |
| *Power connections
| |
| | |
| '''If you believe a connection may be at fault:'''
| |
| :*Use [[Electricity Primer#USB Cables|short USB cables]] (<5 m)... long wires lead to poor sensor data and/or inadequate power
| |
| :*Use powered USB hubs or direct connections to a computer.
| |
| :*Try unplugging everything on the hub except the Phidget.
| |
| :*Try plugging the Phidget directly into the computer instead of using a hub. If this solves the problem, either the hub is at fault, or the added length of cable from the hub to the computer may have caused instability.
| |
| :*Make sure any cables between Phidgets are correctly connected. Helpful pictures can be found on the [[:Category:UserGuide|User Guide]] for your device
| |
| :*If your Phidget needs external power, such as the motors and relays, the proper way to provide it can be found on the product page for your device [{{SERVER}} on our main website]
| |
| | |
| Communication problems come from either (a) power issues, or (b) connection issues. Once everything is plugged in and powered properly, there is not a whole lot that can go wrong with cables.
| |
| | |
| The one exception to communications problems being only from power or connections is if you're using a wireless internet connection to the [{{SERVER}}/products.php?product_id=1073 Single Board Computer]. Help for setting up and troubleshooting that Wifi connection can be found on the [[OS - Phidget SBC|SBC operating system page]].
| |
| | |
| | |
| ==Device Troubleshooting==
| |
| | |
| To determine whether the problem is with the Phidget itself, '''check whether the Phidget works on a different computer'''.
| |
| | |
| '''If you suspect the problem is with the hardware:'''
| |
| :*Move the setup to a different operating system. If it appears on another system, you'll want to debug your original system starting with [[#Operating System Troubleshooting|Operating System Troubleshooting]]
| |
| :*Check what your device can and can't do (power, functionality, etc) - this will be found on its product page [{{SERVER}} on our main website].
| |
| :*Make sure all the pieces are hooked up correctly. Helpful photos can be found on the ''Getting Started'' page for your device in its [[:Category:UserGuide|user guide]].
| |
| :*If you're trying to do something especially involved, become well-versed in your hardware. We provide lots of information on our [[:Category:Primer| primer pages]].
| |
| | |
| It may be tempting to assume that a device "not working" indicates a problem with the hardware. But this troubleshooting page itself shows that even something as simple as a device "not working" could be due to a problem at several different points. The best place to start if you haven't worked through our documentation yet would be the ''Getting Started'' guide for your device, found in its [[:Category:UserGuide|user guide]].
| |
| | |
| ===Diagnosing Hardware Problems===
| |
| An easy way to tell you have a '''new''' problem with your device is that it suddenly stops working. If you run the same code, on the same system, with the same libraries, and the same Phidget and suddenly it doesn't do the same thing anymore, you almost certainly have a hardware problem. This can happen especially on boards and/or components that handle some form of external power (motors, relays, etc). It is important to make sure you don't overload the board, or you could do some serious damage. Check the specs for your device and remember, be conservative.
| |
| | |
| ====Heat====
| |
| One of the surest ways to discover a problem is as simple as touching the board. When current flows through electronics it will generate heat, this is a fundamental fact with all electronics. The more current that you are pushing, the more heat that will be generated. As a result of this the instance where you have the most current possible flowing (a short circuit) will also generate the most heat. So much heat that it will likely be painful to the touch so be careful when poking and prodding the various parts of the board. Keep in mind that some heat build up is to be expected, but if you can find a part of the board that is unusually hot then there is a strong possibility that there is a short circuit somewhere in that section and the board has been damaged. You should {{ContactUs|contact us}} if this is the case.
| |
| | |
| ====Checking Voltages====
| |
| If you have a multimeter at your disposal another good way of checking your board is to check that all of the ICs on the board are getting the power they should. If you look at the labelling on the top of the ICs you should be able to get the part number of the chip. If it is too small or hard to read you can always look at the high resolution product images on our website to get a better look. Failing that, {{ContactUs|contact us}} and we can give you the part number. Once you have it search the internet for a data sheet for the part. The data sheet will have a pin diagram from which you can determine which pins are V<sub>cc</sub> and Gnd. Take your multimeter and measure the voltage between those pins. Does the chip appear to be getting the voltage it should be? If not then it is possible there is a short somewhere in the power line.
| |
| | |
| ====EMI====
| |
| One of the most difficult hardware related problems to diagnose and debug is electromagnetic interference or EMI. In fact, it is such a complex topic that we have a guide devoted entirely to it. If you think you may be having EMI difficulties or if you don't know what kind of difficulties you might be having (an apparent lack of other explanation is a good sign your problems might be EMI related) you should read our guide for [[Addressing Electromagnetic Interference with Phidgets|addressing EMI issues]].
| |
| | |
| ==Network Server Troubleshooting==
| |
| | |
| To determine whether the problem is with the Network Server, '''check whether the Phidget can run without the Network Server''' by directly connecting it to one of the computers and running Phidget code locally on that system.
| |
| | |
| * This will be possible at least for the computer hosting the direct connection to the Phidget
| |
| * You can use a local version of the open() function, or use our examples as described in the [[#Code Troubleshooting|Code Troubleshooting]] section above
| |
| * For the platform remotely controlling the Phidget, this direct test may not be possible (such as for [[OS - iOS|iOS]] or some [[OS - Android|Android]] devices) | |
| | |
| If the Phidget works locally but not over the network, the problem is with the Network Server. If the Phidget does not work locally either, it is probably not the Network Server, and is instead your code, your operating system, your connections, or the device itself. Use this Troubleshooting guide on the local system to diagnose the problem.
| |
| | |
| '''If the problem is within the Network Server:'''
| |
| :*Make sure the Phidget library and Network Server versions are the '''same''' on both computers. Different Network Server versions do not work together. Find the Network Server download on the [[Software Overview#Operating System Support | page for your operating system]]
| |
| :*Wait some time (a few seconds, to start) before trying to do things with the Phidget upon first connecting remotely, sometimes delay occurs over a network
| |
| :*Check the network setup on both sides. Typos can occur in the IP address, port number, server name, and password.
| |
| | |
| Slowing your program down by using a '''<code>sleep</code>''' or '''<code>wait</code>''' function will allow you to test whether network lag is at fault. Network delay will primarily affect (a) how quickly you can use the Phidget after opening and attaching it, and (b) the speed of reading continuous data from the device. Putting wait delays in your code especially in data-reading loops will prevent the network from being totally overloaded, and let you see whether you can get 'any' data through.
| |
| | |
| Another problem might be an error in the details that need to match on each computer. You either need an IP address and port, or the server name (when using muticast DNS from '''<code>Bonjour</code>''' on Windows and OS X or '''<code>avahi</code>''' on Linux). The server name is set at the Network Server start up, or it will default to the name of the computer with the direct connection. Double-checking all of these details may uncover the problem.
| |
| | |
| Finally, if you suspect multicast DNS may be the problem, use the IP address and port form of the '''<code>open()</code>''' function to directly connect to the computer controlling the Phidget. On [[OS - Linux|Linux]], the use of mDNS can be compiled out of the Network Server, and the Network Server can be tested without it.
| |
| | |
| ===Version Mismatch===
| |
| If you are experiencing a "Version Mismatch" error this is due to either end of the connection having an out of date version of the Network Server. To fix this make sure that both ends are fully updated and try again. Note that on the SBC this means you will need to go to the System->Packages tab and upgrade all of the systems packages. For more information on upgrading the SBC refer to the [[1073 User Guide#Recovery / Upgrade System|SBC's User Guide]].
| |
| | |
| ==Common Problems and Solutions==
| |
| ===Windows===
| |
| ====Issue: Software projects are not working after a Phidget22 reinstall====
| |
| Solution: You need to reset your references and library paths. When you reinstall the Phidgets drivers all of the old paths can get broken. Make sure that you are including the correect header files and that you have referenced the correct libraries and that should fix the problem.
| |
| | |
| ====Issue: Some third party software prevents communications with Phidgets====
| |
| Some drivers or software will sometimes mistakenly claim Phidget devices when waiting on some hardware to be connected.
| |
| This is caused by the drivers taking every HID (human interface device) on the USB bus, effectively stealing them from the Phidgets drivers.
| |
| When this happens, the device shows up in the Phidget Control Panel at start up but examples and programs are unable to make a connection to the Phidget.
| |
| This has been known to occur with Logitech QuickCam, Force Feedback Mouse, Nike, Velleman K8055, and some SteelSeries drivers.
| |
| | |
| Solution: If you suspect this is a problem then try putting your machine in safe mode. If this fixes the problem you can be sure that this is the problem. Try shutting/uninstalling the offending driver/software down or kill its process in the task manager when using Phidgets.
| |
| | |
| ====Issue: A corrupt installation fails on uninstall or repair====
| |
| Solution: If the normal uninstall fails, for whatever reason, you can choose to remove the Phidget drivers manually.
| |
| Please perform the following:
| |
| # Shut down any programs and processes using the Phidget libraries, including the Network Service and the Phidget Control Panel.
| |
| # Delete {{Code|C:\Program Files\Phidgets\}}
| |
| # Remove the Phidgets key from the Registry {{Code|[-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ Phidget22NetworkService]}}.
| |
| | |
| In most cases this is enough to get the installer working again. If you need to remove all traces of the Phidgets libraries manually, perform the following additional steps:
| |
| | |
| # Remove {{Code|Phidget22.NET}} from {{Code|C:\Windows\Assembly\}}.
| |
| # Delete {{Code|C:\Windows\system32\phidget22.dll}}.
| |
| # Delete Phidgets from the start menu.
| |
| # Search for and remove keys mentioning Phidgets from the registry in the following locations:
| |
| #* {{Code|[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\]}}
| |
| #* {{Code|[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\]}}
| |
| #* {{Code|[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\Phidgets Inc]}}
| |
| #* {{Code|[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Assemblies\Global\]}}
| |
| # Reboot
| |
| | |
| '''NOTE:''' You can go through the registry and purge any other keys mentioning Phidgets if you still have problems, but at this point you should be able to reinstall under most cases. There will also be keys relating to the installer, the .NET library and the COM library, but they should not interfere with anything.
| |
| | |
| ====Issue: Event data is sporadic/slow/clumped over the Network Server====
| |
| Windows implements 200ms delayed ACKs for network traffic. When traffic is one-way only - as it is with event data, the data will all arrive in clumps every 200ms because of delayed ACKs.
| |
| | |
| This can be a great drawback for applications which rely on low latency event data over the network. (source: http://support.microsoft.com/kb/214397)
| |
| | |
| This delayed ACK behavior can be disabled in windows to decrease event latency as documented here: http://support.microsoft.com/kb/328890
| |
| | |
| In the future, the Phidgets library may implement this differently, but so far we have been unable to match the performance achieved by disabling delayed ACK.
| |
| | |
| ===Linux===
| |
| ====Issue: Linux will only schedule one low-speed interrupt transfer per millisecond====
| |
| You can find out the type of your Phidget by attaching it and then running <code><font size=3>dmesg | tail</font></code>, which will display the type of Phidget from your kernel logs, as described above in the [[#Hardware|hardware section]]. The practical consequence of this is if your system has many low speed Phidgets attached, they will each be throttled down. Low speed Phidgets require an interrupt transfer as often as every 8 milliseconds. A Linux system could only have up to 8 of these Phidgets attached.
| |
| ====Issue: The data read from a program, or the first packet on the Network Server, can give a sample overrun error (EEPHIDGET_OVERRUN)====
| |
| Linux only polls data from the analog inputs on Phidgets when you ask it to. So there is some delay between when you open the device and when it actually attaches when data from those inputs are accumulating...and overrunning the buffer. This is simply in the nature of how Linux polls USB - we recommend catching (but ignoring) this one-time initial error.
| |
| ====Issue: Your device doesn't seem to run as expected on a Raspberry Pi====
| |
| The USB ports on the standard Raspberry Pi are only capable of supplying around 100mA reliably. Since USB specification dictates 500mA of current maximum, many USB devices require several hundred mA to run smoothly. Since the Pi cannot supply this much current it is common to see buggy performance or complete failure to run at all. The get around this you should use a USB hub connected to the Pi that has it's own external power supply. This will allow the devices connected to have as much power as they require.
| |
| | |
| ===Phidget SBC===
| |
| ====Issue: Curl doesn't install smoothly====
| |
| There is an issue with the embedded version of PHP5.3, try forcing it to install the specific version that you need. This can be done with the following command:
| |
| <syntaxhighlight lang="text">
| |
| apt-get install php5-common<nowiki>=</nowiki>5.3.3-7+squeeze14
| |
| </syntaxhighlight>
| |
| | |
| ====Issue: FTDI adapters do not appear to work with the SBC====
| |
| The 3.1.6 version of the Linux kernel which is used on some versions of the SBC has a bug that causes issues with FTDI drivers and makes them malfunction. To solve this problem you must upgrade the kernel to a newer version. You can find the files [[#Quick Downloads| here]].
| |
| | |
| ====Issue: USB Memory Keys mount at more than one location====
| |
| When you insert a memory key, the SBC will load it as a device (e.g. {{Code|/dev/sda1}}) and it will also ''mount'' the key for reading and writing within the {{Code|/media/}} directory. The {{Code|/media/}} directory version will be called something like {{Code|usb0}}.
| |
| At times, an inserted memory key will get mounted in more than one location. You can observe if this occurs by checking the currently mounted devices with the command {{Code|mount}}:
| |
| | |
| <syntaxhighlight lang="text">
| |
| root@phidgetsbc:~# mount
| |
| tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
| |
| proc on /proc type proc (rw,noexec,nosuid,nodev)
| |
| sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
| |
| udev on /dev type tmpfs (rw,mode=0755)
| |
| tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
| |
| devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
| |
| rootfs on / type rootfs (rw)
| |
| procbususb on /proc/bus/usb type usbfs (rw)
| |
| /dev/sda1 on /media/usb0 type vfat (rw,noexec,nodev,sync,noatime,nodiratime)
| |
| /dev/sda1 on /media/usb1 type vfat (rw,noexec,nodev,sync,noatime,nodiratime)
| |
| </syntaxhighlight>
| |
| | |
| You will note that the same device ({{Code|/dev/sda1}}) is now mounted at ''both'' {{Code|/media/usb0}} and {{Code|/media/usb1}}. To fix this problem as it occurs, you can use {{Code|umount}} (notice there is no letter 'n') to unmount the second instance:
| |
| | |
| <syntaxhighlight lang="text">
| |
| root@phidgetsbc:~# umount /media/usb1
| |
| </syntaxhighlight>
| |
| | |
| In practice, this should not be a problem, because writing to or reading from either {{Code|usb0}} or {{Code|usb1}} will have the same effect on the memory key. However, if you hard-code a media location into your program (i.e. expecting {{Code|/media/usb0}} to be the first USB key you insert and {{Code|/media/usb1}} to be the second key) your program will sometimes work and sometimes fail.
| |
| | |
| To get around this within code, find the mount point for each device as it appears. The devices, such as {{Code|/dev/sda1}} will always refer to the actual memory key. But, they cannot be written to directly without being mounted, so you will have to parse the mount table (what is returned from {{Code|mount}}) within your code to find the device and its corresponding mount point.
| |
| | |
| This is a problem with the standard embedded Debian automount program, and we have no known fix.
| |
| | |
| ====Issue: Perl Locale Errors on SSH - No Locales Installed====
| |
| By default, no locales are installed on the SBC. If you use [[#apt|apt]] a lot to install and manage your software on the SBC, you will get messages like this:
| |
| | |
| <syntaxhighlight lang="text">
| |
| perl: warning: Setting locale failed.
| |
| perl: warning: Please check that your locale settings:
| |
| LANGUAGE = (unset),
| |
| LC_ALL = (unset),
| |
| LANG = "en_CA.UTF-8"
| |
| are supported and installed on your system.
| |
| perl: warning: Falling back to the standard locale ("C").
| |
| locale: Cannot set LC_CTYPE to default locale: No such file or directory
| |
| locale: Cannot set LC_MESSAGES to default locale: No such file or directory
| |
| locale: Cannot set LC_ALL to default locale: No such file or directory
| |
| </syntaxhighlight>
| |
| | |
| To squelch these messages, you should install and reconfigure your locale like this:
| |
| | |
| <syntaxhighlight lang="bash">
| |
| apt-get install locales
| |
| dpkg-reconfigure locales
| |
| </syntaxhighlight>
| |
| | |
| The last command will show you a long list from which you should pick your location, by language. For example, en_CA is english_Canada. Here in Calgary, we use en_CA.UTF-8 and so for the first question we would input locale "114" and for the second (system) question we would input {{Code|en_CA}} for the locale.
| |
| | |
| This might give you a locale undefined error, in which case you can generate the locale (for us, again, it is en_CA):
| |
| | |
| <syntaxhighlight lang="bash">
| |
| locale-gen en_CA
| |
| </syntaxhighlight>
| |
| ====Issue:My Cron Job Doesn't Work====
| |
| | |
| It is actually very common for a script or program to work on the command line but then ''not'' work as a cron job. The most common reason for this, by far, is that you specify ''relative'' paths in your program to access files rather than ''absolute'' paths. For example:
| |
| * {{Code|code/project.c}} is a relative path (bad for cron)
| |
| * {{Code|/root/code/project.c}} is an absolute path (good for cron)
| |
| The cron jobs are ''not'' executed from your home directory, or your code directory, so they will not be using the same location you may be using to test your code. So always use absolute paths.
| |
| | |
| Another common reason is you may be using environment variables or other settings that are true in a terminal but are ''not'' true by default in the raw system. You can end up taking many things for granted in a shell, for example the shortcut "~" means home directory in a shell, but not by default in the raw system. The things that get loaded for a shell (but which are not present in the raw system) are:
| |
| * The settings loaded by {{Code|/etc/profile}}
| |
| * Any settings in {{Code|~/.bashrc}}, which is nothing by default on the SBC
| |
| | |
| On a full Linux operating system, you would use the logs written to by cron to find the error output and debug it. On the SBC, however, cron does not write logs (otherwise, these logs would eat up the SBC memory very quickly even for routine jobs). For short-term debugging, you can write output from your program to a file, and read that file afterwards to figure out what your program is doing.
| |
| | |
| ===Languages===
| |
| ====C/C++====
| |
| =====Issue: I am using a non US-English version of Windows, and the Visual C/C++ examples run into a linker error=====
| |
| The example projects, by default finds the phidget22.h and phidget22.lib in ${SystemDrive}\Program Files\Phidgets\Phidget22. If you are using a non US-English version of Windows, the Phidget libraries may be installed into a different location. To resolve, you will have to modify the paths to these two files. For instructions, please see your environment/compiler section.
| |
| | |
| ====LabVIEW====
| |
| =====Issue: I cannot attach to an object any more after running my program once=====
| |
| What this means is you probably aborted the VI which stopped the program before the Phidget could be closed. Aborting execution will not release the Phidget device properly and will consequently make it unusable until the Phidgets library (or LabVIEW) has been restarted.
| |
| | |
| To resolve this, you may open a new VI, place PhidgetResetLibrary.vi, and run it. This will completely reset the current Phidget library, making it possible again to connect to all Phidgets.
| |
| | |
| '''Note that this action will close all Phidgets that are currently open in LabVIEW, and should not be used while other Phidgets-related LabVIEW VIs are running.'''
| |
| | |
| [[Image:Phidget Reset All Palette.png|link=|600px|center]]
| |
| | |
| [[Image:Phidget Reset All.png|link=|600px|center]]
| |
| | |
| In order to prevent this from happening you should use a software stop button when possible instead of halting operation. That way the Close subVI gets called and the Phidget will be released.
| |
| | |
| ====Max/MSP====
| |
| =====Issue: When a patch file is closed in the Max/MSP environment, the program crashes=====
| |
| If in your Max/MSP environment, you have more patches(of the same Phidget object) than you have of the actual hardware device, the Max/MSP environment may crash. This is due to the fact that a single Phidget Max/MSP object only corresponds to a single Phidget device hardware. For example, your Max/MSP environment may experience unexpected behavior while you have one PhidgetInterfaceKit device connected to the computer, but you have a two seperate patches opened with a single PhidgetInterfaceKit Max object in each one.
| |
| | |
| Likely Fix: Please ensure that you do not use more patches(of the same Phidget object) than you have of the actual Phidget device.
| |
| ==Contact Us==
| |
| | |
| If you are still having trouble after working through this guide, please {{ContactUs|contact us}}.
| |
| | |
| It helps if you can you can give us precise information about your issue, such as:
| |
| *Minimal code to reproduce the problem
| |
| *What part of the system you think the issue might be in, and why
| |
| *Photos or even videos when necessary
| |
icon in my system tray
