Yair

Use the system tab rather than the Labview one. It has the method to create them on-the-fly (if I remeber correctly).

You're probably thinking of a tab in an ActiveX or .NET container.

I am stuck on how to be able to generate new tab pages on the fly. In the meantime I will just have some number of blank subpanels within parent tab pages.

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.

That VI is built as a source distribution

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.

It would be nice to have OpenG libraries excluded from the VI Hierarchy window which is not an option for user.lib.

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:

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

The hot flow to where no one has gone before.... Slogan the Next Generation (and gender neutral)

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.

It doesn't really address the fundamental problem that is the source of all the others listed previously; VIs are binary files and all these tools are made for text files.

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.

Abraham

Moses

Jesus

George Washington

Detric Bonhoeffer

Don Quiote

Ben

You forgot Lady Gaga.

I can't tell you how happy this makes me. No more will my users be able to 'pause' dynamic VI launching by dropping down a menu and not selecting anything...

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.

(Heh... as if irrelevance ever stopped a teenager from trying to win an argument.)

Or most adults.

...though I do now vaugely recall prior discussions about how easy it was to dig into an exe to rev eng source code.

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.

One thing I have seen intermittently with our large project is that using Ctrl-F in the Project Window to search for VIs by name can result in the system slowing down until LabVIEW is shut down. In this state, most mouse clicks take several seconds, and any time a different window is selected, the Z-order of my open windows is shuffled in a seemingly random way, which takes 30-90 seconds to sort itself out and accept any more mouse or keyboard input.

However it only happens sometimes, and the link to control-F is only suspected, not proven, so I've been having trouble reproducing it for a support ticket. Have you seen anything like that?

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.

I finally figured out what causes this - http://forums.ni.com...EW/td-p/1629378

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

What really annoys me is when LV grabs onto files which were opened by completely separate applications.

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

There is no "unfair" in a game of solitare.

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.

There are various controls here - http://lavag.org/files/category/1-user-interface/

You can also find some stuff here - https://decibel.ni.com/content/groups/ui?view=documents