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/

I recently ran into the exact same thing except my offending VIs weren't password protected so this thread definitely helped.

 

Does anyone know what mechanism causes VIs to lose their linking to their lvlib files?  I only noticed that it was happening when I came across this error.

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

Would you elaborate on what was broken? I'm intrigued.

 

(One of the usual suspects for code that works in the IDE but a build that fails is to check the hierarchy for Diagram Disable structures. If the structure contains disabled but missing SubVI, App Builder will fail. This is typical on EXE builds but not installers, so I'm curious to learn more about the failure mode you fixed!)

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...

Well, you could try what I did (as painful as it is), start pruning large chunks of your Main VI until you do get to a point where the installer preview works. Note you do not actually have to build the exe to check the installer preview. This may shed some light on what is the offending code that the installer builder does not like.

 

Also, try adding:

 

 NI_Appbuilder_logging=TRUE

to your LabVIEW.ini file. This will cause a text log file to be generated for all your builds, including the installer. Try actually build the installer even if the preview is nerfed, you should get some info from the logfile. The log file appears in the same directory level as your .lvproj file.

 

Good luck, this is such a frustrating thing to debug!

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!

Actually, I AM using the built-in functionality exactly as you indicated. The fact that you did 1000+ VIs in so short a time does not bode well for me. I left it running over the weekend, I really hope it's all resolved by the time I get back to work tomorrow.

 

 

Yes, I have the same concern. A tree VI sounds good at least to help make sure things get updated when the Typedefs change, but of course that means maintaining the tree as the project is modified. What about auto-populating folders in the project tree? Do those make everything get loaded into memory?

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

You guys are scaring me away from this feature. Between anecdotal evidence like this and the mark project items to separate... process I just stopped after the 5th hour of processing, I'm feeling pretty nervous. I might still give it a try with Shaun's conversion VI posted at http://lavag.org/topic/12886-experience-with-separate-compiled-code-from-source-lv-2010/?p=77020, but now I seem to be stuck in this operation for good and I'm terrified to kill LabVIEW forcibly. With a project folder containing rougly 850+ vis, lvlibs, and ctls, the project-based conversion dialog says it's at 6736 loaded and counting. I would love to know what is going on here. I assume this is enumerating the files, removing the compiled code, and saving them?

screenshot1000138.png

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?

How much work would it be to recreate your project in 2013?  I ask because I have seen instances where a project file get corrupted or something, where it breaks and there is no explanation for it.  So I tried making a new project, then adding my code to it, making the Build Specification the same way the other was and it works.  Possibly something went wrong in the upgrade process from 2011.  I'm not saying this will fix it but if the project file it self is the problem this should help.

 

I just reread your post and it sounds like you may have tried this, you said "so I upgraded it... with no success..." what did you upgrade?

 

Also I never use the Generate Preview.  The last time I used it, it took just as long to generate a preview as it did to build the application.  Has it improved over the years?

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 LogMan,

 

I had exactly the same symptoms when upgrading a project from 2012 to 2013.

 

After a lot of cursing and stripping my code back to the bare minimum I was left with a stupidly simple main VI that would build fine, and could create an installer. Adding a single VI to this would cause the installer to not generate the preview as you noticed, and also fail to build.

 

The VI that broke the camels back was a harmless utility from one of my re-use libraries (.lvlib). This library has a whole bunch of functions in it, and some of the VIs called some other libraries (obtained via VIPM) which I had not bother to install in my 2013 dev environment. Even though I was not actually calling these VIs from my main app (i.e. the main app was perfectly legit) the library was probably being loaded into memory when you do the file preview in the installer, and as there were dependencies missing it got confused.

 

So, to fix the problem I just needed to have all my dependencies installed, and the problem went away.

 

Edit: try a mass compile on your source directory, it will very quickly show you if you have missing dependencies.

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.

> 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?

 

This isn't an "IDE slowing down" issue. This is "my code runs slower at runtime". The choice to use property nodes vs subVIs has *nothing* -- repeat *nothing* -- to do with any IDE slowdowns.

 

Unfortunately, just writing your diagrams to wire the error cluster through and using that popup menu option doesn't suffice -- the property node adds a case structure around every VI call because the syntax of the property node promises not to execute properties if the first one returns an error and it doesn't know whether or not the subVI is going to pass that error wire through unmodified or not when it compiles the caller.

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.

The slow down was probably the biggest one, though I believe that was addressed some time ago. I'm still not convinced property nodes were the cause though so much as poor architecture on my part, the project that exhibited the behavior was old and refactoring has since improved it considerably.

 

I have also seen properties "go bad", wherin they turn black and become unwirable: here and here. I've also had a few cases where using a property node broke the VI, but replacing the property node with the actual VIs worked just fine, this was posted some time ago to lava but my searching is failing me. I have also seen problems with property nodes getting confused about their types, where a VI will suddenly break a wire because of an apparent type mismatch between source and sink, however deleting the wire and rewiring works just fine.

 

The kicker about these issues is they tend to creep up in re-use libraries seemingly randomly, and to fix any of them I need to trigger recompiles in those libraries, which sends source code control into a tizzy. My work around: I no longer use property nodes in re-use libraries, and as habit I rarely use them other code either because who knows when something will get promoted to a library.

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!

B) The property node mechanism is nothing more than syntactic sugar around the subVIs. Since I eliminate the error terminals from my property accessors these days, the property node syntax isn't even an option for me -- the dataflow advantages (not forcing fake serialization of operations that don't need serialization) are obvious... the memory benefits of not having error clusters are *massive* (many many cases of data copies can be eliminated when the data accessors are unconditional). 

 

I've been trying to broadcast that far and wide ... it isn't that property nodes are slow or getting slow. It's that the LV compiler is getting lots smarter about optimizing unconditional code, which means that if you can eliminate the error cluster check around the property access LV can often eliminate data copies. This gets even more optimized in LV 2013. That means creating data accessor VIs that do not have error clusters, which rules out the property node syntax.

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?

I've heard that if you name the property folders akin to polymorphic Menu items then you'll have a property node hierarchy.  I've never actually tried it though.

 

Read:Data

Read:Status

Read:Otherstuff

Write:Data

Write:Status

 

should give you a hierarchy when choosing the property node with Read and Write sub-menus.

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!

This also raises another philosophical discussion on the decision between VIreadwrite vs propertyreadwrite. What are the best practices for this and what are the factors in deciding one over the other?

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

As for properties, I've largely stopped using them due to buggy behavior I've observed over the years and have continued to see as of LabVIEW 2012. I also see no reason to wrap all my access around error logic.

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/

Hmmm, but if that is the case then how does my "trick" work at all if it just uses the default fonts? I thought it forced the font to be something other than the default.

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

Try paste this into the .ini file for your application.

 

appFont="0" 13

dialogFont="2" 13

systemFont="1" 13

 

 I am not 100% sure what the "0" etc refers to, other than somehow it maps to a font. You can change this to something like appFont="Tahoma" 13 to force your Win7 PC to use Tahoma in the built app, rather than the default of SegoeUI. Fonts in LV are a bit of a dark pit...

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.