Chris Davis

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)

I was able to get the Zip file extractor to work with the batch file... seems like kind of a round about way to do it, but it works.

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)

What about just output? I was thinking along similar lines recently. I have to send a timing pulse to 8 different locations to start a process. My first thought was to use a cheap NI DIO board, but the idea of being able to use the parallel port and save myself a PCI slot sounded pretty good too.

Thanks,

Gary

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)

if i have to choose either parallel port or 6024E DAQ for digital signals and control , which one to choose ?

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)

But we would loose the backward compatibility as many LabVIEW programs expect VI s to include both source and binary.

Tomi

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)

Got this USB-bracelet (I was very thankful NI didn't go for the USB-thong) on NI-days here in the Netherlands. It holds a lot of the presentations given!

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

Since you mention it, how do I plug in to the project UI?

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)

VIs can be dynamically called in an exe, in an LLB, or just in some directory as long as the correct path is supplied. For my "plug-in architecture", in development mode, I store my dynamically callled VIs in a dedicated sub directory.

...

For my exes I roll my dynamic VIs into my exe. In the past I have left them out, but for various reason I now perfer to intergrate them in.

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

After rebuilding (by the way, why does OpenG builder take so much longer to build stuff than NI's version?), the error at runtime changed to 1390 when attempting to load the dynamic VIs. This gives a 1026 (invalid reference) when trying to run.

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)

LabVIEW 7.1 and below requires that you set your VI to be 'reentrant' if you are using that VI as a wrapper for calling a dll. I am not sure if LabVIEW 8.* does not require this. Unfortunately in LabVIEW 7 and below, you could not debug your VI if you set it to be re-entrant

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.

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

If all you are trying to do is print a text file out, you could use notepad. Just call notepad with a /p option at the command line.

notepad.exe /p "c:\logfile.txt"

What you are seeing is the fact that your plugin VI's can't find the vi.lib files it needs to execute. You'll have to package your plugin's as LLB files using either the OpenG Builder (what I reccommend, particularly since you will probably need "name mangeling") or the NI application builder. Basically an EXE doesn't have access to vi.lib, and the application builder only includes the vi.lib files your exe needs to run. BTW, when you build your plugins, either in the OpenG builder, or with the NI Application Builder, you will have uncheck the option to exclude vi.lib files, user.lib files, and (possibly) instr.lib files. There has been discussion on this topic elsewhere on LAVA before, but I can't find it right now.

QUOTE(Thang Nguyen @ Mar 20 2007, 09:20 AM)

Hi Chrisdavis,

I forgot about the AI-110 :headbang: . The current for the system is really small about 100mA. In this case, if I have the battery connect to the system, how should I connect to the AI-110 as a current source to measure the current?

I also need a voltage converter from 12V - 5V. Because this is a low power system, I want to look for a good converter. Could you recommend me any product?

Thank you so much,

Thang Nguyen.

Sorry I can't help you much more, we've stepped outside my area of expertise. You should be able to ask an electrical engineer, who would be able to help you out with the circuit design and connections needed to turn current into voltage. As for DC to DC converters, look at http://www.digikey.com' target="_blank">DigiKey, they have a ton of them, and can help you pick one out to fit your exact needs.

Sorry I can't be of more help.

Chris

QUOTE(AnalogKid2DigitalMan @ Mar 21 2007, 08:51 AM)

I haven't built my first installer in 8.2 yet, but have also wondered why MAX shows run-time engines for 7.1, 8.0, and 8.2 with a fresh LV8.2 installation.

Some of Max's test panels were written in LV 7.1, thus the need for the 7.1 RTE. I suspect that something else in Max may have been written in 8.0, thus the need for that RTE.