ars_stowers

QUOTE(yen @ Jul 27 2007, 07:54 AM) 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) The 15 or 16 ms thing is something of Windows if I recall correctly. Anything timing beyond this speed can't be measured that way. A timed loop should get you where you want. But a timing schedule of microseconds (and measuring it correctly)... Maybe a timed loop clocked against a real clock. Ton Please see my reply to Yen below. I'm having some problems with timed loops. QUOTE(Karissap @ Jul 26 2007, 10:17 PM) I got the same value of 0.015625 seconds for every loop execution when I ran your test. There are a whole bunch of things which can improve vi timing. Something like a Timed Loop sounds like it would be better for your application. Try searching for timed-loop in the example finder. http://forums.lavag.org/index.php?act=attach&type=post&id=6474 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) 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) 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) QUOTE(ars_stowers @ Apr 12 2007, 09:27 AM) 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. 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) 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) 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) 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) 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) 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 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 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