Aristos Queue

Bingo.Think about it --- if you do "preview", you have to have a copy on your local wire and a copy left behind in the queue. Why? Because as soon as your VI continues past the Preview node, some other thread somewhere could Dequeue the data in the queue. If you haven't made your own copy, you're now sharing data between VIs... and much badness ensues (one stomps on the other, one disposes the data while the other is still using it... ug). For the record, Notifiers always do the equivalent of a preview because there may be any number of Wait nodes listening for the same notification.

Suggestion from LV Architect: How about an XControl whose data type is a Data Value Reference of your array and you manage the display of the data that way... AQ fills in details: So basically, you read your data from disk, and then use the New Data Value Reference to stuff the data into the DVR. Then you write that to the FPTerminal of a custom XControl. That custom XControl has an array display with the array index hidden. Instead, you have a separate numeric control. You grab subsets of the array to display and change which subset you get each time the user changes the value in the numeric control. This should get you down to just 1 copy of the entire array with copies of some very small subset (however big you make the display on the FP of that XControl).

There are plenty of nodes in LV that execute even if there's an error in -- Close Reference, for example -- and the behavior there is well defined. I would assume the property node would follow suit. I think the bigger question is how would we change the block diagram to indicate "executes even if there's an error in" and whether this setting would change the behavior *between* properties... currently if you have 3 properties on a single node, if an early one triggers an error, the later ones don't execute at all.

You have the FP open when running this VI. That means that you have the buffer coming from the Read node, the Operate data and the Transfer data. Do this: Close the VI so it leaves memory (that deallocates all the data). Open a new VI. Drop your current VI on the diagram as a subVI and then run the new VI. You should only see the one copy of the data that is coming from the Read node. Because that one copy is the already allocated buffer for when you run the VI again. In other words, if you run the VI a second time, you won't take a performance penalty having to allocate that first buffer because LV will use the one already allocated, assuming it is the size needed. Running thousands of VIs you'll find that most of the time arrays and strings are the same size every time they go through a given block diagram. LV leaves the dataspace allocations allocated all the way through the diagram because for repeated runs, especially direct runs of the VI that happen when you're testing and debugging your VIs, the data is the same size and you don't have to do the allocation every time.

Further details... Items marked with "I THINK" may not be correct and may be amended by later posts. If the front panel of a VI is NOT loaded, there is only one copy of the data, the data actually in the terminal. So there isn't any copy overhead when calling a subVI whose panel is not loaded. Notice I said "loaded" not "open." A VI's panel is loaded ifIt's front panel is actually open There are any local variables or any statically-linked property nodes on its block diagram Someone has obtained a control reference to any control on the panel or to the panel itself The VI has unsaved changes (the panel is kept in memory until you save the VI) You're doing remote debugging of the VI All of these can create the situation where a VI runs slower than expected, particularly while debugging. [*]Application Builder strips the front panel from VIs by default except the top level VI. This is specifically to avoid this slowdown cropping up by accident.[*]I THINK that if a VI is running in the UI thread (File >> VI Properties >> Execution >> Preferred Execution System) then LV can skip the transfer data and copy directly to the operate data because it knows there cannot be a draw event going on at that moment. Not sure about that.[*]A local variable is more efficient than a Value property call because both make a data copy but the Value property has the overhead of having to switch to the UI thread. I THINK that if a VI itself is running in the UI thread that they are then equivalent. Nothing beats using the FPTerminal.[*]If you only need data storage and not data display, instead of a local variable, consider using a Data Value Reference, new in LV 2009. This is something that came up after release as a possible use after LV 2009 was released, and I don't know of any benchmarks comparing the two. I THINK that for a large array, the mutex overhead of the DVR will be less than the copy overhead of the local variable. But that's just a hypothesis. The "anxious deallocate" primitive can more often than not slow your performance more than the copy overhead. If your only concern is memory overhead, not speed, you might benefit from using it. Maybe. My recommendation is that you put it in a Case Structure and only invoke it if the array on your diagram is greater than size N where N is some large number that is rarely reached.

Sorry, McKman... the Value property does make a copy of the data for the wire. Otherwise after you read the value, if someone modified the value on the front panel, your block diagram would suddenly have a whole new value, right in the middle of execution. That would be very very bad. The difference between local variable and property value is the UI thread swapping, as mentioned by others.

Any control represents as many as 5 copies of the data. Default value -- the value of the control by default. Operate value -- the currently displayed value of the control. Execute value -- the value actually in the FPTerminal. This may update several times before the data is passed to the control itself unless Synchronous Display is enabled. Transfer value -- the value last moved from the FPTerminal to the Operate data. The transfer data copy is made by the executing thread so that the execution isn't locked by a transfer to the UI thread. Can't copy directly to Operate data since the UI might be in the middle of a redraw when the transfer occurs. Extra value -- created only when VI Server Value property or a local variable gets involved trying to copy the data back out of the control. The comments here are talking about the extra data.

Only one undo? No. In fact, LV 2009 increased the default undo size from 8 to 30. Works well on my machine, both my PC at work and my Mac laptop.

Mark: The problem of single access to data is not a problem for OO to solve. It is a problem whether your data is a LV object, an array, a cluster or just a lonely integer. The DVRs are an excellent tool in that toolbox, and they are what you should use for many "parallel access to the same data" type of problems. LV2-style globals are another such solution. Both of these are options with relative pros and cons. I'm not sure that we've found a truly "good" solution to the problem at this point -- and by "we" I mean the LabVIEW community including LV R&D and all of our users. I helped with the work on the DVR feature of LV, and I think it is a useful tool. But I think it has to be "use these when all else is a worse" solution, not a "this is the first thing you should reach for" solution. As I have said many times in the past: LV needs references. There are things you cannot achieve without references. But you should still avoid using references!

My team is very glad that Jan and Mikael stuck with us. The GOOP Developer Toolkit is a very nice extension to the LabVIEW environment. We appreciate the effort they have put into this tool.

Someday we'll be able to get the data view mechanism working so you can see the values of those constants (and default/operate values of controls and indicators). Unfortunately, that feature keeps getting pushed back for a long list of reasons, not the least of which is it is hard to make usable.

The singleton pattern is one folks have talked about a lot on this forum and others. I keep coming back to the thought that a singleton object in LabVIEW is simply an LV2-style global (aka uninitialized shift register) with some defined operations. It is mutex safe, optimized for dataflow, and easily written. With some clever expansions to how you pass parameters (i.e., operations as class objects instead of raw data), you can make a very robust singleton object without defining a class specific to the singleton data itself. And you can find all the places where it is being used, a trickier proposition with the DVR solution. I recognize that the infastructure that you have to put around an LV2-style global is heavier than many of us would like, but that's in some ways more of an editor problem than a language problem. We made a big deal of building a singleton object example that ships with LV, mostly because everyone expected us to have a solution there, but over time, I have become less satisfied with that answer. The concept of "singleton" means "pointing all operations to a particular address in memory." In a dataflow language, that can be better optimized and (hopefully) better implemented by centralizing calls to a particular set of wires, not pointing many different bunches of wires at the same data.

There are interfaces that have methods that are combinations of several other methods on the interface. An interface might expose a DoThis and a DoThat method and a third method that takes a boolean parameter called DoOneOrTheOther. Just an example. In that case the interface still doesn't have any knowledge of the particular class, but it does provide an algorithm as part of itself that takes advantage of the rest of the interface.Which brings me to another thought I've been having about interfaces... the possibility that an interface could declare a private method and expose a public method that uses that private method as part of an algorithm. There are cases where I, as the person implementing the interface, need to write some function that the class must expose in order to plug into some algorithm, but the function itself is one that should never be called except by the algorithm. I know... I'm questioning all sorts of basic assumptions about "what constitutes an interface." But that's my job as a language designer. Just because it works like XYZ in C# or Java doesn't mean that it is how it should be implemented, either in languages in general or in LV specifically. This is a topic on which I'll be playing for a long while yet.

None of the patterns documented in the document change a lick with the introduction of DVRs. Some of the other patterns from the Gang Of Four book might be more directly implementable, but they (generally) remain undesirable as any use of references in a dataflow program is subject to severe negatives, especially since most of the needs that the patterns serve can be done without references. I would hesitate -- strongly -- to call any pattern that uses DVRs "cannonical" unless/until it can be demonstrated that no dataflow solution exists.

You don't. The only mechanism is to run the VI.

Private methods on interfaces can implement parts of the interface and are quite useful.

What is a tabbed menu?

You are correct. It is not your job to keep track of our bugs. Once you file a bug report with us, it's our job to get it fixed. Unfortunately, not every bug that gets filed gets fixed. There's a constant balance between the CAR backlog, fixing CARs for new features, and development of new features. Time available in the development cycle, risk level of the bug's fix, and mutation issues can all keep a bug from getting fixed, sometimes for quite a while. And there are some bugs that eventually reach the point of "it's just not ever getting fixed" simply because the issue is so corner case and requires so much code movement that it's probability of getting fixed falls to zero. Corrupting bugs have highest priority (those that cause you to lose all your work because the VI is saved wrong). Crashing/hanging bugs have next priority. After that is incorrect behavior (doesn't work as documented) and then cosmetic (stray pixels left on the screen, for example). CARs without a known workaround take precedence over those with a workaround. And bugs that occur in the runtime engine take precedence over bugs that occur only in the editor. What the LV Champions have done is create a system for users to prioritize bug fixes. They have the ability to tag bugs as "this is a high priority to us, even though it may not look like a big deal." That helps make sure a bug gets attention that it might otherwise not get because of other seemingly higher priority bugs. The Champions thus have the ability to speak for the community and say, "This needs to be fixed ASAP." Again, even with the ASAP, it can take a time to get a fix right for some bugs, so "ASAP" may not be the next release. There are CARs from many versions ago that are still not fixed. Every release we have a percentage of the CAR backlog that we commit to fixing, and every release we chew through a few more of them. I know it is poor consolation that your particular bug didn't get fixed. All I can say is that we fix many, and we try, through the Known Issues list, to keep you apprised of those we don't.

x

It's definitely NOT going to make 2010. As I said at NI Week... you should expect very few LVOOP features in the next one, possibly two, releases. What we're working on now will take significant time and attention, with little bandwidth to spare in the interim.

He probably just copied the constant from somewhere... the effect won't be any different than if he used a regular LV Object constant -- the center input only cares about the type of the wire, not the value on the wire. Of course, depending upon the value of that constant, you might be creating a dependency on a class that is otherwise unused in the diagram. It'd be better to use a default-value constant.

You'd think so, wouldn't you? The response there has been very different.

Read the documentation on the Event Structure. It was brand new in LV 6.1, and that gives you the tools to do what you're asking.

Your tool makes me both happy and sad, both motivated and depressed. It is nice to see people using classes and using them so much that they write tools to extend them and make them more useful. It's just this particular tool... you see, this used to be in LabVIEW, but it never shipped. First I was told -- by multiple sources -- that using a text display was bad, that it needed to be the icon display or whatever the user had configured in their Tools>>Options for palette displays. Ok, so I made LV build an on-the-fly graphical palette. But then it was shot down because the layout was inconsistent: things in the palette shouldn't move when a new VI is added to the class, but adding new VIs at the end means nothing is ever findable. Can't you make it alphabetical but read my mind and not be alphabetical when I don't want them to be? Shouldn't virtual folders have something to do with it? Why aren't the parent methods folded in? Why are they in sub folders? Shouldn't they be in superfolders? What the heck is a superfolder? Perhaps the palettes should be named in iambic pentameter. Can you make all the icons rhyme? Eventually I went crazy, had a nervous breakdown, and killed the feature. Clearly, anything we did automatically was undesirable. Another member of my team made it so that a .mnu file could be associated with a class so that users could define their own layout for the VIs. I've never felt like revisiting the issue. I commend your work on this feature. I am surprised this thread is not full of people complaining about how useless it is.

URL isn't quite right in the link. Here's the fixed link: http://expressionflow.com/2009/09/15/limits-of-for-loop-parallelism-how-parallel-they-really-execute/