 |
|
How do I dial a phone? Tone dialing is a combination of two tone frequencies output through your system's soundcard. Version 5.1 contains an example on how this is achieved in EXAMPLES\SOUND\SNDEXAMPLE.LLB\SIM PHONE.VI. The frequencies (Hz) to output are: Number Hightone Lowtone LabVIEW also allows direct access to the serial lines and can dial a modem using standard modem commands. How do I get the command line parameters for my program? Search NI's Example Programs Database at this web address: http://digital.ni.com/explprog.nsf/$$Search for "command line". It will give you a VI that does returns the command line parameters for a LabVIEW program. What are the undocumented LabVIEW ini settings? These are the possible strings that can appear in the LabVIEW preferences file (or .ini file for those who are 8.3 limited). Some of them are obvious as to what they control and what arguments they take. Others are a bit obscure. The "xxxxx" option for example is not chosen for its natural associations. Some of these values are set by the normal preferences dialogs and some are for specific platforms. Others can only be set by the preferences file (the masscomplog for example). Brian Renken has recently hosted a site that details all these settings and will probably be a more uptodate listing. You can find this at: http://LabVIEW.BrianRenken.com/INI/ Should I play with the undocumented LabVIEW settings? The options that aren't in the preferences dialog are generally considered to be not useful or even harmful. They are sometimes there to allow National Instruments a backdoor or a workaround for when the LabVIEW development team changes a behavior. They are also used to turn on obscure development features that the developers use to make or debug LabVIEW. These obscure features are typically kind of like the attic or basement of a house, not finished out, not very interesting, and potentially harmful. The LabVIEW developers have never tried to hide any of these strings, but it is unlikely that you will gain any benefit from trying out various combinations of the settings. If you ask technical support what a setting is, they will likely tell you that they have no idea. They are telling you the truth. Even Greg McKaskle would not know what some of the settings do without checking the code. Others, such as exoticcontrols, no longer do anything. It was once used to show a control palette submenu that contained controls that were still in work and not ready for prime-time. They were experiments, unsupported features, and guaranteed to crash if you did much with them. Just the sort of thing that is needed for development, but not useful to even advanced LabVIEW users unless they have a death-wish. If you experiment with the .ini file and you crash mysteriously losing hours of work, I'd suggest putting the file back to the way LabVIEW left it. Don't ask tech support to fix it or complain that the LabVIEW attic has rusty nails and splinters. Resedit is a low level tool that in the right hands is useful, in the wrong hands, well, its in the wrong hands. For the person that likes taking a multimeter and a soldering iron to computers and household appliances, its exactly what you always wanted. If you start monkeying with things in the resources or the .ini file, use common sense and do it on a copy or you will just end up reinstalling LabVIEW. Once the fun and experimentation is over with, I think you will agree that the useful options, with very few exceptions are in the Preferences dialog. How do I include LabVIEW ini file settings with my built application? There are a several situations where you might need to do this. Examples include gaining access to COM ports greater than COM10 and including fixing the fonts used on the front panel objects. To include ini file settings you need to copy the settings from your LabVIEW ini file and save them in an ini file with the same name as your application. For example if your program is MYAPP.EXE then the ini file would be MYAPP.INI. Furthermore you need to edit the section name in the ini file to match your program name. If you look at the LabVIEW.INI file you will see that the section name is [LabVIEW], you must change this to match your application. eg [myapp] in our previous example. Place the ini file in the same directory as your built application. How do I build an executable and what files do I need? The LabVIEW development environment is somewhat unique in this respect. National Instruments supply the development system in several flavours. The Base Development System does not include the ability to compile programs (as EXE's), but does allow applications (VIs) to be run under the development system (and the code is compiled code). The Application Builder can be purchased separately or as part the Professional Development System. There are a couple of good resources on building executables on the National Instruments website. Check out the following: http://www.ni.com/support/trouble/labview/toolkits/appbuild/lv51ab.htm What is good LabVIEW programming style? Originally there existed a document entitled "LabVIEW with Style" -- A Guide to Better LabVIEW Applications for Experienced LabVIEW Users", authored by Gary W. Johnson and Meg F. Kay. Consider this document to be nominally obsolete. It is on the CD-ROM with the book "LV Graphical Programming" but was lost from the Info-LabVIEW ftp site with a great directory shuffle there some years ago (it was in a now-absent DOCS directory). The document does not appear to be on the NI ftp site either. There is a much better reference available now. If you buy the Professional version of LV6.0i, you get a printed manual called Development Guidelines. Even if you just get the non-pro version, install all the PDF manuals and you will find the same document as DEVSTYLE.PDF. It's a wonderful little book, written by the VI Development team at NI with input from many... including that ancient style guide that Meg and I worked up. Highly recommended. Also on the NI website a search for STYLE GUIDE will locate the "Rules To Wire By" series by Rande Johnson. It's a great series, and may well meet your needs. Lots of wisdom there. There are more works in progress on this subject, including one or more books (NOT by me!). And NI will keep revising the Development Guidelines book. Why does my EXE have the wrong date? Under some operating systems a built application in LabVIEW versions 5 and 6 (specifically Windows based machines) has the last modified date reported by Windows for the application exe file consistently set to the same value and not to the current date and time? This occurs regardless of the settings of the system clock. It appears that this is a bug in the Windows operating system. As far as we are aware, Microsoft has been aware of it for at least three years but the bug does exist at least under Windows 95 and 98. It is unknown whether the newer versions of Windows (including NT) still exhibit this problem. The problem occurs when the LabVIEW Appliction Builder copies the standalone stub from the APPLIBS directory (applib.llb) to the exe file and appends the VI code to it. The Windows functions used for this should modify the modified date of the file but leave it at the date of the original stub There are also a couple of alternative user workarounds. If you are not parcelling up your application into distribution disks you can "touch" the built exe with the linux utility of the same name (free downloads of win32 based touch utilities are available on the net; e.g. from the CygWin project (http://sources.redhat.com/cygwin/)). Alternatively you could write a small application that reads one byte of the file and then writes that byte back to the file, thereby updating the modification time and date.You could also modify the applib.llb stub file directly just before building the application with either of the touch methods described above. This modification of the stub file will at least ensure that the files heading for the distribution disks end up with a file time and date close to that of the final build process. How do I save my LLB VIs that contain bad filenames? When saving VIs from a LLB (library) file to directories, the LabVIEW File Manager sometimes responds that it can not handle the "bad" filenames. The problem is that some of the files in the LLB are saved with "/", ">", "<", "?" characters in the file name, and these do not translate into valid filenames in the target file system. The solution: If I uninstall LabVIEW I get an "Error Applying Transforms". What the ...? When LabVIEW 6.0i was released there were several issues with the installers for LabVIEW and its drivers. This was such a nightmare that several of the team working on this wore t-shirts with "we know the installers don't work ..." at NI Week 2002. The solution: |