Chris Davis

QUOTE(Mike Ashe @ May 10 2007, 08:03 AM) You have this option, but it is probably more than most people want to wait for. I agree the LabView related emoticons might help some people understand a text based explanation of LabView. I don't know if Mike can add them or not, but I don't think he's added the emoticons from this page yet, so it may not be possible...

QUOTE(crelf @ May 7 2007, 07:50 AM) I'll work on it, although I'm not quite sure how to start a new wiki article, I've just edited one that already existed. Guess I'll have to learn.

QUOTE(JodyK @ May 7 2007, 03:46 PM) I had this problem with the 6009 as well, but it was because I had used it with DAQmx base at first. http://digital.ni.com/public.nsf/allkb/634CEF92DEC749CB8625703800708FC5' target="_blank">This link might clear up the problem. QUOTE I sent my client an installer with just the latest application built, and a link to download and install DAQmx 8.5 on his own. I really like the idea of the NI installer builder, but I have never gotten it to work effectively. Does anyone out there have any good experiences with it? Any tips to make it work more effectively? I use the install DAQmx by CD or download method as well. I have used the NI installer in the past around LV7, but quit after I found NSIS and was able to understand it and use it for my installs.

Chris, I don't know if you meant to post this in the lounge, it sounds like a response to a different thread. I personally think this topic might make a good wiki article. I'm sure you'll get lots of responses so I'll throw my two cents in too. Upgrading versions of software, LabView or any other software, is a time consuming thing. It should never be done in or around "crunch" time. Having a source code control system is a must to make the process of falling back to an older revision easier. Use a virtual operating system to test out your "this upgrade is a piece-of-cake/walk-in-the-park/5-minute-job" theroy. Finally, my rules to upgrading new software 1. Backup 2. Backup 3. Backup If all else fails, remember to use your backups.

There is an OpenG VI that sizes the window to the "content". Jim posted a blog entry on Resize front panel to largest decoration, which is very similar, and may be more appropriate to what you want to do.

QUOTE(Noxious @ May 3 2007, 04:51 PM) You might also want to check out http://nsis.sourceforge.net/Main_Page' target="_blank">NSIS. I've used thier install packager and have been very pleased. It is free, and open source. One potential downside is that it has its own language to build installers with, and you will have to learn it to make more complex installers. The upside is that it has great help files and examples which will guide you through any problems you might have. Since it can be run from the command line, it can also be setup to rebuild your install package when executing an EXE build (providing you are using the pre/post build VI features of OpenG Builder when building your executable).

Take a look here. Brian is active on these forums, and I'm sure an email to him would make sure it will do what you want.

I made this modification to my copy and I was able to add files recursively. I didn't make an exhaustive test, just a couple of files, but I don't see why it wouldn't work all the time. With a few more UI tweaks it could be made to be turned on with a checkbox. The old version http://forums.lavag.org/index.php?act=attach&type=post&id=5667 The new version http://forums.lavag.org/index.php?act=attach&type=post&id=5668 Jim's workaround has the nice capability to not add subversion and CVS files, which could also be added at this point in the code. On second thought, that capability might be more appropriate if added to the recursive file listing VI in the OpenG file package...

I believe OpenG Package Builder will allow you to package any type of file, not just VIs. I do believe Tomi would like a way to recursivly add directories of files to an OpenG Package which is a valid request for the package builder.

QUOTE(Gary Rubin @ Apr 28 2007, 08:30 PM) If you've got USB you could try http://sine.ni.com/nips/cds/view/p/lang/en/nid/201630' target="_blank">one of these (USB 6501) for only $99. DAQmx compatable, using an express VI you'd be done in 5 minutes or less with the DIO part.

QUOTE(ControlEngineer @ Apr 27 2007, 02:52 PM) Thats easy, choose the 6024E. Don't worry about the differences in this case. Its easier all around to program the 6024's DIO ports than trying to use the parallel port as DIO.

QUOTE(Tomi Maila @ Apr 26 2007, 10:41 AM) Since this change would only happen on a new version anyway, it would be up to this "new" version of LabView to handle converting between text-based source files and binary-based source files. (i.e. LabView 8 can open LabView 7 files, but not vise versa.)

I have been using these same API functions for camera data streaming, with these API functions, 8 SATA hard drives (RAID 0) and a Highpoint RAID controller, I can sustain a 400MB/sec stream of data for more than a minute. You do have to pad your data to be a multiple of 512, but for me that is possible. In fact to stream a camera that doesn't have a frame size that is a multiple of 512, I pad the file until it is a multiple of 512, then reread the temp file and remove the padding for the final data file. Another issue I found when I started using these API funtions was the inability of C's fwrite function to write a file bigger than 4 GB. So now I use these functions for writing any file I need that have a possibility to being over 4 GB in size. I've used these functions, with no changes in 2K and XP, not yet in Vista. One thing to look at is the MSDN entry for these functions, which lists what operating systems they are avaliable in.

QUOTE(tcplomp @ Apr 17 2007, 04:11 PM) That actually looks useful, maybe I'll get one soon. I just hope this doesn't replace the screwdrivers...Those have saved me many times in the past...

QUOTE Nice segway... I figured you had thought of parsing the file itself.

The project file is just an XML file, so it could be parsed, and a tree control could display the information, just like it does in the real project explorer. If your scope was limited to opening / switching VI's that appear in the "subpanel" area of your mock up, you could make it happen. Good luck.

A similar question was asked here

I've back saved the control to LV6.1 but I can't post it from the computer I'm at, I'll try to post this evening.

QUOTE(gleichman @ Apr 11 2007, 09:40 PM) If you can a VI in the run time environment that is not contained within the executable, you will be running that VI in a totally different execution environment, it will have no access to any of the VIs in your executable and must be built to run totally independent of the main executable. The type of plugin architecture you (and the original poster) are using bundle the plugins into the exe as dynamic VIs, which works fine, until you need to add or change plugin, at which time you will have to redistribute your exe file with the new/changed plugin. It appears the original poster did not add his plugin VIs as dynamic VIs, based on what his later posts indicate. He has now added those VIs as dynamic VIs to his executable build and things are working for him. Jpdrolet provided an alternate method of sharing VIs between the main executable and a plugin by linking the VIs you would like to share between the EXE and the plugin to the VI as it exists in the EXE. This could be a tedious manual process, depending on the number of plugins, so jpdrolet has suggested he would look at adding this capability to openG builder in the future. It is possible that this method will not work in LV 8.2+ because NI changed the built executable design from previous versions of LV. Another alternative to communicating between plugin VIs and a main executable is to use a queue based messaging system to transfer messages and/or data. I currently use this method. I also build all of my plugins as LLB files that include all the VIs needed to run, including VIs from VI.lib, instr.lib, and user.lib, this gives me the capability to change a plugin, or add new plugins without rebuilding the main executable. This can be important if you want to distribute your executable to a large number of customers, while providing each customer a customized set of plugins. It also lets your users add plugins to your executable, without having the source code to your program. Does this help?

I hadn't heard and/or thought of this technique, very interesting option. Do you know if this technique would work in LV 8.2+?

QUOTE I don't know the answer to this question, but I've thought it myself a couple of times. I don't mind it since I have SO much flexibility with the OpenG Builder that I can let it take a little longer to compile. As for including your dynamic VIs in your built application... I've done this as well, and you don't end up with a true plugin system. Everytime you change an old plugin or make a new plugin, you have to recompile and redistribute your whole executable. You don't end up with a true "plugin" system, although I think you will find that your LV2 globals will work since everything is included inside a single exe. To create a true plugin system (see definition below) you'll have to use something besides a LV2 global to communicate and transfer data from plugins to main program, but you'll get the ability to expand the program without recompiling it. If you share your API set with others, you'll also have the ability to have other people expand your program to fit thier needs. True Plugin System: A main executable program that can have additional functionality added at run time by adding a file to a known location (usually a directory underneath the EXE file in question) without having to recompile the executable. This type of architecture demands preplanning to provide a known documented API set to the developer of a plugin.

QUOTE(alukindo @ Apr 9 2007, 06:25 PM) I've used many dlls in LabView 7 and have never had to set a VI that had a DLL to reentrant. If you can find the knowledge base article(s) with this information please post them. In my experience, it is usually a problem with the setup of the DLL being called, or in the DLL itself. If you can get the function to work in a simple C program the way you want to call it from your DLL you are probably in business. Although I have found that DLLs that allocate thier own memory (as yours seems to do) usually require a seperate wrapper DLL that you have to write to make them function reliably in LabView. YMMV BTW, I did try and open your code, but since it was saved in 8.2.1 I couldn't open the actual VI. Since 8.2.1 was released less than a week ago, you might consider backsaving to something that is a little more universal, so those who haven't even gotten thier 8.2.1 CDs can actually view the code in LabView. Just a suggestion...

I've been working on a similar project, but I haven't been trying to use VIs in my main application in my plugins. I ran into the same problem you have when I did try to do that. I ended up using a set of communication queue's to communicate information between the program and the plugins. Its really not that difficult, if you go ahead and document what the communication will be, and what each command will expect as an answer. I've got two queue's setup, one for commands, and one for data. I've got an independent loop in my main program that watches the communication queue for commands, then feeds data to the ones that need it, or simply acknowledges the command on the data queue. Good luck, let me know if I wasn't clear enough here.

The FTP icons came from the internet toolkit, it is included with a Developer Suite, and can be purchased seperately.

I typed in webcam to the LAVA forums search, and got two results which will help you. Next time try our search engine first. 1 and 2