贴个英文FAQ－Active X，数据采集，杂项

Active X
Can I use Active X and OLE from LabVIEW?
<Chris Hecker Chris.HeckerATCAS.honeywell.com>
(Timeless)
LabVIEW from version 5.x allows the use of Active X. DDE was supported in version 4 onwards. Version 5.1 includes Active X events.
The resource "Understanding ActiveX and OLE " by David Chappell is useful as a starting point. It's written at a high level with little or no code. You do need to gain an understanding of COM by reading the first few chapters before jumping to ActiveX containers.
If you decide to go with ActiveX as opposed to OLE, then the VI usage is limited to the invoke node, property node, and to the G data node. Out of these, the property node is the work horse. Connecting the ActiveX refnum to the refnum input of the property (or invoke) node allows you to specify which property (or method) you want to manipulate. Depending on the property used, you may find that the output from the node is another refnum that serves as input to another property node which then exposes a set of lower level properties that you can use.
If you use OLE, things work in a similar manner, but instead of embedding a control in your program, you're (essentially) creating a script that uses a different application. The application is referenced by using the open automation node. Specify the application by using the Select ActiveX Class offered by the Open Automation VI. The automation open refnums must be closed when finished with them by using the Close Automation VI. As for refnums created by cascading to lower level properties, it is adviseable to close them, but it may not be necessary (unconfirmed).
As for help on specific controls, you will have to rely on the help provided with the controls. COM specifies an interfacing method; there's no (easy) way LabVIEW can know about the properties and methods provided by the controls.
The capabilities offered by including COM in LabVIEW add to the flexibility of the language but, like CINs (Code Interface Nodes), exposes the developer to a lot of the lower level programming issues that were eliminated by LabVIEW. There's been some interesting discussion on the Info-LabVIEW list server concerning brittleness of LabVIEW applications due to different versions of applications, particularly MSOffice. Also, be aware that LabVIEW ActiveX containers do not support events before Version 5.1. So, if you want to respond to a double click on the leaf of a TreeView control, you won't be able to use the double click or hit test methods unless you upgrade your version.
(back)
How do I write data to an Excel spreadsheet?
<Paul Sullivan PaulATSULLutions.com, Alex Le Dain alexATicon-tech.com.au>
(Sep 2000)
Firstly, do you really want to? Certainly Excel and LabVIEW have supported direct communication, whether by OLE, DDE, Active X, or Apple events (for those of us on the minority platform), for many years. (I used direct communication between LabVIEW 3.0 and Excel 4.0). The problem is that Microsoft changes the protocols with every upgrade to Excel. All your carefully crafted code breaks and needs to be redone. Consider the possibility of communicating instead through a tab-delimited text file. That will work with any version of Excel and a large number of other programs as well. LabVIEW supports tab-delimited text files (and other delimiters) with File I/O >> Read From Spreadsheet File, File I/O >> Write To Spreadsheet File, and String >> Spreadsheet String to Array.
Other issues can be incompatible versions between the development system and the target system and does the target machine even have Excel on it? When developing for a general audience, stay with the common denominator.
And what if I still want to write to Excel? Well there are essentially two options. One is to buy a commercial product such as XL-VIEW (see Other Links and Resources) or the Report Generation toolkit (http://sine.ni.com/apps/we/nioc.vp?cid=5769&lang=US). The other is to experiment with Automation. To summarise this process you need to open an automation connection to Excel, and use invoke and property nodes to open a workbook, and then a worksheet, and then you are ready to write to a cell. The Developer Zone on the NI web site (http://zone.ni.com) has several examples on accessing Excel. Furthermore there are ready made snippets in the LabVIEW examples directory (examples\comm\ole-excel8.llb).
(back)
Can I control Word from LabVIEW?
<Alex Le Dain alexATicon-tech.com.au>
(Feb 2003)
Yes you can. The issues on controlling Word are the same as those for controlling Excel. If you have the time you can develop your own code to do this, check out the examples at the Developer Zone (http://zone.ni.com), or perhaps purchase the ready to run WordVIEW toolkit (see Other Links and Resources). Furthermore NI has released the Report Generation toolkit that gives access to report generation using the Windows Office suite (http://sine.ni.com/apps/we/nioc.vp?cid=5769&lang=US).
(back)
How do I set the icons of a tree view control?
<David A. Moore David_A_MooreATMooreGoodIdeas.com>
(Jan 2001)
First create two ActiveX containers on the front panel. Place the TreeView in one, put an ImageList in the other. Second, right click on the ImageList and bring up the editing dialog by selecting either Property Browser or ImageList|Properties (I suggest the latter). Thirdly, use the editing dialog to paste in the images you want and set any other properties. Fourthly on the block diagram set the ImageList property of the TreeView to be the ImageList. Lastly, select the images by name or number for each Tree node.
(back)
Data Acquisition
I am experiencing crosstalk. Should I be angry?
<Chris Regier chris.regierATni.com>
(Timeless)
Crosstalk is the influence of one channel on the measurement of another channel. Therefore the signal of a channel may be influenced by its neighbouring channels and vice versa.
Crosstalk behavior is not surprising at all, and is common to all DAQ boards with a scanning front end. Scanning works great under the right circumstances, yielding highly accurate results at low per-channel cost, but it can cause all sorts of problems under certain conditions. To explain what is happening; there is capacitance at the output of the channel multiplexer on the DAQ board. DAQ board manufacturers don't put capacitors there, it comes for "free" as an undesired effect in the multiplexers, PGIA, and board layout. Anyway, when you scan, the voltage on one channel gets stored on the capacitance and transferred to the next channel in the scan. If the impedance of the source on the second channel is not low enough, the source can't charge the capacitance to its value in its allotted time, and you get the crosstalk effect.
(back)
Is there a workaround to the crosstalk problem?
<Chris Regier chris.regierATni.com>
(Timeless)
There are several things you can try. First, don't scan any faster than you have to, and set the interchannel delay as large as you can tolerate. I'm not sure what value of interchannel delay NI-DAQ picks for you as a default, but I know you can change it easily by wiring up the appropriate control. Obviously, don't scan at all if you don't have to. Second, use low impedance sources. Try to stay under 1 kohm. Third, scan a grounded channel between your other channels. This will discharge the capacitance, and virtually eliminate the channel coupling. However, if your source impedances are too large, your channels still won't read correctly, since they'll still have to charge up that capacitance. This method also costs you one channel and half your speed.
(back)
How should I measure the relative phase between two noisy signals?
<Paul Sullivan PaulATSULLutions.com>
(Timeless)
Usually the best way to measure phase angles between noisy signals is the CrossCorrelation function in Analysis >> Digital Signal Processing. Crosscorrelation (whether by this VI or any other means) uses ALL the data at ALL phases to determine the relation between the two signals, so its signal-to-noise ratio improves as the square root of the number of samples processed. No fancy sampling near a single site (peak or zero crossing) can match this S/N. And crosscorrelation works even for signals that are wildly non-sinusoidal.
In fact, it is a good general rule to use as much data as possible in ANY measurement. For instance, use rms measurements to determine the relative amplitudes of two noisy signals, autocorrelation to measure frequencies, etc.
(back)
Is there a way to scan SCXI 1100 or 1102 channels out of order?
<Ted White twhiteATdateppli.com>
(Timeless)
There is a hardware limitation on the 1100 and 1102 cards that only allows you to scan contiguous channel lists. You must scan this way but you do not have to read all the channels. If you use the "Channel to Index.vi" (from the "Calibration and Configuration" palette) and "AI Buffer Read.vi" (from the "Advanced Analog Input" palette) you can read a subset of the channels that have been scanned.
(back)
Why do all the Fieldpoint examples not use FP Read. Should I FP Advise someone?"
<Aaron Gelfand>
(May 2002)
This question was posed: "I'm doing some FieldPoint work and in perusing the examples I became
curious. Most of the examples show reads from FieldPoint using the FP Advise function even though a read function is available. Does anyone know if the Advise is better for reading the I/O and why?"
and Aaron Gelfrand from National Instruments replied:
Actually, at this point we have been re-writing the majority of the examples to use the FP Read.vi rather than the FP Advise.vi. There is a simple fundamental difference between the two although they can often be used interchangeably. The FP Read.vi is synchronous and the FP Advise.vi is asynchronous (and can be trickier to use).
What does this mean in terms of use? Let's illustrate by creating a system consisting of a computer with LabVIEW, an FP-1000 (a serial network module) and an FP-AI-100. We create a program that starts with an FP Open.vi, a FP Create Tag.vi and then in a while loop, we place a FP Read.vi. Also, in the loop, we need to place a delay timer such as wait until next millisecond multiple. If we give our timer a 500 ms value, then every 500 ms, the loop will execute. When the loop executes the FP Read.vi, the read calls into the FieldPoint Server which in turns polls the FP-AI-100 using the !G optomux command (see the FP-1000/1001 Progammers Reference Manual for information on the Optomux protocol used by FieldPoint Serial modules). The FP-1000 responds to the poll by reading the FP-AI-100 and sending the data back. Then the server returns the data to the FP Read.vi which passes it to your chart (or whatever you do with the data). The key thing to note here is that the command sent to the FP-1000 is only sent each time the FP Read.vi is executed.
Now, let us create the same program using the FP Advise.vi. Using the FP Advise, one parameter that we give it is Advise Rate. The Advise Rate causes the FieldPoint Server to set up an asynchronous callback that occurs automatically at the advise rate. So we start our program and the FP Advise (on the first iteration) starts the callback. What now occurs is that the FieldPoint Server polls the FP-1000/FP-AI-100 at the specified advise rate automatically. Whenever the poll occurs, the FP Advise.vi is notified. So how exactly is this different? Well, for one, we no longer need a delay timer in our loop. The FP Advise will always trigger at the advise rate (note: it may be slower depending upon the number of channels on the system). Additionally, we now have the option of having the FP Advise.vi returning data on data change only, allowing you to put the while loop to sleep while data is not changing. In other words the FieldPoint Server is polling the module but your LabVIEW VI can be asleep allowing more processing power to be used by other parts of your program.
So, when do you use the FP Read vs the FP Advise? The general rule of thumb is to use the FP Read.vi when you are newer to FieldPoint programming, if you need to multiplex FP Refnums (for example create an array of Refnums, then use a For Loop to index the array), or when you will have multiple FieldPoint accesses in a single loop. The FP Advise.vi should generally be used for individual loops that should be put to sleep for specific intervals where there is no additional processes in the loop that will be adversly affected by the timing of the FP Advise or the On Change option.
Since the FP Read.vi is easier to use and less prone to being misused, we decided that the basic examples should illustrate the use of the FP Read.vi and that more advanced examples would demonstrate the proper use of the FP Advise.vi.
(back)
Miscellaneous
How do I dial a phone?
<Alex Le Dain alexATicon-tech.com.au>
(Timeless)
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
1 1209 697
2 1336 697
3 1477 697
4 1209 770
5 1336 770
6 1477 770
7 1209 852
8 1336 852
9 1477 852
* 1209 941
0 1336 941
# 1477 941
LabVIEW also allows direct access to the serial lines and can dial a modem using standard modem commands.
(back)
How do I get the command line parameters for my program?
<Brian Renken BrianATRenken.org>
(Timeless)
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.
(back)
What are the undocumented LabVIEW ini settings?
<Scott Hannahs sthATmagnet.fsu.edu>
(Timeless)
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/
(back)
Should I play with the undocumented LabVIEW settings?
<Greg McKaskle>
(Timeless)
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.
(back)
How do I include LabVIEW ini file settings with my built application?
<Alex Le Dain alexATicon-tech.com.au>
(Jan 2001)
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.
(back)
How do I build an executable and what files do I need?
<Alex Le Dain alexATicon-tech.com.au, Mark A. Hanning-Lee mhanning-leeATsyagen.com>
(Timeless)
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
http://www.ni.com/support/trouble/labview/toolkits/appbuild/common51.htm
(back)
What is good LabVIEW programming style?
<Gary W. Johnson johnsongATllnl.gov>
(Jan 2001)
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.
(back)
Why does my EXE have the wrong date?
<Rolf Kalbermatter rolf.kalbermatterATciteng.com, Alex Le Dain alexATicon-tech.com.au, Jean-Pierre Drolet jean-pierre.droletATtr.cgocable.ca>
(Jan 2001)
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
file. Although NI could theoretically add a manipulation to the Application Builder which really "touches" the file to update the modification date, this is only a workaround for someone elses bug. A fix for this bug is available from: http://www.cybertechs.qc.ca/~jpdrolet/labview
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.
(back)
How do I save my LLB VIs that contain bad filenames?
<Brian Renken BrianATRenken.org, Albert Geven albert.gevenATphilips.com>
(Jan 2001)
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:
1. Make a backup. VERY IMPORTANT!
2. Load the hierarchy as-is, including all the VIs that call the problem VIs (ie those that give bad filenames).
3. Open the problem VIs and give them legal filenames using the "Save As" File option.
4. Close all the other VIs, saving any that have changed (ie callee's path has changed).
5. Use the File Manager to delete the bad VIs.
6. Convert the LLBs to directories.
(back)
If I uninstall LabVIEW I get an "Error Applying Transforms". What the ...?
<Alex Le Dain alexATicon-tech.com.au>
(Feb 2003)
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:
1. Execute regedit or regedit32 depending on your platform (ie Start/Run, type regedit32, OK).
2. Do a search and find the following section in the registry: HKEY_CLASSES_ROOT>>INSTALLER>>PRODUCTS with the value of 20F22BE295933D11082B000540F95DD5
3. Delete the TRANSFORMS field.
4. Exit regedit.
5. Try the uninstall again.
6. Ignore the laughter of the MAC only LabVIEW users.
(back)