LogMAN

Just out of couriousity, do you use class property nodes in your project and are the VI updates related to them?

The Automotive Diagnostic Command Set (ADCS) in version 1.2.0 when used will prevent the installer to generate a preview, set properties of any application executable, and building the installer, due to a bad linked VI. The installer dialog will just show '<Error generating preview>' in the application details section. I got this issue on a new installation of LabVIEW 2013 and this behaviour has since been reproduced by an NI technician. A bug report has been filled in: CAR 429636 There is currently no way to build the installer including the application. It is not possible to add the offending VI to the library, as the library is locked & password protected. My solution was to build an installer for just the additional installers (runtimes, etc..) and to manually copy the application files to the target system. Here is a copy of the issue details from the initial thread that is also linked below. Please reffer to the thread to get more detailed information about the circumstances that causes the issue (and to see some actual pictures): ----- The Automotive Diagnostic Command Set in version 1.2.0 does update the compatibility to LV2013 and adds a new feature that causes my problem. Add an INI key to the LabVIEW.ini NI_Appbuilder_logging=TRUE The build log is created next to the *.lvproj file and directly shows the problem. Here is the important line of the build log: The file at 'C:Program Files (x86)National InstrumentsLabVIEW 2013vi.libAutomotive Diagnostic Command SetDiagnostic Transport.llbOpen Diagnostic on LIN.vi' was expected to have the qualified name 'NI_Automotive Diagnostic Command Set.lvlib:Open Diagnostic on LIN.vi', but has the qualified name 'Open Diagnostic on LIN.vi'. ----- Notice: I was able to start the build, because the installer has already been configured in LabVIEW 2011 SP1 & ADCS 1.1.0. Here is the related topic: http://lavag.org/topic/17137-error-generating-preview-in-installer-properties/

Unless you remove a VI from its library, it will stick to it, even if you try to load it without the library. However if you load a VI that is part of a library, you can disconnect it (File -> Disconnect From Library). I think there is also a possibility, to break the library, if you replace a VI of the library with one that is not linked to it (I have not tested this though). This is why I avoid to edit VIs while the library is not loaded.

I think we stick to much to the BD, where the FP also needs much more love As I checked for new ideas in the Idea Exchange, I found an interesting one: Check this link: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Match-widths-of-Label-and-Caption-input-fields/idi-p/2579739 I like this idea so much that I couln't help but giving it kudos

Hi mwebster, I've downloaded your VI and confirmed the behaviour on my Win7 system on LV2011. The stepping effect as in your diagrams however never occured to me. I think the term 'drift' is misleading you here. The 'date/time in seconds' value will always drift slightly to the 'tick count', as the tick count is less accurate (significant digits missing & tick counter is rounded!). You can see that in your graph which has a range from -0,0006ms to +0,0008ms on my attempt. Thats a range of 14µs! For example: date/time: 15,3388772010803223 tick count: 15,3390000000000004 difference: -0,0001227989196781 That's what causes the effect of 'drifting' in your graph, as the timer needs many iterations to line up again in terms of microseconds. Eventually both values will round up again and the cycle starts from the beginning. There is always a chance, that one of the two functions is executed slightly after the other one, since your system is not a real time system and the functions are of different compexity inside. Also non-realtime systems have a common habbit to suspend execution of some threads to allow execution of other ones. Maybe thats causing the stepping effect in your graph eventually. Depending on the number of CPU cores and the way Microsoft handles threads (this also changed between XP / Vista / Win7 / Win8 / ... ), your experience might change too. I'm not sure though, why your XP system had a difference of 800ms... I remember something about one of them may be handled by the bios instead of the CPU... A quick search turned this out: http://digital.ni.com/public.nsf/allkb/4E12F6841016929D86257126007A9D94 I assume that the system made an synchronization to it's time over the internet at some point over the weekend. If the computer is not connected to the internet, I've no clue. As for the differences you are asking for: The date/time is more accurate and absolute, where the tick count is less accurate and relative to the start of your system (ms since start). If you need an accurate way to display execution times or delays, the tick count is everything you need. The system can only be handled down to ms anyways. Use date/time whenever you need an exact timestamp.

Hello again! I'm back to report the problem / solution. The <Error generating preview> in the installer dialog is caused by a bad VI from one of NIs Toolkits! The Automotive Diagnostic Command Set in version 1.2.0 does update the compatibility to LV2013 and adds a new feature that causes my problem. Thanks to neil who made the suggestion to add an INI key to the LabVIEW.ini NI_Appbuilder_logging=TRUE The build log is created next to the *.lvproj file and directly shows the problem. Where the IDE dialog just showed me an error: -1! !!! error -1 !!! Here is the important line: The file at 'C:Program Files (x86)National InstrumentsLabVIEW 2013vi.libAutomotive Diagnostic Command SetDiagnostic Transport.llbOpen Diagnostic on LIN.vi' was expected to have the qualified name 'NI_Automotive Diagnostic Command Set.lvlib:Open Diagnostic on LIN.vi', but has the qualified name 'Open Diagnostic on LIN.vi'. This freaking VI forced me to clean up my project! ( I removed a whole bunch of orphan VIs, disabled structures, conditional structures, etc.. so it's good for the project ) As I'm unable to remove the offending VI from the library (password protected), I have to rely on NI to update the toolkit ASAP. I hope this prevents anybody else to run into the same problem. Thanks for the support and the helpfull suggestions, my project is now OCD conform

Well the project is still broken. I know the part/VI in my project that causes the issue but I'm not sure why, so I'm currently in contact with NI to find a fix. I will surely post the solution once I know what is going on...

Thanks for the advice neil! Where can I find the log file btw? (my build does abort instantaneously, so I'm just curious) I found the VI in which the problem occurs (using your method). One of my VIs is very, very badly broken, but still executable I can see the preview now, if I completely remove that specific VI from the dependency! Maybe I'm halucinating here, but I'll now contact NI for further investigation and may update once I got answers. Thanks for the support!

My bad, I missed the part where you said 'project-based conversation dialog'. Let me recollect something: The dialog that appears will in fact list all the LabVIEW items in your project: The enumeration process might take a while depending on the number of files in your project but there has never been a loading screen for me. Be aware that all files within the project (VIs, libraries, llbs, auto-populated VIs/libraries/llbs, etc...) will be enumerated (except for files under 'dependencies'). Have you ever reached that dialog at all? It's not clear for me. If you never reached that dialog, it should be rather safe to kill LabVIEW (it's enumerating files) -> I assume your dialog does only say 'Loading:' and not 'Compiling:' as in your screenshot. It seems like LabVIEW is trying to load everything (the entire LabVIEW directory?) into memory (..LabVIEW 2012resourceFramework* is part of the LabVIEW core!). So you could abort that operation and try on an empty project file. If you have the same behaviour again, it would be a good time to contact NI. If you want/have to abort the process, you should check the object cache first. If the size changes, than LabVIEW does remove compiled code. Killing the process then might result in broken VIs. It is located under: C:Users<your user name>DocumentsLabVIEW DataVIObjCache<your labview version>objFileDB.vidb So for me that would be: C:UsersLogMANDocumentsLabVIEW DataVIObjCache12.0.0r4objFileDB.vidb

There are quite a few items loaded and I'm not sure how the sources will react if you kill LabVIEW (some of them might have their compiled code removed while others dont). It wouldn't be a big issue if you had your code in SVN or something where you could just revert the working copy... (I recommand to create a backup before doing such stuff anyways) However if you have a single project file and want to remove compiled code from VIs within the project you can do that from the project properties dialog (Seperate compiled code from new project items & Mark existing items) I recommand to use that function as it is shipped with LabVIEW (at least since 2011 afaik) I used it on my recent project with 1000+ VIs and it took just a couple of minutes. Just read the thread you linked: Seems that LabVIEW 2010 had some issues with the removing of compiled code. As you are using LabVIEW 2012 that should be no issue, so why using that VI instead of the build-in function anyways?

Hi hooovahh, Well I use a DLL file in my project that has been created in LabVIEW 2011. This should be no issue, but would have made my application to load both runtimes (2011 for DLL & 2013 for EXE) so I managed to recompile the DLL in 2013. This is what I mean by upgrading "it". As for the preview: If you create an installer, you want to tell it where to store the application files. For that the installer dialog will automatically generate the preview in order to provide the files list... I also want to provide a menu shortcut to the executable which I cannot create if there is no preview that includes the actual executable (it is basically as if it doesn't exist at all!). The preview generator (in the application specification) is very quick for large applications. Hi neil, It seems I'm not the only one who had problems lately. Lucky me, as I now have an experienced bug tracker I did as you suggested: I mass compiled all the project folder and cleaned up the orphan & bad VIs unless there was no error left, but still no improvement. Here is what I did: 1. Mass compile project folder (returned some warnings about Bad-VIs & Missing VIs) -> Due to orphan VIs in my folder structure (removed!) 2. Mass compile project folder (still returned a bad VI) -> Removed it from my project library 3. Mass compile project folder (no error) -> Still can't see my preview in the installer dialog 4. Mass compile shared company libraries (no error) -> Still preview error 5. Clear compiled object cache (I use SVN, FYI) 6. Mass compile project folder (no error) -> Still preview error 7. Create a new project; add all necessary files; create an application specification; create the installer specification -> Does not work (preview error) 8. Mass compile vi.lib (did only take about an hour or so & returned a bunch of errors -> masscompile.txt) I did stuff like: - Restart LabVIEW - Reload Project - Recreate Project every now and then, but in the end there was still this <Error generating preview> text. Well I'm ready for my weekend but if there are any more suggestions I would be happy to try them out! Nice weekend to everybody!

Hello everyone, I recently installed LabVIEW 2013 on my development machine to get rid of some issues in my current project. However the project is originally build in LabVIEW 2011, so I had to save all VIs for the new version (no issues ) I'm still able to build the application executable with no problems too! Now I want to provide an installer for the customer to upgrade the Runtime engine and some additional stuff that has been changed for LabVIEW 2013. And there lies my problem, as I'm currently unable to build an installer. The configuration dialog shows 'error generating preview' for any executable in the project: Naturally I tried to generate the preview in the executable, but there seems to be no issue: Creating new specifications did not solve the problem and even creating a whole new project file and including the startup VI to it + creating new specifications did not solve the problem... I made a new project with a single VI for testing if the application builder is not working in general, but thats not the case, as I was able to create an application + installer with no issues. So I'm quite sure there is something wrong in my project that causes this behaviour, but I've currently no clue what that could possibly be. I read somewhere (in the NI forums I guess) that there could be issues if you have files in your project that are build in an older version (as one of the dll files), so I upgraded it... with no success... Now does anybody had an issue like that in the past / currently and is there anything I could do or check to regain the ability to provide a proper installer? What could possibly cause the installer dialog to fail generate a preview where the application dialog is successfull? Any ideas are welcome

Well... Removing the topic does help... Thanks misterious someone works for me again.

As much as I don't want to bring this topic back, the feed is broken again! This time check out that post here and read the title... Since the post is quite new, the problem is currently in line 232 of the RSS. My XML check (notepad++) gives me a parsing error: Can anybody confirm this?

Also try this link: ftp://ftp.ni.com/support/softlib/labview/labview_development_system/ It also contains older versions.

I see, two different matters. An interesting point for further investigation... Thanks for clarification! I will have to run some tests to fully understand the actual impact that is caused by error clusters (speaking at runtime now!). I'll take that 'IDE Slowdown' matter into a different thread as it has nothing more to do with the topic at hand.

Turns out LabVIEW is connected to this forum. It has given me the right answer directly after my innocent question... The issues you described are exactly what happened to me today while changing a whole class tree, RIP project! Interesting point... I'll take that in mind for my future development. I always considered property nodes as a huge advantage over accessor VIs when it comes to large amount of elements (you know its small and tidy...). It seems there are some major drawbacks! The whole 'Error Cluster Everywhere!' story is also something I'm very concerned / confused about. In many cases I just have an error terminal going in-out with no particular meaning to my VI, just to maintain facade. Is it a way to get rid of the 'IDE slowing down' issue if I remove all the case structures from the property Read/Write VIs?

Just tried, but unfortunately LabVIEW removes the colon Tried 10 times However I'm stuck with LabVIEW 2011, so maybe its a new feature? EDIT: Found a thread that describes what you mean: http://lavag.org/topic/13581-property-node-names/ Mr. Mike described how to do that >> Thanks man! The long name is what shows in the property selection menu (when you click on an item in the property node). This name is also used to structure that menu. If there is a colon in the long name, you'll get a submenu ("pull-right"). e.g.: If you had two properties with long names "Color:Foreground" and "Color:Background," they would both be in a "Color" menu listed as "Foreground" and "Background." The Long Name can be set in the editor by going to the class properties dialog (i.e. right clicking on the class and selecting "Properites"), selecting "Item Settings" and choosing the property you want to edit. The same for the Short Name. Set the Long Name with a colon and you'll get a nice property selection list! @shoneill: You're the best, thanks!

There are of course numerous approaches and personal preferences to that matter, so this is how I generally handle it: First of all, each element of my class private data is accessible via property nodes, however there are some exceptions for arrays >> you can't have an index terminal on a property node Some of the properties are public, some are private, some are read or write only. However each property has a read and a write accessor for use by the class itself (no bundle/unbundle) All data that is absolutely required for the general function of my class is presented by member VIs. However you could use the public read/write properties to directly access data or get additional information if necessary and possible (remember some of the properties are private ). Also the member VIs do not necessarely just return the private data, but they return data in a way the developer can handle it (Trying to avoid complex clusters). If NI would allow us to create property node hierarchies and invoke nodes all the considerations would not be necessary... Just thinking about it makes me so You mind sharing your experience / knowledge? My applications are heavily based on property nodes and there is just one nasty issue I found up till now >> Property nodes are slowing down the IDE if they contain complex data (class, clusters).

This tool is nice and will become very useful once the bug is fixed. I tried your code and instantly experienced the bug. However there is a workaround: Running the main VI directly from disk will prevent the crash. Sadly it will crash the moment you close the UI. I found one issue so far (seem to solve the problem for me): You store references to each library into a variant attribute that is collected in the Variant 'Reference Lookup List'. >> Remove all dependencies to that list and fetch the references again in your 'Callable Methods.vi'. In my case the Browser did not crash anymore... However that does not fix the issue with calling the Browser from the Tools menu... I don't know for sure, but it seems that the instance from the Tools menu compared to starting a VI directly from disk is somehow different...? Does anybody know more about that? EDIT: Tested in LabVIEW 2013 (32-bit) on Win7 x64

There you are my soul... How dare you talk about my programming habits in the public? Damn most time my left hand moves on its own and all the icons and lines align by themselves just to ease my eyes It does not even take me longer to get my stuff finished. However we LabVIEW programmer are not called 'pixel pusher' for nothing

I absolutely support the considerations of the previous post, so please don't oversize your main VI if it is not absolutely necessary (It never is...). There must be a good reason for programming the SubVIs in the first place. Anyways here is a link to a RCF plugin that should do the trick: Expand SubVI I never used it and I have no advice for installing the RCF.

You might want to read that post to know how to draw attention: http://lavag.org/topic/15044-using-the-report-to-moderator-link/

Well you could. If you write "Arial" instead of "0" than you'll get Arial font instead of the default one. Right now we assume that the default font on an XP machine is different from the one on the Win7 machine. Up till now I couldn't reproduce the behavior on my virtual machine, but I'll try on the real system anyways. I have no access to the target system for some weeks, so feel free to suggest some more ideas

I'll do that for sure. Thanks for the input. The "0"... might be related to an enumeration according to: That would make: 0 = Application Font 1 = System Font 2 = Dialog Font I guess it'll cause the system to use the default LV font that is related to the specific item. I'll try it and tell you guys if it works.