Aristos Queue

Are there specific examples of typical by-ref designs being converted into a by-val design?

None that aren't proprietary. But the effect is something we see commonly: an object that is essentially nothing more than a cluster, like, perhaps, a block of configuration data for some hardware, is passed around as a reference, being looked up from the ref each time a node needs data from that cluster instead of wiring the cluster through to all the subVIs by value.

* and it will be bug free by that time.

Ah, come on... admit it... you folks would be bored out of your minds if we didn't include at least a few bugs for you to work around... ;-)

New Parents:

In between changing diapers and cleaning burp rags, take a moment to consider your child's future. Will your little one be able to make it in the rough and tumble world of the future? Yes, but only if you provide the right tools. And what could be more important to your child's future than LabVIEW? Sure, you could make a couple extra house payments, but will that help your child's education? No. Good parents know that a child's work prospects depend on a fully licensed copy of LabVIEW. You can help them out tomorrow by your actions today! Just start sending annual checks in the amount of $3000 every year to "National Instruments." We'll hold onto those funds for you and when your child is old enough to need their own block diagrams, you'll have built up a tidy nest egg, which NI will generously apply to the annual Software Subscription Package. If you make this easy payment of just $250 each month, by the time your child is 18, you'll likely have enough saved for them to have six or even seven years of LabVIEW enjoyment*, more than enough time for them to establish themselves in the industry. Act now, and you can also establish separate trust funds for your child's TestStand, Diadem and MeasurementStudio!

Why would you wait? Even while you think about the value of this offer, your child is getting older. Start sending those checks today!*

* accounting for likely increases in SSP cost

** This message not endorsed by NI, its affiliates or my managers

*** Congratulations, Jim!

I would of cause not even consider by value unless I really needed the highest speed.

I on the other hand would not even consider a reference solution unless all else failed.

My solution: Give your ListOfPigs class a method called UpdateOnePig, which takes an index of a pig and instructions on what to do to that pig. The instructions can come in the form of parameters that you pass into the ListOfPigs' VI or a VI Reference that you call. The block diagram of the UpdateOnePig has an InplaceElementStructure that has an Index and Replace array node on it.

• You change the inplaceness of data that goes through the subVI.

If you change the inplaceness of a subVI, the caller VI will be broken when it loads. The caller VI checks that subVIs have the expected inplaceness and breaks unless it matches the inplaceness the caller was compiled to expect.

For inserting an object's UI into a subpanel, I have used the reverse approach successfully - I have a DD VI that accepts a reference to a subpanel called something like "Insert UI", then its up to the individual class to decide what VI gets inserted and give the opportunity for the class to do any housekeeping before actually displaying its UI to a user.

Excellent strategy. This isn't formally documented as a pattern but probably should be.

I think for detecting Is Sibling you're going to have to add framework VIs. I can't think of any way to do what you're asking with built-in functionality.

I'm so proud of the little Equals prim. You know, I taught it everything it knows. ;-)

Has this been added to the idea exchange? I looked and couldn't find it.

Yes. Here:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Insert-class-VI-contextual-menu/idi-p/996055#A2548

Write a static dispatch VI -- it does NOT have to be a member of the class, assuming the dyn disp VI you're trying to invoke is public -- that has the same conpane as the dynamic dispatch VI except that the terminals aren't dynamic. Have the static dispatch VI call the dynamic and then use OpenVIRef to open ref to the static dispatch VI.

The recovery system autosaves every 5 minutes.

I was surprised at how different the runtimes were given that the queue contained a cluster of 4 scalars. I didn't think that copy that would be a very big deal. I guess all things are relative when you're talking about 1e-4 vs. 1e-5 ms.

Everything counts in large amounts...

As I understand it, a preview element always makes a copy of the element data, but a properly used dequeue-enqueue implementation can be made inline.

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).

We're getting totally off topic here, but what would happen if the property node did ignore errors? Would the error output be the error input? Would errors that occured in the property node be merged? Wuold this be extended to VIs and primatives (and other things too)? Of so, how would they be handled? I agree that it *could* be useful, but I think what we have is intuative and works fine.

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.

I understand LV makes 2 copies of FP controls, but why isn't it reusing the copy that's there not doing anything else?

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.

1. 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."
2. A VI's panel is loaded if
   1. It's front panel is actually open
   2. There are any local variables or any statically-linked property nodes on its block diagram
   3. Someone has obtained a control reference to any control on the panel or to the panel itself
   4. The VI has unsaved changes (the panel is kept in memory until you save the VI)
   5. 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.

I'm thinking the transfer buffer is the extra copy.

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.

Techie,

I believe the benefit of the "property node value" is that it does not require a copy of the data to be made in memory like a "local variable" would. From what I understand LabVIEW keeps a copy of the data for each local variable in the code. So if my code occasionally updating a front panel graph that has a lot of data, I use a property node since speed is not an issue and I don't want to eat up memory with multiple copies of data. But if I wanted to quickly update a front panel graph with small amounts of data, I would use a local variable. Where is the break even point? I don't know. You can always test it out if you want to find the optimum choice.

Mark

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.

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!

I am sorry you had to wait for the release but we had a few issues with the LV 2009.

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.

Exactly, and when I take over the project 6 months later...

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.

I was mainly thinking of singleton that is, in C++, implemented by a static pointer. I figured that we could do the same in LabVIEW with a ref stored in a private fonctional global. But I understand your arguments.

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.