eberaud

Great presentation, thanks Derek.

Thanks for replying. I'll go to the pub directly and see if I can meet fellow CLAs or NI staff!

I am attending the CLA summit for the first time next week. I'd just like to check if anybody here is going as well and if you'd be interested in meeting on Sunday evening and then heading to the Sunday night social together 

Good to know. I'll un-nest them! 

Thanks. I guess I might have found a particular situation because of nested libraries:

Truly amazing tool. I now have a very visual way to explain the impact of my code refactorization. Jon, where can we find the legend about the colors and shapes for the force diagram and dependency wheel? Also, I originally thought the shape of the leaves on the dependency wheels indicated the direction of the dependency, but it now seems to me that it only depends on the size the libraries takes on the wheel.

Hi, I have contacted NI sales services but it's a great frustration as usual, so I will try to get some support here

Basically for a project I need 2 CAN ports and I decided to go with XNET and Compact DAQ. I have 2 solutions I try to choose from:

Solution 1 --> One 4-slot chassis with 2 NI-9862 modules (one port per module)

Solution 2 --> One 1-slot chassis with 1 NI-9860 module (this module has 2 ports)

I am confident that solution 1 will work well since I already had a project in the past with one 4-slot chassis (cDAQ-9174) and one NI-9862 module. But going with solution 2 will allow me to cut cost significantly. I just want to make sure it will be absolutely seamless and transparent for the software. Does anybody have experience with the NI-9860? Can it be considered as the equivalent of 2x NI-9862 as far as the software is concerned (LabVIEW driver) or does it remove some performance/flexibility/other?

Thanks!

Thanks to all. Things are much clearer now!

Actually that setting is inherently used by the application builder. Whatever you define as top level VI in there gets intrinsically set this flag and will cause the VI to launch your application.

Oooohh 

You'll see this sometimes when the developer doesn't have access to the application builder, but wants the user to be able to double-click the VI on their desktop and have it start running immediately instead of being presented with the opportunity to edit the VI.

Thanks, that makes sense. We only work in a executable environment, so I rarely think about the needs of those of us who need to run the sources.

Thanks. Still a bit of confusion:

"Open" - This is when a specific VI (or control, though there're not many things that happen when a control is opened) is started (double click on it in a project or in a file system folder), and you can see its front panel on your user-interface.

When a VI is started? You don't mean executed, right? To me it's rather "when its front panel is open". Sorry I just find the word "started" very ambiguous here.

Run when opened: When the front panel is opened the VI is automatically started.

When would you ever want to do that? I always want to control when a VI runs, either statically as a subvi on a block diagram, or through the proper VI Server method if it's a dynamic call. Do you mean that, for example, you would use a simple "Open FP" invoke node and that will run the VI automatically in addition to opening its front panel? Any other use case?

Reviving this discussion after being surprised by this behavior: (but now that I think of it I shouldn't have been surprised, it kinda makes sense!)

The reference I get through the Static reference is different from the one I get through the Open VI Reference even though the VI in question is not re-entrant. Does it mean I have 2 references to manipulate the same VI? It seems it's the reference that gets prepared for asynchronous call and not the VI itself, since the Start Async function gives me an error if I wire Staticref instead of Openref to its input.

While on the ACBR topic, I just noticed the subvi can't know which VI called it. In my screenshot, the caller of chart.config.vi calls it through an ACBR node, but the call chains shows that chart.config.vi.ACBRProxyCaller.5180012F was the caller...

One of the significant confusion stone in my understanding of LabVIEW shoe is the difference between "Call", "Launch", "Load", and "Open". I'm not adding "Run" to this list, as it is more self-explanatory, at least I believe. 

In the Execution window of a VI Properties, we can see the following options:

"Auto handle menus at launch"

"Run when opened"

In the Customize Appearance window, we can see those other options:

"Show front panel when called"

"Show front panel when loaded"

I'm not asking for an explanation of those specific options, but I'd like a more general understanding of what those "Call", "Launch", "Load", and "Open" verbs mean.

Thanks!

We deprecated those VIs in LabVIEW 2015 and created new ones that use error in/error out instead of embedded error handlers:

 That was a very good idea. I never liked those guys.

The other thing I find for myself is that I loathe people who say "simple error handler is bad, lets use 1 button dialog". 

Definitely. The worst thing about the LabVIEW 1 or 2-button dialogs is they use the root loop, so while displayed, many functions such as Open VI Reference just have to wait their turn to access the root loop, causing very undesirable behaviors! A few months ago I tracked down and replaced all those dialogs with my own standard dialogbox.

The factory pattern is great and I like to use it all over the place. I think your approach is good, and the variant method definitely works, I've seen it many times before. However it requires you to be extra diligent since a slight difference between what was passed inside the variant and the way to cast it back into usable data would generate an error that could be tough to troubleshoot along the road. Unless you use a typedef, modifying the data type on one side won't automatically modify the other side.

One alternative idea would be that the initialization data is itself an object. You could have an abstract class "initialization data", and then child classes such as "InitDataClassA" and "InitDataClassB". Look at the decorator pattern, it might give you some idea. Of course you're adding another layer of LVOOP, so there is a complexity trade-off.

I guess you mean that the other way around

This means this then that? 

True, I'm surprise your link still doesn't mention Windows 10!

According to that link and this link, LabVIEW 2015 is officially supported by Windows 10.

Now, if Alpha.vi is saved looking for Yoda.lvlib:Beta.vi and you then move Beta.vi out of Yoda.lvlib and into Yolanda.lvlib, now when you load Alpha.vi, it finds Beta.vi at the right path, but the qname doesn't match, so it considers the subVI to be missing, and searches accordingly.

Old thread, but explains exactly what I've been working on for the last 3 weeks! 

There are five library types: lvlib, xctl, lvclass, lvsc and xnode (the last of these being somewhat mythical). Lvlib and lvsc do NOT load all of their member VIs. The others do. They do list all their VIs in the project tree, but the VIs are not loaded into memory. All of them do load their nested libraries into memory.

I understand the concept of loading VIs into memory while in the dev environment. But what about building an executable? Let's say I have some VIs in a lvlib that are not being used anywhere in a certain application I'm going to build. But since there are other VIs in that lvlib that are being called, I see the lvlib and all its members in the dependencies. The unused VIs won't be loaded in memory, but are they going to be included in the executable?

I started a new thread because I didn't want to hijack the great article about dependencies between classes : https://lavag.org/topic/19421-visualizing-dependencies-between-labview-classes/

Historically our code has contained numerous circular dependencies, where a member of library A would call a member of library B, and another member of library B would call another member of library A.

As you know this situation isn't great for at least 2 reasons (but I'd love to hear even more reasons from you)

1) There is no way to load just a basic library in a small project without loading almost all the source code of the application

2) There is no hope to be able to switch to Packed Project Library one day

After many days, I managed to refactor the code and got rid of almost all of the circular dependencies. I'd like to have a visual way to show the difference between the "before" and "after". The VI Hierarchy tool does show that but there is just way too much going on to really make sense of what we're seeing. I'd like a similar tool that would only show the dependencies between libraries, without seeing the details of the libraries content. Do you know such tool?

Thanks!

Thank you Rolfk! Seems like our best move is to use either 2 PCs (be it through virtual machines or not). We do have to guarantee the quality as those builds go to customers.

Thanks, I think you understood my question, but I thought I would post a picture to be a bit more explicit about what I intend to do:

Dear all,

My team and I are in the process of migrating our application from LV2011 to LV2015. While in this process, we need to be able to make 2015 builds for testing purposes while continuing to build 2011 releases for our current customers. We have a dedicated build PC and I initially wanted to use to build both versions.

The issue is: the version 15.0 of many drivers such as NI-CAN, NI-XNET, NI-VISA doesn't support LV2011. When I installed the version 15.0, the libraries were actually removed from the vi.lib folder of LV2011.

The thing is for the LV2015 version, I do want to use the latest libraries (15.0)

Before trying to reach a solution, I would like to understand one thing about those libraries: when I install them, they do 2 things:

(A) Install the libraries in the vi.lib folder to be used by the development environment (Development PC)

(B) Install some resource files to be used by the run-time engine (Deployment PC, aka customer PC)

Here is the question: Can I use a version 14.0 for (A) and 15.0 for (B)? I'd guess not but I like dare asking naive questions, you never know...

If I want to be able to keep my ideal scheme (14.0 for LV2011 and 15.0 for LV2015), the 2 solutions I see would be:

1) I copy the folder from the vi.lib of another computer which has the 15.0 installed to the LV2015 folder of the build PC which has the 14.0 installed (so I don't install 15.0 per say)

2) OBVIOUSLY I get a second build PC

Have you ever had to deal with those issues?

Thanks!

They probably want you to compare total cost and the total input. Use a "greater or equal to" function which will generate a Boolean and wire this Boolean to the Select input:

If Input >= Cost then Change Due = Input - Cost and Additional Money Needed = 0

If Input < Cost then Change Due = 0 and Additional Money Needed = Cost - Input