Template:LabVIEW Troubleshooting: Difference between revisions
(Created page with "{{UGC-Start}} {{UGC-Addressing}} {{UGC-Entry|I cannot attach to an object any more after running my program once|| What this means is you probably aborted the VI which stopped...") |
No edit summary |
||
Line 1: | Line 1: | ||
{{UGC-Start}} | {{UGC-Start}} | ||
{{UGC-Entry|I cannot attach to an object any more after running my program once|| | {{UGC-Entry|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. | 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. |
Latest revision as of 21:51, 3 February 2021
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.
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.
All Phidgets-based error codes in LabVIEW are offset by 7000 to avoid conflicting with LabVIEW's own error codes. To get the equivalent Phidget return code from the LabVIEW error code, simply subtract 7000. For instance, error code 7003 in LabVIEW translates to Phidget Return Code 3.
To find the meaning of all Phidget Return Codes, you can go to the Phidget22 API page, and open the PhidgetReturnCode section under Enumerations.
In other words, if you open 2 of the same device and have a sensor change event for each one your system can behave unpredictably. This problem is a quirk in the way that LabVIEW handles passing events to and from C. There are a few solutions to this issue, either:
- Stop using events and simply poll the device. Events work similarly to polling in LabVIEW anyway and should not cause substantial performance changes to your application.
- Implement a simple fix to the events which are causing the problem. The pointer is identical in the case where two events of the same type are passed from a single function. This causes the events in C to output to the same event in LabVIEW. To get around this you need to copy the offending subVI, then change the name of the cluster object in it from "Event" to something else (your choice), change the name of the .vi to something else and then use those two different subVIs in your program. You would need to repeat this for each subsequent event of the same type you wish to have.
- Make an array of all the devices you intend to use with the event, and feed the array into a single EventCreate vi, and use a single EventExe handler for all the events. When using this method, it might be tempting to add multiple event handlers, but keep in mind that events only occur once, in whichever handler sees them first. When running multiple Phidgets through the single event handler, you can determine which one caused the event by comparing the phid terminal from the EventExe VI to the Phidget IDs (Device In/Device Out) of your Phidgets.
We recommend using either of the the first two solutions where possible. The first is a bit cleaner, but the second will work just as well. We only recommend using the third method in cases where it is not practical to manually create individual event handlers.