Christian_L

Doesn't it come down to the fact that by-reference objects are really references to by-value objects and all references in LabVIEW basically behave the same? In my mind I prefer to think of DVRs as reference to something and sometimes those things happen to be (by-val) objects; I don't think of by-ref objects to be a unique type of data type in LabVIEW.

Congratulations, Jim. I'm sure she'll be wiring in no time. You know peek-a-boo is just a lesson in object persistence.

It looks like the problem is not with the Default value of the Tab control, but in the drawing code. i.e. the drawing of the tab control ignores the default and sometimes the current value of the Tab Control. If you switch to the diagram and then double click the Tab Control terminal, it will jump back to the front panel and will set the Tab Control back to the first page regardless of which page it was on earlier. The default value for the Tab Control is stored however in the VI, so resetting all controls and indicators back to their default value will work in the VI code. This has been previously reported as CAR 182844 to LabVIEW R&D.

Sounds like a very good application for LabVIEW. Here's a simple example of implementing this.

Or build a really large LabVIEW diagram. No need for subVIs any more.

Corrected link: http://zone.ni.com/devzone/cda/epd/p/id/6287

Just FYI, in Systems Engineering we have implemented this solution using SQLite for the newer VxWorks based cRIO targets. You may want to contact us before spending a lot of time on that implementation.

You'll likely need to include your 8.6.1 project that is causing the problems with your posting on the NI forum in order for NI to be able to look into the problem. As you mentioned this doesn't happen for every project and so the AEs and R&D will need something specific to look at to figure out what is going on.

Using Save As... in the File menu you have the option to save the entire VI hierarchy in a new location (folder). This will save the current VI and all statically linked subVIs. Any subVIs that are called dynamically must be saved manually in addition. Another option is to use the Source Distribution under the Build Specification in the project. This requires the Application Builder. http://zone.ni.com/r...source_dist_ex/

Based on a quick test, I think the answer is both. On my laptop with a wired and wirelesss network interface, LV 8.6.1 opens a VI server on both adapters and I can connect to either one from a remote system. I tried the following code to determine which adapter was already used by VI Server and it turned out both.

TCP does not support broadcasting as it requires a connection for each communication link, however UDP does allow for broadcasting to all systems on the local subnet. Each system listening just needs to open a UDP port at a known port number, and then you can broadcast a message using UDP to that given port number. (Send the UDP message to 255.255.255.255 for broadcasting.) You can send out a Discover or Ping message so that each system listening responds to the sender with its name and IP address. This wil provide a list of available systems to the sender. You can check out the Asynchronous Message Communication (AMC) reference library which handles most of what you are asking for. It includes a Ping function which will discover all of the systems on the network which have the AMC listener enabled. This allows you to get a list of devices on the network so that you can send directed messages to each.

I don't see why either of these would cause us not to use standard terminology for what seems like standard programnming features. If we want LabVEW to be accepeted as a programming language, which at least some strive for, then we should use programming terminology when talking about it. For people without programming experience, I don't think it makes any difference what we call it, as the name won't mean anything to them either way and they have to learn the concept. Should it be a GHEER-MLB or a widget pointer? Which of these would you rather learn how to use? But the point should be to get away from calling it native anything. Either is native and you don't need to call it that, or it isn't native and needs a different name. Should they be NLCs* or just classes? *Native LabVIEW Classes

I would look at other programming languages and see what they call their classes and objects. Looking at C++, it seems the term class and object are pretty popular. So if LabVIEW has a native class and object, why not call them class and object? (It's not like were calling an integer an LVINT.) Since the wire representing a native object in LabVIEW is 'ByValue' then use the appropriate modifier for a reference to an object, like object reference or object DVR. I guess a single element queue containing an object would be an object QR. We may still need to differentiate between DVR and SEQ containing an object.

What you describe is a very common requirement in industrial control applications, where often a touchscreen is used to display these individual control screens. We (NI Systems Engineering) have put together a reference design which is one solution to this requirement. It is called the HMI Navigation Engine (HNE) and parts of it are also included in the LV Touchpanel module (8.6 and later). The reference design is based on pure LV code and will work on Windows as well as LV touchpanel targets. The HNE uses a main VI in your UI application which is not visible to the user. It calls any number of subVIs, each of which is one of the screen you show to the user. The HNE VIs provide easy-to-use tools to switch between screens. They also keep a record of past screens visited so that you can easily add a Back button which jumps to the previous screen. The number of previous screens stored in memory can be configured. The HNE document describes all of this in more detail.