Phillip Brooks

With a desktop this large, I could create larger block diagrams and obfuscate my code to the point where only I could edit it. Requires a dual-link DVI-D graphics card that supports WQXGA (2560x1600) resolution. Add the needed graphics card and you're over the price of a LabVIEW Full Dev. license! I guess I'll have to wait until next year, maybe Santa can negotiate a volume discount...

Using GPIB instruments? If you're working with GPIB based equipment, you can use the event registers if your instrument impliments it correctly. Using Service Requests in your GPIB application

Has anyone ever used the Lego products with LabVIEW? The new NXT controller makes this look like I would try this out. New LEGO MINDSTORMS Software to Be Powered by National Instruments LabVIEW Lego Mindstorm NXT robots are smarter and stronger than ever!

1 GPIB device with 2 PCs I've used the ICS Electronics 4842 to share an 8 1/2 digit DMM between two computers. I bought mine on EBay for ~$100; I think they cost quite a bit more than that retail though... http://www.icselect.com/gpib_extdr_ds.html#sw I saw one today on EBay

I agree with your observations, and wasn't aware of the change to allow NI-VISA distribution with a compiled application. I always use some sort of NI hardware (GPIB, etc) so licensing has never been an issue for me. I remembered complaints by LV developers who use serial interfaces, and after reading about the SerialPort class in .NET 2.0 put 2 and 2 together, got 5 , and thought to ask the question. I did revisit the M$ site and checked the OS support for .NET 2.0. Supported Operating Systems: Windows 2000 Service Pack 3 Windows 98 Windows 98 Second Edition Windows ME Windows Server 2003 Windows XP Service Pack 2 That doesn't mean it will PERFORM, but it SHOULD at least work. The later versions of NI-VISA only support NT, 2000 and XP. The .NET download is ~22 MB, and required available disk space is listed as 280 MB. The NI-MAX download is ~15 MB, the MAX folder on my PC is ~201 MB. I noticed that NI makes reference to an open source project called Mono that intends to offer .NET support for Linux and Mac; but I don't understand how it would be called from LabVIEW.

I've been playing with .NET in my spare time, The list of new features in the .NET framework v 2.0. includes a SerialPort class. I've read about some people being dissapointed with having to use VISA in order to access Serial devices; could this new .NET class be used to create a replacement for the old Serial Read/Write functions? Simple example of Serial I/O using C#.NET What's Playing? From MS Coding4Fun

Your problem seems to be more of configuration management one. If your LabVIEW stations are "instruments" then you want to treat them as such. I've used many traditional instruments where firmware and even OS updates (Agilent scopes) were regularly released, but I didn't because of dependancies and configuration management. Don't treat the instrument station as simply another PC on the network. Don't take crap from the IS department. They will likely say "It's a PC, it's on the network, and the company policy is yada, yada, yada... We own it, and it MUST have Netscape, TimeKeeper+ 2000 and the AutoChron Super Backup service running..." Don't install MS-Office, Norton AV, Firefox, or AOL IM. Don't use the instrument station for non-instrument functions like timeclocking or a print server. Disable Windows sharing, Windows Update, telnet, ftp and all the other unneeded services. Store your data directly on a server and access the results from there. If your IS department can't help you do this, point it out to the IT manager! To reduce the possibility of viruses, your instrument stations could be placed on a private LAN. The account(s) used by operators would not have admin priviledges. They could be further physically secured by removing floppy drives, disabling USB (disables removable media) and disconnecting the optical drive from the computer's bus. You might say "Hey, now it's hard for me to update or work on the instrument station. How do I load, debug, etc..." You will have problems with Linux, LVRT etc. The difference is that you won't have to support new OSs, manage LV licenses for different platforms or learn how to relink a kernel!

Copied from Info-LabVIEW posting, 29 Sept 2005: The deluge of thank-you notes and kind expressions that we have received since announcing the LabVIEW Technical Resource's last issue is greatly appreciated. The success of LTR during our 12 years of publication has been due to the great support from the LabVIEW community -- technical reviewers, authors, and customers. We want to express our appreciation to the LabVIEW community. The difficult decision to end production of LTR was not for profitability reasons, as has been speculated, but rather for rate of return reasons. Historically, applying these same resources and assets to other business/product lines that we own has resulted in higher rates of return. There has also been some speculation as to whether this publication should convert from print to electronic. LTR successfully converted some of its international product lines to fully electronic versions several years ago. However, the true cost of production of LTR product lines is not in the printing costs, but rather in the editorial, testing, and quality control effort to provide quality, applicable material that supports all platforms and LabVIEW versions. Those that have submitted articles know of the editing, review, and software testing cycles that goes on to provide technically accurate and applicable articles An idea was proposed on the Info-labview site that LTR should be included in the SSP package. We have discussed this type of value-added addition to the SSP program and other ideas with National Instruments over the years. However, other than successful pilot programs with a few international SSP programs, the idea was never formally adopted. As far as the future of the LTR Publishing business, two larger publication houses have expressed interest in buying our assets. We chose to stop publication efforts as we work toward this transition. There is no guarantee at this time that the content will stay LabVIEW based. It is possible our order fulfillment and production processes will be purchased for use with other content. It has been a great opportunity to work with the LabVIEW community - a passionate group generous with their time. We're proud to have supported the LabVIEW community and run a successful business for 12 years. Thank you again for the outstanding community support. Karen Pape Managing Editor LabVIEW Technical Resource 860 Avenue F Suite 100 Plano, TX 75074 Phone: 214-706-0587 x104 Fax: (214) 706-0506

Under the LabVIEW Help menu, select "Search the LabVIEW Bookshelf" Select LabVIEW Development Guidlines, or view on-line at: http://www.ni.com/pdf/manuals/321393d.pdf Other style info: From Bloomy Controls: Five Techniques for Better LabVIEW Code

You're welcome... There was a question about GUIDs on Info-LabVIEW. See attached... I tried to create a quick .NET version; Place a .NET Refnum on your front panel. Associate the Refnum with the class System.Guid You will find this by browsing and selecting the file mscorlib.dll. On my XP machine the path was C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorlib.dll Invoke the method NewGuid, then pass the NewGuid Refnum and invoke ToString. As always, clean up your references by closing them. From what I've read, this implementation may use a hardware specific value (network MAC address?) as a seed for the GUID. http://lists.ximian.com/pipermail/mono-lis...ary/003109.html Download File:post-949-1133787439.vi

I was looking for a method to validate large files in LabVIEW. The NI MD5.LLB source required passing a string which is not practical for a multi-megabyte file. I researched the .NET MD5 functionality, and put together this VI (LV Version 7.1). The .NET implementation is quite simple. I tested this VI against the labview_80.exe download (~450MB) and FastSum 1.3 Standard and was able to verify my download; see Download LabVIEW 8.0 Now! thread... FastSum took over a minute to run, the .NET calc called from LabVIEW took ~ 30 seconds... Enjoy! Download File:post-949-1133361444.zip

Subset of NI icons in your local installation: Program Files\National Instruments\LabVIEW 7.1\examples\instr\insticon.llb\Icon256.vi More on line at: http://www.ni.com/devzone/idnet/library/ic...rt_glossary.htm One trick I recently learned from this forum is to select a region inside your icon and then executing paste. The graphic will be scaled from the clipboard to fit your selected region. I've been opening MS-Word, finding something I like in the clipart gallery, copying and pasting it into my LV icons. There are recurring styles for some of the MS clipart that makes things look consistent, and I've even gotten some compliments :thumbup: for taking so much time to make meaningful icons!

I ran the VI on my computer, then made the changes Louis suggested, and saw similar improvements. I watch the NI Developer Zone RSS feeds and read "Optimizing LabVIEW Embedded Applications" and shaved some additional time off by following the advice to "use shift registers instead of loop tunnels for large arrays." When passing a large array through a loop tunnel, the original value must be copied into the array location at the beginning of each iteration, which can be expensive. The shift register does not perform this copy operation, but make sure to wire in the left shift register to the right if you don

I often change the display properties of front panel controls. For example, I hide the labels and display the captions or set the caption to bold text. If I multiselect (SHIFT+select) a group of objects, and want to apply a single (common) property, the change is only applied to the last selected object. I understand that not all FP items have the same properties, but there are SOME common properties for the class "Control". Individually selecting and setting properties is very tedious.

NI Toolkits?! What are those! I haven't yet worked for an employer that would pay the price for these :2cents: I long ago wrote my own interface to ADO, and have never been involved in PDA, imaging or FPGA development. In the consulting world, I'm sure that these tools pay for themselves quickly. Thanks for the insight.

See the online help: Generate Occurence Details Note National Instruments encourages you to use the Notifier Operations functions in place of occurrences for most operations.

Nice palletes :camera: ! Some of them look familiar, but some look very INTERESTING!

:thumbup: That was the trick, thanks Michael! :worship: I sometimes get worried about going "outside the box" with all of the layers; VISA, DAQ, MAX, etc... It was nice to find that LabVIEW is forgiving outside of the development environment too. I've been burned too many times by adding modules/drivers in other languages only to break something else...

Sorry to those who surf other boards as well; I'm in a crunch and can't figure out what to do. The more eyes, the better... I'm trying to upgrade an installation of LV6.1 to use the application builder. The computer was already built and had NI MAX 3.1 and NIDAQ 6.x.x installed. When I do a custom install to select only the Application Builder, the 6.1 Installer indicates that I have a later version of MAX and NIDAQ, and that it will replace MAX and NIDAQ with older versions. I can't "unselect" this! I don't want to change these; I've spent 3 months developing with the 3.1 and 6.x.x and can't afford to break my code now. How can I install the 6.1 App Builder WITHOUT touching MAX and NIDAQ?! Why does the LV Installer insist on replacing things that should not matter?!

LabVIEW 8 Easter Egg Seemed appropriate to pass along, this might also be worth cross-posting in the LV8 LAVA forum... Posted today, 19 Oct 2005 on the Info-LabVIEW forum; by Stephen Mercer: Easter Egg: A hidden feature of a piece of software, generally something that has no functional impact, just fun visual impact. I happen to like these little hidden corners of a product, provided they take up little to no space on the end user's harddrive. Since I started working at NI, I've put one or two into LabVIEW. But the one I planned for LV8.0 turned out to be a sufficiently good idea that it got documented. If you look at the documentation for the "icon editor dialog box", the last line of the documentation says, "Use the lv_icon VI template in the labview\resource\plugins directory to create a VI with which you can edit VI icons outside of the Icon Editor dialog box." In LV8.0, take a look in the directory labview 8.0\resource\plugins\ There you will find a file called lv_icon.vit. On the front panel of this VI Template are instructions for how to build your own icon editor that will replace the one used in LabVIEW when editing the icons of VIs. There is another file called SAMPLE_lv_icon.vi which is a trivial example of one such replacement icon editor. Just rename that file to be lv_icon.vi and then see what happens when you try to edit a VI's icon in LabVIEW. Have you ever wanted to be able to load your icon in some other piece of graphics software, edit it, and then put it into your VI without cutting and pasting every time you want to edit it? Have you ever thought about just building an icon editor in LabVIEW with features that you like? I saw comments on this mailing list recently about maintaining an icon library. You could write an icon editor that integrated such a library into itself. In short what started out as a project to open a backdoor for creating silly icon editors for an easter egg idea turned into a real opportunity for LV users to improve/change their icon editing experience. This is one of the small features of LV8.0 that most users will never need or want, but I figured some of the gurus on this list might use this feature to great advantage. Pojundery, Stephen R. Mercer -= LabVIEW R&D =-

Pick one, bone-head! :laugh: This is the message I got once when trying to compile a Novell Shell driver using the Netware 2.x (Late 80s). I was specifically trying to create a dialup driver by following the instructions in the manual. There were two dialog options; OK and HELP. I Clicked HELP and saw a duplicate box with OK and HELP. Tried HELP one more time and got "Pick one, bone-head!" :laugh: I reported it to Novell and got an appology letter. Don't know what happened to the programmer, but I imagine in today's environment, one might be let go for that.

It's not the same as a FP group, but you could use a loop with count of 1 or a sequence structure to create a grouping.

I Moved up to 1280x1024 with my new job. The Dell I received has a nice monitor and graphics card, and the legacy code I work with was done on a dual screen 1280x1024 setup (lots of scrolling made me give in). I had created a two tone background image that gave me a 1024x768 rectangle in the upper left of my screen so I could check my front panel size for use on the ATE computer. After attending the LabVIEW Intermediate I&II classes, I found a couple of similar backgrounds on the CD that also left room for the menu bar (assumed bottom) so I use this instead. (See attached) I don't maximize the diagram, I use the extra real estate for the control and tool palettes. The only time I find myself scrolling is when I start getting into ActiveX calls and control references; the size of the property and method nodes don't make things easy.

Image Toolbox by George Zou. http://www.geocities.com/gzou999/gtool.html The diagram have been removed, but the output returns Pixmap data for use in your application.

If your application is already built, it may take some work. Whenever I've needed to load parameters from an INI file, I: 1. Create clusters that contain the variable elements that I need to read/write. 2. Save these as typedef'd controls and use these in my sub-vis. 3. Use the OpenG INI read and write functions to load and store the clusters in INI sections and variables. If a variable is added, you can edit the typedef'd control. This should update anywhere you've placed the control. Don't change the order of your cluster elements, just add elements to the end. By using simple typedefs instead of strict, you can move the elements around within the cluster frame on the front panel without breaking your code; you can even hide elements that you don't need. I generally try not to delete elements from my clusters once I've added them. If your software design process is working, you shouldn't need to make that many changes