Yair

Note that LAVA seems to have forgotten its notification settings and stopped sending emails when new replies are posted to followed threads. This can be fixed by going to the notification options page and checking the email option:

You're probably thinking of a tab in an ActiveX or .NET container. Why are you using a tab at all? Just use a single subpanel and use the "tabs" (a ring or a list box works well) to control which VI is currently displayed in the subpanel. Then you can add as many items as you want at run-time.

My guess would be a vi.lib or user.lib VI, as those don't get included automatically in a source distribution. I would start by unchecking the exclusion boxes in the build spec. Of course, then you will probably get some conflicts, because you will have the same VI more than once, but you can either ignore that or use a library to wrap everything in the distribution in its own namespace.

The only thing I know of which can cause that state is if the VI is broken (although it's quite possible there are other causes). My guess would be a missing subVI or typedef. If you have a reference to the VI then you can presumably use that to open its FP or BD to get a more detailed message (if it's an EXE then presumably you would need to make sure these aren't stripped).

The 3D graph, if memory serves, is an unlocked XControl, so you should probably be able to edit it, although I don't know how easy it would be and you would need to create a copy of the entire library so that it's not overwritten when you upgrade LV. Presumably it's somewhere in vi.lib and you should be able to easily see it by right clicking a 3D graph and selecting Advanced>>Show Diagram, which I believe should be available in all XControls.

Vote for this idea (http://forums.ni.com/t5/LabVIEW-Idea-Exchange/more-exclusion-settings-for-the-VI-Hierarchy/idi-p/963121) and follow the comments there.

You mean like this?

Recently I've been working on upgrading two projects to accommodate new requirements: An automated calibration system for water meters. It calibrates the meters by setting a series of flows and comparing the volume measured by the meters to the volume measured by reference meters. This includes control (all the valves, pumps, etc.), a calibration process, talking to hardware with a custom protocol (the meters which require all kinds of stuff) and working with the factory ERP to get calibration data and to write results. A control and management system for a potato packing plant. The plant gets potatoes from the fields and then it cleans, sorts, packages and ships them. This includes not just the entire control system for the plant, but also a management system which tracks incoming material, production data and shipments and produces shipping documents and reports. The control and management systems are both written in LV and integrate with each other fully. Until now this plant processed roughly 150 Tons in a shift, but since it's being upgraded and more than doubled in size, I have no idea what that figure will be when we finish the upgrade.

These are questions from the online CLAD example, and people have probably asked about it before. Do a search for "CLAD questions" or for the text of the question itself.

LAVA - creating new LabVIEW land*. * "Creating new LV frontiers" actually sound better, but it deviates from the land-creating-lava metaphor. Just be happy I didn't post my original version - slowly flowing where no man dare touch the floor.

I'm not sure what your question about opening the VI reference is exactly, but in any case, you should note that what you're doing will not help you in determining which version the VI was saved in. To do that, you need to call the Application class method Get VI Version and give it the path to the VI. Also, there's a utility called the Dataact Version Chooser which should already do this, so you might be better off using that. I haven't used it myself, so I can't comment on how it works.

Exactly. I haven't used either Git or Mercurial, but I have seen Thorvald's session a couple of years ago and I remember that he emphasized that the reason Git is so much better is because it does merging properly and effortlessly, something which is a problem in LV.

Can I use it even if I haven't been to NIWeek?

LAVA - Slowly flowing where no man has gone before. Sorry.

You forgot Lady Gaga.

I'm fairly sure that the Open VI Reference primitive still has the root loop requirement, so if you're using that to get the reference just before running the VI, you would still have the same issue.

You're saying that this is for saving to config files. OpenG already has VIs which do that (the variant config VIs package). They also use the OpenG variant VIs (I'm assuming in pretty much the same way you did) and they plug into the config file API. MGI has a similar tool (the read-write anything VIs) which uses built-in functionality, so it should hopefully handle all data types.

Or most adults.

Not that easy. You can theoretically* access VIs, but since they don't have their block diagram, they are only going to be of limited help. * I say theoretically because I believe this was made harder in 2010, although I'm assuming it's still far from impossible.

For the reference, use the terminal's reference to get a reference to its control (available as a property), then call the Create Reference method on that control. For the constant, you should be able to use the New VI Object primitive to drop a Class Specifier Constant, which you can then configure using its Type property, which accepts the name of the class (although I don't think that will get you the strict reference which you seem to want). The class is in GObject>Constant>Refnum.

I have seen similar things with 8.6 and 2009. This happened to me just yesterday with 8.6, and I believe I can describe it like this: I think it was the first time after opening the IDE. Searching for something (I think I used Find All Instances on a subVI) opens the find window and does the search. When the search reaches the last VIs, LV becomes unresponsive for a few seconds and then the windows are shuffled around and the find window is no longer in focus. I'm not sure if this also happens on subsequent searches. I tried it now and it didn't happen.

And according to AQ on that thread, this has been fixed in LV 2011.

I finally figured out what causes this - http://forums.ni.com/t5/LabVIEW/LabVIEW-locks-unrelated-files-if-you-drag-them-over-a-LabVIEW/td-p/1629378

How about not being able to solve it even a single time, because the cards have been dealt in such a way that you can't even make a move or where you can only make a single move and then you're stuck (which I have seen happen more than once)?

If you're getting a file not found errors, it's usually because of the way relative paths are built. The easiest thing to do is to display that path where LV expects to find the file. This should help in determining why it's pointing at a location other than where the file is.