ars_stowers

QUOTE(yen @ Jul 27 2007, 07:54 AM)

Yes, while your CPU can perform operations very fast, Windows is a standard OS and as such does not gurantee timing. It can take the CPU from you and cause LV to wait every once in a while for its own purposes. See here and the posts it links to for some more details.

Some options:

Use a real time OS with LabVIEW RT (see crelf's blog).
Increase the priority of your process and thread both in Windows and in LV.
If you have a DAQ card with a hardware timer, you can use its triggering to get more accurate timing.

I will try to increase my thread priority and see if that helps. Having never messed with priorities in LabVIEW, how does one go about doing this?

Additionally, can you point me in the right direction to see some examples of using triggering to get better timing from a DAQ card?

Also, I've tried playing around with timed loops, but have run into some problems. The first issue is that I cannot wire anything to any of the inputs. When I try to wire something to them I get the error "Input Node: This node is not executable". When I look at the examples with timed loops, they have inputs wired and work correctly. If I simply disconnect and then reconnect one of those inputs, however, then I get the same error. The second issue is that even when I use a timed loop (without relying on a hardware timer), I get the same sorts of delays added. Ideally with a one milli-second period, I would have delays of 1ms for each iteration, but I still get the 15 and 16ms delays, plus combinations of them (31, 46, etc).

Sorry for the ignorance that I'm sure is coming through in my posts, but thank you all for your help.

QUOTE(tcplomp @ Jul 27 2007, 12:25 AM)

Please see my reply to Yen below. I'm having some problems with timed loops.

QUOTE(Karissap @ Jul 26 2007, 10:17 PM)

I've played around with Timed loops, but when I do, they don't work correctly. First, they still have the same delay as when I use a normal loop. Second, I can't wire anything to the inputs without getting the error "Input Node: This node is not executable". I can load examples with wires going to the nodes inputs and it works correctly, but if I diconnect one of those wires and then reconnect it, I get an error.

This may have come up before, but I couldn't find it with the search function.

When a loop executes, is it normal for it to have a delay every once in awhile? The example I've attached should show what I'm talking about.

In an extremely simple for loop (only checking the time each iteration to measure iteration length), the length of an iteration should be, at the most, a microsecond or two. What I'm running into, however, is that every 10,000 (more frequent if I throw a delay in the loop) iterations or so, one iteration will take much, much longer than it should (e.g. 15ms). Is this normal and is there anything I can do about it?

To stave off people who are going to say "who cares," let me explain why it is a problem in my main application. If anyone can point out a flaw (probably pretty easy actually ) in my architecture, then please, do it so that I can fix things. Basically, my program works by polling a variety of conditions (some conditions require hardware checks, others are purely software) and taking an action if the condition has been met. The actions that have to be taken need very precise temporal resolution, and when a 15ms delay pops up, it can throw off the timing of the action.

Additionally, I have tried putting in both a 0ms and >0ms delays, and neither remedies the solution. If the lag only occured every 10,000 iterations when using a 1ms delay, I might be ok, but since the frequency goes up as I introduce a delay, it is no go.

Thanks for the help in advance!

QUOTE(yen @ Jun 18 2007, 01:42 PM)

So, what's the difference from what we discussed http://forums.lavag.org/index.php?showtopic=6567&pid=25521&st=0&' target="_blank">here?

Why do you need a third party installer?

Just a guess, but maybe he thinks the NI installer is slow/horrible/limited/select one of the above? There are a lot of things that I wish that I could do with NI's installer, but have turned to NSIS for. Examples: creating config files at runtime, giving users multiple installation types, running code during the installation, making small installers, easier registry management, automated installer building, etc. In general, I've just found NI's installer to be not quite as good as other solutions out there. Plus, NSIS is open source, which is quite nice for those of us that care about such things.

QUOTE(chrisdavis @ May 29 2007, 09:01 PM)

Are you, by chance missing a file that your LabView EXE needs to run? Builder puts files that are needed for execution (such as DLLs and / or CINs) into a RSRC folder with the exe.

I've got big projects (300 - 500 vis) that I compile with Builder and havn't ever had a build time that long. Which leads me to my next suggestion. Have you tried performing your build after a clean restart of LabView? I'm currently experiencing an issue with Builder where I seem to have found a memory leak, but it has to do with building LLB files with VIs from vi.lib and user.lib. I haven't gotten to the bottom of it, but it doesn't seem to affect building an exe, from what I can tell.

Are you experiencing a long save time? Building an exe in LabView requires re-saving your code to a new place, so if saving your code takes a long time this would contribute to your build slowdown. Have you tried building your exe on your local hard drive? It might let you know what is missing from your network build copied to a local drive...

I don't believe I'm missing any files. In this project, the only resource type files I need are some dynamic VIs and they are all included. I'll look over my code again to make sure I don't have any such calls.

As far as the build time goes, I figured it was due to my project size (about 375 VIs), but maybe it isn't. What kind of build times do you get for projects of this size? I'm not sure how long you mean by long save times, but every once in awhile, I'll change a type-def that changes about 60 VIs in the project. Saving all those probably takes 1-2min. Is this long?

I've tried building immeadiately after starting LabView, and it doesn't give me much of a speed increase.

I will try building from the local drive. That may give me some improvement as I could see how lots of reads and writes to our network drives could be slow. Hopefully, that will help me figure out if I'm missing any files.

Michael_Aivaliotis - I haven't had the "Remove type definitions and unused polymorphic VI instances" checked. Does it matter how I do the destination? Currently, I'm building to a single .exe file.

Thanks for the help from both of you!

EDIT: It looks like it was a network drive issure. Building locally instead of from the network dropped my build time from ~1hr15min to 6min. It also appears to have fixed the invalid input parameter issue. Thanks again.

This one is throwing me a major loop. Here is what happens:

1) Build executable using OpenG Builder (Version 1.0.0-beta07, Build 311 for those keeping score of such things).

2) Run executable from network drive where build (can change folder, doesn't matter) and I have no problems.

3) Copy Executable to local drive, run, and get following message: "LabVIEW: An input parameter is invalid. The file " is not a valid LabVIEW file."

After clicking OK on the error dialog, the program proceeds to run correctly. Any ideas what is going on?

If it helps, I'm going to do another build tomorrow, so I'll see if it is just a fluke. If anyone has any suggestions for where to look or debugging to do during the build, let me know now. This is my first big project and builds are taking over an hour which is driving me crazy! I know most of you probably work on projects that require overnight builds and such, but for me long build time = frustrating. I shouldn't complain though because I'm sure the time is proportional to how bad (ie: spaghetti coded) my project is. Sorry for slipping off topic here.

Any help would be greatly appreciated. Even if you can give me a starting point to look at, it would be very helpful.

QUOTE(gleichman @ Apr 12 2007, 01:13 PM)

I still don't understand the problem. You can dynamically call VIs outside of an executable. I've attached a simple example of this. The executable and the dynamic VI share a VI that is located in the exe. Example written in LV8.2.1.

QUOTE(ars_stowers @ Apr 12 2007, 09:27 AM)

My problem was that I was trying to dynamically call VIs not included as dynamic VIs in the build. Help from everyone in this discussion and fiddling around on my own helped me figure this out.

The discussion shifted from there to the best way to design a plugin architecture to allow linking to the VIs in the executable by VIs not included as dynamic VIs at build time.

I would have looked at your files, but unfortunately, I am stuck at 8.0.1 and can't open them.

Hope that explains it better and sorry for being unclear in the beginning.

QUOTE(gleichman @ Apr 11 2007, 09:40 PM)

I still don't understand the problem.

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. During program initialization, I read the filenames in this directory and open a VI ref to each one and store the refs in a USR. Then I use Call By Ref as necessary.

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. The same VI that prefetches my VIs from the directory checks if the environment is exe and if it is it searches in the exe for files with a predifined prefix. I always use the same prefix for the dynamic VIs so the code doesn't change between Dev and exe.

- Alan

Alan,

The problem I originally had was in trying to leave my dynamic VIs out of the executable so that they could be changed or new ones created after building the main executable. The problem that I was running into was that I could not link to the subVIs I needed in the executable from the dynamic VIs. Integrating the dynamic VIs would indeed have overcome my problem, but that would still leave me without the ability to change which dynamic VIs were loaded from a config file.

As chrisdavis has pointed out, I was having problems because I did not add my dynamic VIs to the executable build as dynamic VIs, so they were linking to the RTE subVIs. This was overcome by including them.

jrdrolet's assertion was that it is quite possible to create dynamic VIs that link to subVIs within the executable without having those dynamic VIs prepared at build time. From a plugin architecture standpoint, this is an extremely powerful tool.

Thank you all for your help; this discussion has been quite helpful and has gotten me thinking about how LabView actually does stuff.

-Aaron

I forgot to mention that I am using LV 8.0.1

As far as I can tell, it is impossible to open a file within an *.exe from the open file dialog. The only way I have been able to get a RT VI into a plugin is to copy it directly from a dynamic VI built along side the executable. Can anyone confirm that this works in 8.2?

I'm currently working on comparing the binaries between plugin VIs to see if there is any good way to pull VIs out of executables to create an API.

jpdrolet-I don't think it will matter how we load the VIs from the executable, so long as the VIs we are loading are from the executable. Since I can't get your method to work, I'll have to stick with mine. Am I doing anything wrong by going to the BD, right clicking, selecting "Select a VI," navigating to the .exe's folder in the resulting dialog, then typing "MyApp.exe\VINAME.vi" in the file name box? Thanks.

So I finally got things up and running. I'm still haven't figured out all the ins and outs of what is going on, but I'll be doing some more work on this.

Here is what I think I have figured out:

-Dyanamic VIs must be built when you build the executable so that they will link correctly to the VIs in the executable. This makes a plugin architecture without some other messaging system seem impossible per chrisdavis's explanation two posts up*.

-Adding the library VIs are a part of in addition to the VIs themselves as dynamic files in a build can screw stuff up (thus my scoping error). It is better to just add the VIs themselves and their library will be handled automatically.

-The library that is added dynamically screws up its associations so that it is linked to the DE VIs rather than the RTE VIs; this must be corrected manually.

-Don't forgot to change plugin VI names in your config file if their names have been mangled or else you will get an Error 7.

*It is actually possible to create plugins after an application has been built, and here is how. (After I figured this out, I read jpdrolet's post, and if I hadn't thought of this before, it may have encouraged me to think of it. I think our techniques are accomplishing the same thing, although in slightly different ways, unless I am misunderstanding how he said to do it, in which case our techniques are the same). The problem with plugins, as far as I can tell, is that they need to access the VIs inside of an executable file.

To create a plugin that uses VIs in an executable, we need a library of sorts with the executables VIs in it. To do this, we can just create a VI with all the static VIs that should be accessible to plugin writers and add said VI as a dynamic VI to our application build.

After the build, this VI can be opened, and any of the VIs in it copied into a library (drag and drop) to allow use as an API.

If I were to work on adding any functionality to the OpenG builder, it would be to automatically create a project with libraries in it containing links to all the VIs in the executable application on building.

Again, if this was a complete repeat of jpdrolet's post, I appologize for not understanding. Thanks for everyone's help though.

QUOTE(chrisdavis @ Apr 9 2007, 07:56 PM)

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.

Simply because I have a fair amount of code to work with here, I would prefer not to change to a queueing system if possible. If I have to I will, but I think I will try to get working with what I have first. If that doesn't work though, I'll definitely come back to your solution.

Gleichman -

It does indeed work in development mode but breaks when built into an executable. Looking at my dynamic VIs, they are broken when I open them in the Built folder, but you have gotten me thinking that I was really stupid on this one.

I just copied all my dynamic VIs into my built folder and expected them to run. I knew they were broken, but figured if they were called by the program that had already loaded the VIs on which they were dependent, then the VIs they needed would already be in memory and they would not be broken as a result. I completely ignored the name mangling and directory issues that are bound to arise.

I'm rebuilding as I type, hoping that including the dynamic VIs as such in OpenG Builder rather than just copying will fix the issue. I'll let you guys know.

yen-

I get the error when I run the executable. It runs fine in development mode. I am using call by reference node rather than a method. I've attached the code to call my dynamic VIs. (sorry for the lack of comments. It's pretty simple, but if you get lost, ask and I'll explain. All my dynamic VIs ("modules") just have an error in and an error out. When the main selector is set to "run" or something like that (sorry, can't open the VI right now since I'm running a build), then you will get the code to run the modules. This VI is run at the rate I want to update my modules by a loop in the main program).

I'm not quite sure what you mean when you say "what you use the OpenG builder for." If you mean why, then the answer is that LV8.0.1 has some issues with nested libraries and I didn't want to lose the scoping capabilities of libraries just to use NIs builder. If you meant something else by your question, please rephrase it and I'll try to explain myself.

Thank you all for your help, it is greatly appreciated. Also, please don't laugh at the code as I'm a long way from being anywhere near good at LV.

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.

1390=You attempted to open a VI Server reference to an out-of-scope VI. A VI can open VI Server references only to other VIs that it could call as subVIs. After the reference is opened, that VI can return the reference to other VIs that could not normally open the reference.

After building, I did have to reopen the library the dynamic VIs are members of and update it to change the files to reference the VIs I inculded dynamically in the build rather than the VIs in my dev project.

Sorry for just blabbering, I'll probably be able to give you all a better idea of what is going on if I look at it again fresh tomorrow morning.

Using the OpenG builder, I've been attempting to build a project that calls Dynamic VIs (my plugins). Each dynamic VI needs to call some VIs used in the main program. Is there any way to make dynamically loaded VIs call back to functions that are static VIs in the main application build? I've been getting Error 1003 when I try to do this, and it isn't an issue (as far as I can tell) with vi.lib files or anything like that, but rather the VIs called by my dynamic VIs that are part of my main program.

I would think about creating extra copies of the needed VIs or name mangling them with different names to create copies, but they need to be the same VIs because I'm using them for memory (non-initialized shift registers) as well as for the actual functions they perform.

Sorry if this is totally unclear, I've tried to be as clear as I know how. If you don't understand, ask questions and maybe I'll be able to give you a better explanation that answers your question.

QUOTE(chrisdavis @ Feb 23 2007, 10:32 PM)

Ars_Stowers

Thanks for your option as well. I'm not against paying for something, especially if it does a good job! I'll have to explore http://www.vizacc.com/' target="_blank">HelpMaker as well, although I do need to be cross platform in some cases, and this product only appears to output windows compiled help files.

HelpMaker can actually build HTML-Help, Windows help files, Browers Help files, RTFs, OmniHelp files (don't know what these are), JavaHelp files, and can export parts of your project as a PDF.

Don't know if this helps, but I hope so.

I have used Vizacc's (sp?) HelpMaker some in the past. It isn't the best tool in the world, but it is free (not GNU free, just freeware) and works reasonably well.

QUOTE(Eugen Graf @ Feb 23 2007, 04:02 AM)

Hello, is it possible to convert all of my project VIs including depencies and all of files to previous version?

I have 8.0.1 and want to convert and distribute for 7.1.

Thanks, Eugen

No, you can write a VI to do it for you. Open your project, grab all the targets (regular .vi's and dependencies) and save them for a previous version in a new folder. I'll try to make something that will do it for you.

QUOTE(Jim Kring @ Feb 20 2007, 11:00 AM)

Aaron,

I've been working with others on support Project Libraries (as well as LVClass, XControl, and XNode) in OpenG Builder (ogrsc_builder package in http://jkisoft.com/vipm' target="_blank">VIPM). OpenG Builder does most of what NI's application builder does, but it's a bit more flexible. If you're interested in this (it does support LabVIEW 8.0), please let me know. We can use some more testers.

Thanks,

Sure, I would be happy to be a tester, especially if the functionality is superior to NI's app builder. I'll get the Package Manager running and download ogrsc_builder and see what I can do. Is there anything else in particular I should be doing?

Thanks,

Aaron

I just got a response from NI on this:

QUOTE

Hi Aaron,

This was reported to R&D (3X19S7QQ) and was fixed in LabVIEW 8.20. Here is a link to the current evaluation software download for LabVIEW. Thanks!

If you would like to continue using LabVIEW 8.0, you can work around this issue by using files and directories instead of nested libraries.

Please let me know if you have any further questions. Best of luck on your application, and have a great day.

Regards,

Ching P.

Applications Engineer

National Instruments

So, basically, I can't use libraries with their nice private/public setup without migrating to 8.2. Since everything run fines during development, I think I will just try (try being the operative word) to write some code to automatically create a project with folders, etc from my project with libraries. That way I can do all my work with libraries and build from folders.

If anyone has any good ideas on how to do this, please feel free to let me know.

-Aaron

QUOTE(Tomi Maila @ Feb 16 2007, 02:36 PM)

I reported similar problem to NI earlier today. The reason for my error was presumably name collision in two control names. That is two of my classes had a control with the same short name. It cause any problems in the development environment but it causes problems while building. Try to open the builder and go to the last page and press generate code button. This may help you find out if your build is about to fail.

Tomi

EDIT: I took a look at your project. That was not the problem. What LabVIEW version are you using? 8.20 or 8.0 or 8.0.1?

Tomi

I am using 8.0.1. As you mention, it doesn't appear to be a control name conflict because my example project is pretty simple.

When you say "open the builder and go to the last page...," to what builder are you referring? When I build .exes, I normally just create a build specification and then right-click->Build.

Thanks for your response,

Aaron

'm attempting to build an application that runs correctly in LabView and am getting the following error:

Error 1 occurred at Invoke Node in ABAPI Update Libraries.vi->ABAPI Dist Build LLB Image.vi->ABAPI Copy Files and Apply Settings.vi->EBEP_Invoke_Build_Engine.vi->EBUIP_Build_Invoke.vi->EBUIP_Build_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW: An input parameter is invalid.

---

NI-488: Command requires GPIB Controller to be Controller in Charge.

The issue, as far as I can tell, is in having nested libraries within my project. For some reason, the application builder has trouble with nested libraries. I'm including a project so that people can see what I mean, but I'll try to explain it too:

Project:

-Level 1 Library

---Level 1 VI

---Level 2 Library

-------Level 2 VI

-------Level 3 Library

-----------Level 3 VI

If I try to build an application from Level 1 VI or Level 3 VI, it works fine, but if I attempt to build an application from my Level 2 VI, I get the error above. The example I've included above comes is using extremely simple VI's, so I think the problem must somehow be related to the way the application builder is handling the nested libraries. Anyone have any idea what is going on here? I posted this on the NI forums as well, but figured I might get some other responses here.

Thanks in advance for your help,

Aaron