Omar Mussa

QUOTE (Aristos Queue @ May 2 2008, 12:35 PM) I think this problem would be fixed if LabVIEW would allow you to save a VI while it was not 'Idle'.

I just figured out that 8.5.1 does not really exist -- it is only in your minds. Check the LabVIEW.exe version number yourself.

QUOTE (gmart @ Apr 8 2008, 08:28 AM) When I drag my executable over to the Installer destinations tab, I see a preview of the installer output. The folders/names of the files in this preview do not match my built output. My built output looks like this: Application.exe Application\Support\Alarm Application\Support\Measurement etc. (Support is my application 'data' folder, but I've renamed it). My Installer wants to create the following: Application.exe Application\Alarm Application\Measurement ... Application\Support\Alarm Application\Support\Measurement Which does not look correct as my build output does not create any folders at those bold locations. When I try to build, I get the following error: "The following file(s) are not found on the system: ... (filelist of a lot of controls -- interestingly no VIs show up in the list) Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference: CDK_CreateNewWizard_Invoke.vi.ProxyCaller >> CDK_CreateNewWizard_Invoke.vi >> CDK_InstallerConfiguration_Editor.vi >> CDK_Build_Invoke.vi >> CDK_Engine_Main.vi >> CDK_Engine_PreBuild.vi >> CDK_Engine_FileExists.vi " I thought at first the problem could be due to LabVIEW stripping out unused code so I moved the root virtual folder of my classes into the 'Always Included' area of the EXE build specification and I also unchecked the 'disconnect type defs' & 'remove unused project members' options. I'm not sure if LabVIEW is building the missing files into my EXE or what, but the EXE is working (I can run it at the built location) so I have no idea why the installer builder is generating that error. It seems like there might be another root cause to this problem. LabVIEW does not appear to be differntiating naming rules for dynamic dispatch between controls and VIs. If I have two classes that inherit from each other and they both have a control named 'Properties.ctl' there should not be any dynamic dispatch related naming issues because 1) both are members of a library 2) there is no such thing as over-riding a control (only VIs can be over-ridden). Let me know if there is anything else I can do -- I really don't want to upgrade to 8.5.1 yet because I have other projects on 8.5 that can't be upgraded yet.

QUOTE (gmart @ Apr 7 2008, 12:49 PM) Ok, sorry for turning this thread into an NI support page -- not my original intention. I just want to vouch for the fact that this has worked and helped my build a working EXE... The one problem I have now is that when I try to build an Installer now, the installer seems to look for the files without regard for destination or name changes. I'm pretty close to waving the white flag and just leaving everything with default settings even though I finally have my EXE build output looking the way I want.

QUOTE (gmart @ Apr 7 2008, 11:00 AM) I tried setting the destinations but then I get the following error: "Error 1357 occurred at AB_Source_VI.lvclass:Copy_SourceItem.vi -> AB_Build.lvclass:Copy_Files.vi -> AB_Application.lvclass:Copy_Files.vi -> AB_Build.lvclass:Build.vi -> AB_EXE.lvclass:Build.vi -> AB_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.vi.ProxyCaller Possible reason(s): LabVIEW: A LabVIEW file from that path already exists in memory, or exists within a project library already in memory." I think that this is because "the auto rename does not run on the files" :headbang: -- without auto renaming I'm stuck. What I need is autorenaming WITHIN the speficied destination. I guess this is a damned if you do, damned if you don't bug.

QUOTE (Aristos Queue @ Apr 7 2008, 07:53 AM) Ouch I forgot about that :headbang: ... and it explains why I was getting the mysterious and always ellusive error 1502 during the build (Can't save a bad VI without its diagram) -- this error message is the terrible because it does not specify the bad VI path/name or anything. Maybe you can help me figure out the solution to my original problem. I want to distribute the application without having LabVIEW auto move/rename VIs/ctrls during the build (or at least I want to move all of the output from the auto movement to the 'data' directory instead of the target app root directory. How do I do this?

I preface this topic by the following statement: I think that the fact that LVOOP Classes are not automatically namespaced in built applications is a serious problem that should have been resolved by 8.5. When I open a class in the development environment, it is in the name space "Class:VI Name" so it seems unreasonable to me that this is not handled automatically in the LV Runtime Engine (or LV Builder, choose your poison -- I personally think it should be a LV Runtime Engine fix because otherwise you couldn't dynamically load classes into built applications -- & I'm not even sure if you can do that now). If this problem were solved, there would be no need for the workarounds I mention below. I recently upgraded a project from 8.2.1 to 8.5 (why, because my customer wants to be on the bleeding edge -- really no other reason than that). In doing this, for whatever reason, I was no longer able to build an installer from my application. After looking at the warnings, I decided it was most likely due to namespace issues in my built EXE. I grew weary and tired of the warnings from App Builder about LabVIEW finding namespace issues and decided it was time to use the 'Destinations' and 'Source File Settings' pages and take control of my namespace once and for all. Then an issue hit me. If you select a class on the 'Source File Settings' page, you cannot set the contents of the class to have a 'filename prefix' (i.e. namespace). However, if you select a Virtual Folder, you can set a 'filename prefix' (it propagates to all items in the Virtual Folder). So the following workaround found its way into my life. If you create a Virtual Folder (I called mine 'Class Members') and then shove all of your methods, controls, Virtual Folders, etc. into the folder, you can then use this virtual folder for setting your class contents into a namespaced destination. This resolved all of my build conflicts (others arose but were not namespace related so far as I can tell). I plan on using this workaround on any new classes I make until LabVIEW properly sets the namespace automatically in the build process.

QUOTE (crelf @ Mar 31 2008, 05:31 AM) I think that'd be called Australian rules

QUOTE (crelf @ Mar 28 2008, 12:37 PM) I agree completely.

Now this is an interesting NI Week competition in the making ... Bum Bot Wars!

QUOTE (xcgeek @ Mar 27 2008, 10:48 AM) Which is not to say that it can't be done in LabVIEW -- LabVIEW is probably a great fit for this application but you can't just jump into a new language (especially one that requires a paradigm shift in thinking like LabVIEW does) and expect good results. All software projects require good architecture, planning and execution/implementation (regardless of language).

QUOTE (shoneill @ Mar 25 2008, 01:08 AM) Yes, and I agree it is weak. I did testing and realized that my black and white images are coming out as RGB now (so they are 3x the size). So, I'm now using 'IMAQ Write String.VI' and queueing the file string of the image so that I can dequeue and write it to disk in another loop (basically I'm passing the value by value instead of by reference). It works fine this way so I guess my original workaround is only good if you're capturing RGB images to begin with.

QUOTE (jdunham @ Mar 24 2008, 10:55 AM) I'm not using an NI Camera nor am I using the NI Grab or acquisition functions so IMAQ Copy Acquired Buffer.vi is useless in my case (I'm using a 3rd party camera/driver). QUOTE (bmoyer @ Mar 24 2008, 09:08 AM) I don't think this works for non-color images. From the help: IMAQ Merge Overlay Makes a nondestructive overlay part of the image content. This process creates a destructive overlay. The VI then removes the nondestructive overlay. The resulting image is an RGB image. Any workarounds you can think of? Bruce I may have to do a bit more testing. I was able to do this without errors but what I don't know is whether or not the images are good because I left the lens cap on :headbang: I will test this again tonight. The main thing I do know is that I wasn't getting any LabVIEW errors, my output files are readable and the IMAQ refs were Grayscale (U8).

I recently 'discovered' a way to copy an IMAQ image without using 'IMAQ Copy'. The problem -- using only 'IMAQ VIs' (ie, not using anything that comes with Vision Builder) there is no 'IMAQ Copy' available so if you want to acquire images in a loop and have another loop to say, store them to disk, you are sort of stuck (unless you can save the image in the same loop because your camera will overwrite the image reference on the next Grab). The workaround -- using 'IMAQ Merge Overlay' you can essentially copy an image that has no overlays onto a new blank image. In my snippet below, you can see exactly what I mean. Once I've used the new reference to save the image to disk, I destroy the reference.

QUOTE(billings11 @ Mar 5 2008, 02:55 PM) I have the same issue AQ -- would adding 'Conditional Disable' structures work? -- I know that you can set a conditional disable based on a custom project conditional disable symbols (Project-->Properties) but I haven't tried to check whether this will affect the build dependencies.

QUOTE(mross @ Feb 5 2008, 03:27 AM) This method has a terrible flaw. If any VIs are being called dynamically, you will not find them using this method. To check if any VIs are being loaded dynamically look for any instances in your application of the 'Open VI Reference' primative (member of the 'Application Control' pallette).

QUOTE(Aristos Queue @ Jan 30 2008, 11:03 PM) a) I'm using 8.5.b) I NEVER open the VI Hierarchy anymore -- it basically forces me to kill LabVIEW when I do. I'm not sure how many total VIs are in my project. I found a quick way to find the number of VIs that are directly shown in my project (Project --> File Information --> Export Files ...) which I opened in Excel and found 560 files. I know there are more that are being called by these VIs but are located in VI.lib or user.lib.I tend to keep a VI Tree of my project open while developing code -- it seems like it keeps the everything from having issues later when I try to save and apply type def changes, etc. I tried restarting LV and not opening the VI Tree and I had the same problem (it seems to affect my main application class the most).QUOTE(jdunham @ Jan 30 2008, 10:14 AM) As far as it being very slow, thanks for the heads up, and good luck getting some resolution. Is there anything in your objects like a DAQ or VISA refnum which might have a lot of overhead attached to the control? I have replaced my IMAQ refnum with a String and I'm not seeing any difference (but I do feel like that was still a good suggestion/idea).

QUOTE(jdunham @ Jan 30 2008, 10:14 AM) I'm using a ByRef framework (Endevo's but I have seen this problem on the OpenG Classes as well) on top of my LVOOP objects that makes the object data literally a cluster. All of my data access is via 'Get' and 'Set' attributes which basically unbundles/bundles the cluster data into the LVOOP object. The way you will get around your problem of not seeing the data is by creating accessor VIs -- then you can easily probe your object data and life is good again (in my opinion). QUOTE(jdunham @ Jan 30 2008, 10:14 AM) It ended up taking me so much longer to debug the application than it does when I use regular old typdef clusters. If you are not using the benefits of inheritance, then there is even less reason to use them. I'm using inheritance for some of the classes in my system. But I also highly value being able to encapsulate my code. So far, the LVOOP objects are great for that purpose. The biggest problem I see with them from a high level perspective is not being able to create tests for my private VIs outside of my class. Debugging is not an issue for me. QUOTE(jdunham @ Jan 30 2008, 10:14 AM) As far as it being very slow, thanks for the heads up, and good luck getting some resolution. Is there anything in your objects like a DAQ or VISA refnum which might have a lot of overhead attached to the control? That reminded me that I recently added some IMAQ image refs to my data, I will see if replacing them helps. I think the biggest problem is having the classes referencing other classes in their object properties. The recursive checking for errors seems to be the biggest issue (in classes in my project that do not reference other classes in their class data, I don't see the performance issue at the moment). Luckily, I have one 'application' class that has references to the other major classes in my application and it seems to be the only one that is really painful (so at least I'm learning to see where I can 'avoid' the problem).QUOTE(crelf @ Jan 30 2008, 10:08 AM) It might not be a "bug", but it's certainly an "issue" - I'd still submit it anyway: that way NI can know that it's an issue that stopping you from doing your work and, worse still, stopping you from using their product. Ya, ok will probably do so -- but the pain is knowing that to get any true progress I'll have to recreate the problem in a simpler way and that is enough to make a procrastinator wait until the project is over

I'm sure this has been raised before but I hit the wall of frustration today. I have a project with about a dozen classes and minimal inheritance is being used. However, most of my classes have references to other classes in their class data. The problem I face is that every time I make a change to my block diagram, I have to wait about 60 seconds for LabVIEW due to the overhead/recursion/etc. of LabVIEW checking ALL of my classes to see if anything is broken and if so if other classes are broken as a result. Now, this can really suck, especially if all I do is an operation such as add an element to my 'Unbundle by Name' (wait 60 sec) wire the element to another node (wait 60 sec) etc. It basically can result in LabVIEW becoming 'unusable' by me or really anyone else. Its ridiculous and while it is functionally working (i.e. it doesn't break my diagrams in unexpected ways) it is not functional in any other practical way. I guess this is a rant because I can't submit this as a 'bug' to NI (it isn't a bug) and yet this is pretty close to stopping me in my tracks.

Or you can just use ActiveX and get the table data yourself. The best place I've found for help with all things microsoft is msdn.microsoft.com.

I'm working on the same project, and have seen this issue too. I don't exactly remember the circumstances but in my case I was able to figure out that there was a class that was having troubles, if I opened the class first and the VI that was showing up in a LabVIEW file dialog prior to the compiler error dialog you posted (which unfortunately I cannot reproduce right now), I was then able to open the VI that previously had this compiler issue. Anyways, it was not ideal.

QUOTE(sachsm @ Oct 24 2007, 05:35 PM) On a related gotcha, in LV 8.2 (not sure if fixed in 8.5), if you select that option, there is NO UNDO. Basically, the only way to uncheck the 'run after completion' checkbox is to delete the installer spec (truly a pain).

Your database performance will be a function of several factors, including: 1) Database structure -- indices will slow down writes but speed up reads, for highest speed you will want to have as minimal a set of keys as possible (primary key is important, foreign keys will add overhead so should be avoided), the table structure itself can be optimized based on your needs. Also, disk space allocation can be setup to auto grow as table grows, need to ensure that you have settings that don't cause the table to be constantly 'growing' (you want to grow in chunks, not continuously, if you grow continuously you are inefficient) 2) Writes -- there are different ways of writing to the database that are faster and slower (typically, gains realized in writing data will be lost when reading data in my experience so you should consider that writing data happens 1x, while reading happens over and over so focusing on the write is usually a bad design decision) 3) DB Toolkit Usage -- the LV Toolkit has some steps you can take for optimization such as executing with 'forward only' cursors, etc. You need to get into the nitty gritty/low level VIs and understand what settings are applicable for your application. 4) Application structure -- keep in mind that one way to maintain your acquisition speed is to acquire data in one loop and write data to the db in asynchronously in another loop (or program, or cpu, etc). So application structure will matter when it comes to the 'performance' of your application (including writing data and maintaining a high DAQ speed).

Congratulations! :beer:

QUOTE(jpdrolet @ Aug 27 2007, 03:25 PM) Don't use this method, use the one Jim posted. A developer can strip a BD from a VI that is still in the development environment! (Either I didn't reply fast enough or Jim and I replied at same time...!) I reiterate what Jim says.