Jeff B

I don't know a complete answer, but for one thing, if you save a breakpoint into a VI that's password-protected, when that breakpoint is hit, you're prompted for the password (if it's not in the password cache), and if entered, you can debug the VI. This ability can be pretty useful, and I'd be surprised if it didn't introduce a non-zero performance hit.

Hmm, there's one I haven't seen before. I'd be interested in how you got into that situation - specifically where next time you launch LabVIEW you get the autosave recovery dialog with one "blank" item... or any blank items for that matter. Please let me know if you can reproduce this. Given the first dialog, the fact that you get to the second doesn't surprise me. Also, the lack of a "do nothing" option is intentional. By the time the autosave recovery dialog is complete, we must not have any un-recovered files remaining in the autosave directory for the version of LabVIEW you are launching. If you end up at that second dialog, it is telling you that you need to manually go to the directory displayed and copy any files out of there before continuing. If you have any further questions, or suggestions to make this message clearer, please let me know.

To be perfectly honest, I'm not that familiar with the inner workings of the shared variable, but as I was investigating this issue, I learned a little about these entries. Generally speaking, the purpose of the persistent IDs is so that variables can still identify themselves as being the "same variable" even after being renamed. It surprises me that you have no variables in your project and yet these varPersistentID entries still appear. Are you sure some library in your project doesn't have any variables that you may have forgotten about or just not be using? I don't know what consequences removing them from the project could have. It could be very bad, as in your project may no longer load. If you made a backup you could try it, it probably wouldn't have any negative consequences and would probably fix the autosave issue, but I'd hesitate to tell you it's 100% safe to save the project that way and keep working. I dont know how big your project is, but if it's small enough or otherwise organized simply enough such that you could re-create the project by re-adding its contents, particularly if you really don't have any variables in the project, that is likely to fix the problem as well, and in a safer (but more potentially error-prone and time-consuming way).

Thank you for the updated info, I apologize I somehow missed the replies at the end of May. This is now a known issue, and is documented internally with ID# 115766. I have already made changes to improve the error reporting in a future version of LabVIEW. silmaril - if you still have the LVPROJ file, open it in a text editor like notepad. See if one of the first few lines contains the text "varPersistentID". If so, there's no need to send it in. If you do not see this text in your project, please let me know. Be careful to not save or modify the project in the text editor. Bob - I think you've touched on the crux of the issue here, and that is this issue's connection with shared variables. See here for more info: http://forums.ni.com/ni/board/message?boar...hread.id=334074

I don't expect these issues are related, but are you able to answer any of the other questions I posed? Particularly, have you attempted to reproduce it in a new project? What about a new project with a target added? What about once you've saved the project and then make more modifications to it? I understand that troubleshooting this probably isn't that high a priority for you, but as I haven't been able to reproduce it, any information you're able to provide is greatly appreciated.

For anyone who's seeing this problem, what can you tell me about your project? What kinds of things are in your project when you see this? Are you using other targets (RT, FPGA, etc)? Is it a particularly large project? Can you reproduce it starting from an empty project? Good observations David, I'll expand slightly on your steps that might help to reproduce the issue... 1. Close and re-launch LabVIEW. 2. Open your project and make some change to it. 3. Run any VI (we trigger an autosave before VI execution). As David said, if you see this dialog once, you will not see it again until you close and re-launch LabVIEW, making the first step being necessary. If anyone can reproduce this I'd like to know how - preferably in a way that doesn't require hardware, but if that's required to see the problem, that's fine too. Be sure to let me know what add-on module(s) you have installed (like RT, FPGA, etc). Thanks, Jeff

Just thought I'd add a couple of comments... Some of it is new info, some is just a different way of saying what TobyD said... An application built with LabVIEW 8.5 will be a 32-bit executable. It will run in the 8.5 run-time engine (also 32-bit) regardless of the bitness of Windows (runs in the WoW layer on Vista x64). The same installer should get built regardless of whether the machine building it is running 32-bit or 64-bit Vista, and it will install on either one as well. Saying that a 32-bit application will not be able to take advantage of the larger amounts of memory available to a 64-bit OS is not entirely true. On a 32-bit OS, LabVIEW 8.5 can access only up to 3 GB RAM, and even then, only if you have the /3GB boot option. On Vista x64, LabVIEW 8.5 (and therefore a LabVIEW 8.5-built executable) can access up to a full 4 GB RAM. However, as it is still a 32-bit application, it cannot go beyond this, which I believe was TobyD's point. Also, contrary to what TobyD mentioned, USER32.DLL and KERNEL32.DLL have not changed name. Both the 32-bit and 64-bit versions of these DLLs exist on Vista64, but they are BOTH still named USER32.DLL and KERNEL32.DLL. Further, as counter-intuitive as it might seem, the 64-bit versions of these live C:\WINDOWS\System32, and the 32-bit versions live in C:\WINDOWS\SysWOW64. No, I didn't mix those up, maybe Microsoft did, but the product's released now, so oh well. At any rate, you shouldn't have to worry about this too much, as 32-bit applications know to look for these things in the 32-bit location, and 64-bit applications know to look for them in the 64-bit location. That's not to say that any application written on 32-bit Vista or XP will work on 64-bit Vista. The article TobyD referenced is good to make sure your application is both Vista and 64-bit ready. But as far as the NI components, you should be fine. Finally, I had to look up the details on VISA support. It looks like VISA 4.1 was the first version to support 64-bit OSs. As long as you have VISA 4.1 or later installed on the machine where you're building the installer, it shouldn't matter whether the machine is running a 32-bit or 64-bit OS. Hope this helps! Jeff

This issue (the one with projects losing build spec info after autosave recovery) is fixed in 8.5.1. Of course Aristos Queue is right, we'd prefer to figure out what's causing your crashes in the first place and get those fixed as well, so please report them, particularly if you can reproduce the situation.

Sorry for the delay in response. I've reproduced this. This has been reported to R&D (4ENAG200) for further investigation.

Hey guys, Do you think the project missing items that were there is a problem with autosave, or just the fact that you'd made changes to the project since the last time the autosave occurred? If the former, I'd like to figure out why certain types of information in your projects appears to not be getting autosaved. If you have any further information about whether or not you're able to reproduce this, please let me know. Thanks!

Hey guys, The invite managed to find its way my direction. I'd really like to meet you guys, so I'm going to try to make it. A few questions I have: Originally you mentioned seats were limited, but it looks like over 60 people have accepted the evite already! How many seats are there? By when do I need to pre-pay? Any guesses as to when the group would arrive at the Salt Lick? I probably won't be coming from the convention center. Based on your departure time, the distance, and the beer run, I'm guessing you would get there between 6:45 - 7 pm? Thanks! Jeff

Hello all, I presented the originally referenced Dev Days presentation. I have not read all of this discussion, but I followed-up on this topic. I'd suggest that the reasons it was presented is that the person who put together then slides had a false impression of the level of impact it would make. It is true that, when marking inputs as required, in certain circumstances we save a little bit of time by not having to copy in the default value for that control. This amount of time is probably very small, and this technique could potentially be used to eek out just a little bit more performance. It will not likely have a big impact. Sorry for the confusion. Take care, Jeff

Hello Norman, As a result of your report, we've identified an issue that can occur when calling remote VIs dynamically (and in particular, when using the call by reference node) when the call by reference node resides on the diagram of an Express VI's configuration page. This actually doesn't have as much to do with the application instance the configuration page VI is running in as it does the specific mechanisms used inside LabVIEW to launch the configuration page when the Express VI is double-clicked or right-click properties is selected. Please let me know if this seems to summarize your situation, or if you have seen these "hangs" in other situations as well. One possible workaround might be using the Run VI method instead of the call by reference node, but this can get quite cumbersome in a hurry, and requires the dynamic callee to be idle. Call By Reference Nodes can call VIs that are reserved for execution whereas the Run VI method cannot.

Hey Jim, Sorry, maybe it was your post in the other thread that speculated that the built-in mass compile opened, compiled, and saved every VI, regardless of whether or not it had been visited before that threw me off. Or maybe it was just a Friday thing, but I think I see your point now. The built-in mass compile keeps track of no previous work (at least with caching off), but at load time it knows it doesn't need to repeat the compile or save steps for VIs that have already been visited. It seems your VI uses a (quite reasonable) heuristic that VIs in a given directory are likely to load a common set of subVIs to reduce the amount of time spent loading VIs. This is somewhat similar to what the built-in caching does, but not quite. I think from the standpoint of load efficiency, your way is better because it sort of uses a "custom cache size" for each directory of VIs, which is automatically defined as the number of VIs in that directory, so to speak. With either approach there will be some amount of re-loading VIs that have previously been loaded and closed, but I think your VI minimizes this more than the built-in mass compile, even with caching enabled. I think there's value in the current built-in algorithm with no caching, albeit slower, to guarantee no cross-linkages occur (provided there aren't missing VIs). However, I do think it'd be cool if there was an option to do something like your algorithm if you wanted to use caching, or perhaps a different algorithm altogether that neither one of us has thought of yet, who knows. I'll talk to some people and see what I can do.

The built-in mass compile doesn't keep track of what it has previously saved or what it has previously loaded as top-level. I'm not sure where you're going with this, do you have a follow-up question regarding this? Yes, the fact that the sum of time spent compiling & saving a VI is more than that of just loading it once its already been saved in the current version is a general statement, but one that is true for just about any VI. I suppose there may be cases in which this is not true. I've had no part in writing the code behind the built-in mass compile code (which is not written in G), and it's not my goal to try to convince you or even suggest that the built-in mass compile is in some way better than your VI approach. I originally just wanted to point out that there were differences with your approach that could be problematic in certain circumstances. Clearly this is the case with the built-in one as well - namely speed limitations, especially with no cache being used.