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.

So I'll go ahead and respond to this and an earlier post of yours on a different thread that I didn't have time to post anything on yesterday. Caching: The caching you do is quite similar to the way the built-in mass-compile's caching ends up working, albeit implemented in a somewhat different way. The built-in mass compile goes through VIs in a particular directory, and simply has a circular buffer of whatever size you specify of VIs that it will keep in memory. I don't know all the details about how subVIs are handled. For example, if you mass compiled a folder with 10 VIs, and each of those called 100 different subVIs, would that yield 1000 VIs in memory as the cache holds the 10 top-level VIs? Or would just 10 most recent top-level or subVIs with their dependencies be held in memory? I'm not sure, but I'd guess the former. Of course someone here knows, but I'm not sure it's that relevant. File types: VIT and CTT are a good start, but not particularly common as you were probably already thinking. I was thinking more of other types you can find in the "files of type" pull down on a file dialog in LabVIEW (on Windows at least). I think it would be best to also handle LVPROJ, LVLIB, XCTL, XNODE. However these aren't "instruments" that can be saved with the "Save Instrument" function, so it'd be a lot more work than just adding more types to your semi-colon-delimited list of file types. The good news is I don't *think* you take much performance penalty for loading those files non-mass-compiled like you do when loading large VI hierarchies of non-mass-compiled VIs, but I'm really not sure about this. I don't know how much this helps the end issue, but I wanted to explain a little bit about how the built-in mass compile works, as I don't think it's quite the swine you describe. The general mass compile algorithm is designed to be thorough and "as-safe-as-possible", with the built-in caching option added to improve performance in the face of the possible risk of cross-linkage dependning on what you're mass compiling. The built-in mass compile does load VIs on a VI-by-VI basis. Each time a VI is loaded, all of its subVIs are brought into memory as a result. For all VIs we just loaded, we see if they have a docmod (typically as a result of a recompile after version bump) and if so, we save them. We then close them all. Wash rinse and repeat on the next VI, etc. The longest parts of this process are the compile and save, which do not happen for VIs that have already been saved. Take care, Jeff

The Dynamic Data Type (aka. DDT) is intended to provide an abstraction from the data type for Express users, but in doing so, often tends to make things unnecessarily confusing when you're trying to manipulate things that aren't quite so standard. I believe what you'd want to do is convert your DDT to an array of waveforms using the Convert From Dynamic Data, then find your signal in that array and use the "Set Waveform Attribute" to set the "NI_ChannelName" attribute (it's just a string) to whatever you want. Then convert back to DDT when you're done. Any waveform data type has a set of "attributes", it's just not shown on the front panel control / indicator by default. You can turn it on using visible items fly-out menu. Hope this helps!

Please see here regarding 8.0.1 mass compile performance: http://forums.ni.com/ni/board/message?boar...ssage.id=172705 And yes, of course the user VI for improved mass compile performance that I referenced is the one Jim Kring wrote. It's a cool VI, but also has some limitations, though I don't really know the best way to address them in that VI or what their consequences would be on the mass compile. And FYI, the reason I didn't give specific credit in my post to Jim or link to this thread is mostly because he used a private VI server property, which is something we generally don't condone publishing un-password-protected. Still a cool VI though.

For some comments on mass compile speed, please see here: http://forums.ni.com/ni/board/message?boar...ssage.id=172705

For those who hadn't heard, it looks like NI just acquired Measurement Computing, so I'm guessing they probably won't sue themselves anymore.

I recently encountered this, and while it can be annoying, it is not a bug. Let me explain. When you get a mouse down or mouse up event on an object, you are truly getting the same event that LabVIEW itself gets. For example, in the case of a switch-when-pressed boolean, the mouse down causes the button to change value. That is, when LabVIEW internally gets the mouse down event over this boolean, it internally says, "hey, I need to change the value of that boolean in memory, change its front panel appearance, etc." At the same time this is happening, your event structure looking for mouse down events fires. The first thing you do in the event frame is read from the terminal / local / property node associated with the mouse down control. There is a genuine race condition between the terminal on the block diagram being read, and LabVIEW internally updating the value of the control. As with any race condition, the frequency of this could vary from system to system, but in my experience LabVIEW is usually able to process the actual change in value before the terminal is read in your event structure, but this is not guaranteed. With the value change event you are guaranteed to get the most recent value the control changed to. Further, if you looked for the Mouse Down? filter event, you are guaranteed to always get the old value, because your event frame is processed completely before LabVIEW internally gets a chance to respond to the mouse down. I do not know the internals of how exactly events are handled in LabVIEW, but I suspect "fixing" this behavior could cause other undesirable behavior. Despite perhaps not helping solve the problem you were attempting to accomplish, I hope this at least provides some clarification.

Hello LabVIEW Users, Thank you for reporting this issue. Prior to 10/13/2004, National Instruments was not aware of this issue, and we apologize for any inconvenience it has caused. We have since investigated this issue, and I would like to pass along more details about it. This issue occurs when a wire is connected to a For Loop, through the For Loop's diagram, and out the other side of the For Loop, with indexing disabled. Within the For Loop, the wire is branched to one of several operations such as Add, Subtract or Increment. When the original wire comes from a constant or a computed constant and all other wired inputs to the function are also constants or computed constants, the output of the function inside the For Loop can produce a wrong result. The wrong result will either be the constant value itself, or the result which would be produced by the default value for that type, depending upon the operation. While we feel that this issue should affect relatively few real-world applications, we are presently working on a longer-term solution for this, and will post more information in the NI Discussion Forum thread when it is available. Jeff Boettcher Product Support Engineer National Instruments - LabVIEW R&D