Need to find the path to the desktop on any platform? This is the VI from 1999 updated to handle W2k, Windows XP, and Mac OS X, in addition to the older Windows 95, Windows NT, and Mac operating systems already supported by the older version. This version is written in LabVIEW 7.0 and requires System Exec.vi, which wasn't in the earlier versions of LabVIEW for the Macintosh. It could be ported to earlier versions on the PC. Download it and put it in user.lib>>Utilities>>Paths or an equivalent location for smoothest integration with its subVIs.
Desktop.vi uses the Error Handlers package to give you more useful information about failures. If you have not already done so, you will have to download the Error Handlers package or replace Chained Find First Error.vi with a simple error cluster constant in order for Desktop.vi to work. The Desktop.vi license covers the Error Handlers ONLY for the error already built into Desktop.vi. You may use, for instance, the Smart Simple Error Handler in VIs you develop using Desktop.vi to emphasize the error details but you may not use Chained Find First Error to add such details to other errors in your code. That requires an Error Handlers license.
Excited about the ease of developing Hierarchical State Machines and autonomous agent objects with LabHSM? Would you like to encapsulate its message queue info? This add-on is a LabVIEW Component Oriented Design (LCOD) that does just that. Not only are your VIs less cluttered, you even get helpful Programmer Hints when there is something wrong with your connection.
In a Hierarchical State Machine built with the LabHSM package, independent "agent" VIs can communicate with each other by sending messages. It is necessary to set up an individual communications channel for each direction of transfer between each pair of agents that desire to communicate. This connection is maintained in the message queue info cluster that is commonly stored in a front panel control or a shift register of the transmitting agent. This cluster is only used in establishing the connection, sending messages, and breaking the connection. By software design tenets, this data should be encapsulated in the connection object itself. This package accomplishes the encapsulation in LCOD fashion.
Since each connection is a separate object, a LabVIEW template VI, LabHSM Connection.vit, is provided for convenient object instantiation. The template (the only item in the package with which you need to interact) is really just a wrapper for a reentrant VI (hence, the characteristic cross-hatching in the icon above) that does the work. Simply instantiate the template for each desired one-way communications channel and drop that instantiation onto the diagram of the transmitting agent wherever communication is desired. The figure below shows an LCOD implementation of the Master of the Two Communicating Objects example.
This implementation is fully compatible with the LabHSM toolkit and, in fact, the VI above talks to a slave that is implemented with the standard technique. Just download the package (LV7.0, 110kbytes) and unzip it into the LabHSM Library folder. (You may want to copy or move the VIT file to the LabVIEW>>templates folder for more convenient instantiations.)
LabHSM Connection uses the Error Handlers package to give you more useful information about communications failures than the H View Labs code, such as telling you that "Demo_Salve.vi was not found on 22.214.171.124" when you wanted Demo_Slave.vi on 192.168.0.5. If you have not already done so, you will have to download the Error Handlers package in order for LabHSM Connection to work. The LabHSM Connection license covers the Error Handlers ONLY for the errors already built into the package. You may use, for instance, the Smart Simple Error Handler in VIs you develop using LabHSM Connection to emphasize the error details such as "Demo_Salve..." but you may not use Chained Find First Error to add such details to other errors in your code. That requires an Error Handlers license.
LabHSM Connection also uses a few OpenG VIs. If you have not already installed OpenG on your machine, you will need to download a small library (LV7, 16 kbytes) of them and put it in the LabHSM Library folder as well.
"The "Inf and NaN Plotter" from SULLutions is a novel example of LabVIEW developers expanding the functionality of the LabVIEW development environment. Professional add-on tools such as this greatly increase the value of LabVIEW for all users."
— J. R. Allen, LabVIEW Product Marketing Manager, National Instruments
Ever wish that your graphs could show the exceptional values Inf, -Inf, and NaN?
"That's quite a novel idea..." — J. R. Allen
The standard LabVIEW graphs and charts skip the values Inf, -Inf, and NaN when plotting. This makes a lot of sense. A graph wouldn't convey much information if everything were plotted to scale and either infinity were included!
But sometimes you'd like to know that a particular raw data set contained some values that caused exceptions in your processing. In my case, I was taking the logarithm of the residual of a curve fit to detect additional dependencies. For least squares fits, the residual necessarily contains negative numbers (for which there is no logarithm) or is uniformly zero (for which the logarithm is negative infinity). Some, or even all, of the residual doesn't appear in the plot.
If you're plotting only a few points, using a line plot will indicate the exceptions by breaks in the line. The performance of the line adjacent to the gap will even indicate the type of exception. But these breaks become hard to detect for plots of a hundred points or more. You can't miss the three exceptions (one of each type) in the following data plot by the Inf and NaN Plotter package:
The package has three utility subVIs (one of which has nothing to do with the task at hand, but is useful in the demonstrations) and examples of their use in waveform charts, waveform graphs, and XY graphs. (Merge VIs did not make sense given the polymorphism of graphs and charts.) Just download this
Be forewarned that graph cursors have some peculiarities (detailed in the documentation of the example) when you try to make them work across all LabVIEW versions from 6.0 through 7.1.
Would you like to provide users with an easy way to dock your panel in one of the corners of the computer screen, just as they can with PJM's Bird's Eye View? Download this library in raw (1.2 Mbytes) or zipped (607 kbytes) form, put it in the user.lib of any version of LabVIEW from 6.0 through 7.1, and you're set to drop the capability onto the VIs of your choice.
This package provides a convenient merge VI, Add Window Docking.vi, that allows you to literally drop the capability onto your main VI, with no programming or even wiring required. You'll probably want to (but don't have to) integrate the shutdown of the Window Docker fully with that of your main program. If so, just wire the STOP button dropped by the merge VI as the stopping control for your VI, as illustrated in the included example, Redock.vi. If you don't care about coordinated shutdown, you can ignore, hide, or even delete the proffered STOP button; everything will still work fine.
Redock.vi is multipurpose. As mentioned above, it shows how to wire your VI to coordinate its shutdown with that of the docking utility. Redock.vi can also demonstrate just how a panel behaves with this new functionality. Run Redock.vi and click on the arrows to send it into the corners of the screen. Drag it out of a corner and watch it realize and indicate that it is no longer docked. Show all the VIs in memory in the hierarchy window then stop Redock.vi with the stop button (not the Abort) or the window close control, and watch the bulk or all, respectively, of the Window Docking package leave the stage. You'll even see an indication that the coordination takes some time, as the "STOP" text changes to "stopping" for at least a part of the process.
Redock.vi also shows you how to redock your panel after a potentially disturbing event, such as a programmatic resizing of the panel. If you want to keep the panel docked despite a programmatic resizing, you would capture the current docking state, perform the resize, and, after things had settled down, restore the previous docked state. Redock.vi allows you to do this manually. Click the capture button, resize (or move) the panel, then click the restore button. If the panel was originally docked, it will move back to the corner it was docked in. If it was not originally docked, restore will do nothing. If your application needs this capability, Redock.vi shows you how to implement it (slightly differently for different versions of LabVIEW). You'd do the stuff in the Capture case, then resize (or whatever), that might disturb docking, then wait for things to settle down (somewhat longer than a Timeout), then do the stuff in the Restore case.
Redock.vi can also demonstrate the reentrancy of the package. When you run Redock.vi, it actually loads a version-specific VI, e.g., Redock 7.1.vi. Stop this VI and save it under new name, then save it again under a still different name. Load and run both these clones at once. Push the docking arrows, the Capture buttons, the Restore buttons, and drag the panels around the screen in any order at all. Each panel knows which one it is and never gets confused with the other one. (YOU may get confused; they won't.) Each always redocks properly. Each will stop properly and independently.
The code automatically adjusts for optimum performance with your specific version of LabVIEW from 6.0 through 7.1. It will be useful as an example if you're trying to migrate from polling to event handling (or vice versa, as was the case here). It certainly is easier to avoid race conditions with the event structure. Just keep the code within the event structure itself simple, as you would for any interrupt service routine, and mirror the event queuing by queuing your responses for handling in another loop.
March 10, 2004 - Launches different versions for different versions of LabVIEW [at Dan Bookwalter's prodding]. Detects minimized VIs in LabVIEW 7 [with Rolf Kalbermatter's confirmation that I wasn't overlooking the ability to do so in earlier versions]. Always dismisses launcher (March 9 LV7 version sometimes kept the launcher under WindowsXP and always did under Mac OS X.) [thanks to Jim Kring].
Did your projects ever become interlinked because you didn't notice a VI that was on the clipboard or off the screen?
Download this VI (LV6, 132 kbytes), put it in your project folder, and mass compile it. [For LabVIEW versions earlier than 7.0, there will be a warning that Ghost Buster 7.vi failed to load. Don't worry about that. It will never be called.] Load it when you switch projects (or every time you open LabVIEW) to make sure there aren't hidden VIs left over from one project when you load the next. The loader will flash onto the screen and quickly disappear. If, at any time, the only VIs, Globals, and Type Defs in memory are off the screen, are on the clipboard, are minimized [LabVIEW 7.0 and greater only], or have their panels closed, a large red warning panel appears in the center of the screen to warn you of the lurkers. (If an error occurs, this same front panel, colored white for this task, reports it in a standard error cluster.)
Eyes not what they used to be? Open Ghost Buster 6.vi or Ghost Buster 7.vi directly from Ghost Buster.llb and increase the amount that a panel can intrude onto the screen and still be considered hidden. (Ghost Buster 6.vi and Ghost Buster 7.vi are not auto-run, so editing them is easy this way. If you relaunch Ghost Buster.vi when Ghost Buster 6.vi or Ghost Buster 7.vi is already running, Ghost Buster.vi will stop with an error, making it easy to edit or inspect.)
Ghost Buster 6 assumes that you do notice minimized VIs. Ghost Buster 7 warns you if all VIs are minimized. If you know how to detect minimized VI automatically in LabVIEW 6, please let me know and I'll incorporate that feature in the next version.
Have you ever wished that LabVIEW treated your custom errors like the built-ins, with full call chain information and likely causes listed in the error dialogs? Would you like to be able to insert more detailed information at individual error sites and have that information appear in the dialog so you wouldnt have to pop up an additional dialog box to help the puzzled user?
Would you like to be able to specify your error with an intelligible enumerated constant rather than trying to remember which error code you assigned to which type of error? How about having these enums start at some code in the user error range (5000-9999)? Wouldnt it be nice if these enums could contain a few errors, e.g., file not found or timeout, with the error codes that NI assigns?
Different projects use different equipment. Wouldnt it be nice if lists of errors could be combined easily on a session-by-session basis so that youre only treating the errors pertinent to the current setup? Of course, if one set of error codes overlaps another you should get multiple possible explanations, labeled by package, just as the overlapping DAQ and GPIB codes are handled.
When you use someones DLL, wouldnt it be nice to be able to convert the (typically negative) C error codes to the LabVIEW User Error Code rangeand lift the C comments to use as explanations in the LabVIEW error dialogs?
How about being able to set a default error dialog type for the entire sessionand to change it temporarily or permanently at any point in the program?
All these features are included in the new error-handling package from .They are all compatible with the standard error-handling routines from National Instruments, so they integrate smoothly with your current code. You get to choose which features make sense for each project, or even each part of each project. (Severability! Who said that reading those licensing agreements was a waste of time?) See the details or download the package (816 kbytes) which includes all the details as well. (If you don't already have the OpenG toolkit installed, you'll need these OpenG subVIs (60 kbytes) also. If you downloaded Error Handler.zip before noon on June 19, 2003, you'll need the new version of Smart General Error Handler (40 kbytes) for compatibility with LabVIEW 7.0.) All three packages can be unzipped into the LabVIEW directory to add the files to the correct places in the directory structure.