LogMAN

Glad that helped.

 

I seem to recall somebody on the darkside (Christina?) telling me (or somebody else, memory no good these days) that the number is like an index into some global font list or something.

So I'm on the dark side now?

http://lavag.org/topic/16925-controls-change-positions-on-runtime-system/?p=103828

neil, I am your father...

maybe...

Thanks JeffP for the update. I've installed the patch, but unfortunately, this does not solve the issue. I still get <Error generating preview> in the installer dialog.

I use the RSS, but I also go to the site and look at View New Content too.  So while I notice RSS broke this morning, I just went to the site and clicked on all the new posts I was interested in.

 

How can you rely on RSS alone anyway?  Doesn't it only show new threads and not new posts?

No, the RSS shows topics which recently received a new post with the most recent one on the top (there has been a Feed from 2011 some days ago -> 'Editing an Existing Class'). New topics fall automatically into this category though. Anyways I have the choice to follow a topic and not see all 10+ posts of one I don't really care about...

Don't get me wrong, I do use the 'View New Content' Area, when I'm forced to, but I guess I'm just lazy   ( and I'm frustrated when stuff does not work as intended    ) ( Also, it seems I'm not too lazy to complain about it   )

It seems that all the SPAM is finally breaking down the Database. Thus the RSS is now down for good:

BTW, Am I the only one whose depending on this function?

For those who are unfamiliar, this is not something that can be resolved before hand in all cases. A 32-bit LabVIEW application may indeed be run on a 64-bit operating system, it's not until run-time that this can be resolved. When using SZ or USZ nodes, LabVIEW treats them all as 64-bit numbers on the block diagram, and coerces them down to 32-bits if necessary depending on the host operating system when the node executes.

To clarify something here: A 32-Bit application does never have to deal with a 64-Bit pointer! Therefore you only have to deal with different pointer sizes on 32-Bit vs. 64-Bit applications which of course depends on your LabVIEW IDE at compile time. There is also no way you could call a 64-Bit DLL from a 32-Bit application.

Now to the question at hand: I think a pointer sized integer could help in many situations if you want to support both bitness types. However this is only true if you can be sure, that the same library call could in fact link to two separate libraries. For example, the kernel32.dll could be called from either a 32Bit or 64Bit application from the same location (C:WindowsSystem32kernel32.dll), but the 32Bit application is redirected to a different file at runtime. This is very well described here: http://msdn.microsoft.com/en-us/library/aa384187%28v=vs.85%29.aspx

If you want to write an application that supports both types (depending on your LabVIEW IDE), I suggest you handle all data in 64Bit integers and depending on your bitness, typecast to the lower bitness on 32Bit calls (This is what LabVIEW does with the SZ or USZ afaik). The bitness can be determained by a conditional disable structure, as described here: http://digital.ni.com/public.nsf/allkb/F9770A64A5D5EF4A862576E8005985A8

In my opinion, a pointer-sized integer would be nice to have as a choice for integer representation. However it must be made very clear, that the number of bits does change depending on the IDE bitness, as using it the wrong way could cause serious problems in some situations. Anyways I have some situations in mind where I would like to have such a type

I have no solution for you, but this is how my machine works:

1) Creating a file from LabVIEW in C: will return an error

Error 8 occured at Open/Create/Replace File in Untitled 1Possible reason(s):LabVIEW: File permission error. You do not have the correct permissions for the file.C:test.config

2) Create a subfolder (e.g.: 'C:New Folder') now writing the file to this location works perfectly fine.

I did not have to change any properties for the folder at all. The UAC is set to 'standard'. And in the folder permissions, authenticated user are allowed to do everything except 'full access' and 'special rights' <-- these might be spelled differently, as I translate from my German system.

It dosn't seem to matter if the file is *.config or *.txt.

As it is a Windows OS, there are some possibilities that could cause such issues. So here is a list of things you could try:

1) Install all the latest service-packs & updates (Win7 SP1 must be installed, since there have been many issues before)

2) Check again if your account is really of 'Administrator' type (An account with 'User' rights can read the files, but not write)

3) Try running LabVIEW 'As Administrator' explicitly. (This must work)

BTW, I always assume you are running an development system. Is that right, or are we talking about a Runtime system?

For a Runtime system you need to unlock the executable at least.

Please use the report post to moderator link. otherwise we have no idea there's an issue. Believe it or not, moderators don't read every post.

Well I use this function if there is a single spam around (I actually did that on the very first spam-post), but there have been 100+ posts since, which are hard to keep up to. However you should have received 8 more reports just now . I don't think it's necessary to read all posts, since the titles in the RSS are quite obvious. However if reporting is how it has to be done, you can be sure I'll send reports.

Originally, the file was being written to the root drive, C. I thought this might be causing the problem so I moved it to a different folder on the C drive. The problems persisted.

 

The original file extension was ".config." I renamed it to ".txt" just to see what would happen and the file permission errors disappeared. It seems like there's some setting that prevents access to certain file extensions or unknown file extensions?

*.config files are Application Configuration Files which are treated as system files afaik. UAC will of course prevent you from editing system files, unless you have full read/write permission. It seems that the directory you use to store the files does not grant full read/write permission. Did you add your user name in the permission tab for that folder?

I'm running a Windows 7 Ultimate virtual machine on a Macbook Retina. There's only one account setup on the virtual machine and it's the admin account. I tried setting the file permissions such that "Everyone" has "Full Control" on all files/folders. This took a while and the permissions couldn't be set on certain files. It also didn't resolve the problem, which was constant IO errors from LabVIEW complaining about lack of file permissions.

 

I tried cranking the User Access Control / UAC setting down one level at a time and the problems finally went away when I shut it off completely. Is there any other way to fix this problem besides shutting it off totally?

 

Thanks.

I think hooovahh pointed out the correct way to deal with a situation on a Runtime system (Yes, the documentation of the feature could be better & you unlock for certain directories only!). However if you don't need the UAC (like for a standalone system nobody really cares about), just disable it entirely. I figure the latter one to be more like a 'workaround' solution, but you gain access to any file location without setting up all required directories manually. If your application has no predictable default behavior, it could be a pain to setup an installer for a system with UAC enabled.

Count me in. The spam is to much to compensate in the last weeks and so many topics are lost/unseen in the process. It seems to be a single bot/person that will go on for some time. The moderators are doing their job, but that will not be enough if this goes on.

I think a post limit is a good start, however it should be a limit to new members (like for the first 1-2 Weeks after creating an account?), thus limiting the amount of damage and providing the community with the ability to recover very quickly. However the spammer will eventually figgure out a way to generate new accounts automatically, which will cause a new flood of spam with or without the limit.

An additional way to deal with spam is to allow regular members to mark somebody as 'spammer' in order to limit his movements or even temporarily remove the latest (like today) posts of a suspect until a LavaG Moderator looked into the matter personally. This feature should only be entrusted to members who are in club 500 or higher (and the premium members I guess). As the moderators cannot keep up with the spam (sorry, but I guess the community is much faster here), this might be a way to get rid of such situations in the future very quickly by the community itself. And the moderators still have full control over the situations and what happens to such accounts.

Just an idea though and I have no clue how complicate such a function would be to implement. However the community here is great and could be entrusted with this in my opinion.

A LabVIEW captcha (aka CLAD questions) is not very helpful and could easily be avoided, once all the possible solutions are known. If it has to be a captcha, use a regular captcha (picture with random numbers/characters). Anyways LavaG would loose much of its flavor this way. I like how we are trusted without such a security measure.

Hello all,

 

I just wanted to let you know that we are aware of the issue described in the first post (the problem with builder an installer with certain VIs). In this case it is a VI from the automotive diagnostic command set library (CAR 429636). This is caused by a change in LabVIEW 2013 to the installer builder. There are two parts to this issue - 

 

1) If your project contains VIs in certain libraries, you are not able to build an installer that contains these VIs. There is no workaround for this and we intend to issue a LabVIEW 2013 f2 patch which will address this. (CAR 429282)

 

2) If your project contains VIs in certain libraries, you are not able to build a source distribution of those VIs. This is related to 1) but there is a workaround for this. If you go into your build specification Additional Exclusions and check the box for Remove unused members of project libraries you will be able to build fine. This issue will not be addressed by the patch.

 

I find that the appbuilderlogging INI token is extremely helpful for debugging build problems, the additional exclusions are often another good place to look at if you are running into strange build errors.

 

Thanks

Thanks for the update JeffP

I recently opened a new topic in the 'LabVIEW Bugs' forum to track the issue in the future (forget to post it here though )

http://lavag.org/topic/17166-error-generation-preview-in-installer-properties-caused-by-automotive-diagnostic-command-set-120/?hl=429636

The INI token is indeed very helpful, but unfortunately very difficult to discover (If it wasn't for Neil I would still be stuck...).

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?