Aristos Queue

I write a new post. The WYSIWYG editor shows this: But when I actually post the topic, it shows up like this: Notice that the blank lines preceding and following the list are missing.

Wow. I think you've created a situation I never expected anyone to construct. The answer to your question is easy, but you make me think we ought to kill the functionality you're taking advantage of. And, more than what we (LV R&D) ought to do about it, I really want to know why the heck you are in this situation! Short answer: The Call Parent Method always calls the ancestor implementation of the VI. It does not care about the type of the object on the wire. So Call Parent Method on the block diagram of B:M.vi will always call A:M.vi. Long answer: Somehow you have an instance of D on a diagram of B:M.vi and you are passing that D object to the Call Parent Method node. How did you get this instance of D on the diagram of B:M.vi? Here is how I would have expected that it got there: Top level VI is "Caller.vi" Caller.vi has an instance of D on its diagram Caller.vi makes a dynamic dispatch call to M.vi, which dispatches to D:M.vi. D:M.vi uses the Call Parent Method to invoke C:M.vi. C:M.vi uses the Call Parent Method to invoke B:M.vi. And now you are asking what the behavior will be when B:M.vi uses Call Parent Method, and the answer is A:M.vi. Now, that's what I would have expected. Your question implies that something like this happened: Top level VI is "Caller.vi" Caller.vi has an instance of B on its diagram. Caller.vi makes a dynamic dispatch call to M.vi, which dispatches to B:M.vi. On the diagram of B:M.vi, you somehow obtain an object of type D, either from a diagram constant directly on the diagram or retrieving this D object from some data store (global variable, queue, etc, or maybe just by unbundling data stored in the B object). And now you propose to wire that D object to the Call Parent Method. Please tell me that is NOT what you are doing. It sounds like it is, but it shouldn't be happening. There should never be a reason why you would ever want to do this. If you directly pass that D to the Call Parent Method, you are destroying the data integrity of your D object. Any object assumes that if it provides an override of any method then the ancestor method will never act on that object unless it was because the overriding VI used the Call Parent Method to invoke it. I and my team never discussed this case. The fix for the LV compiler is obvious and easy -- the dynamic dispatch input terminal of the Call Parent Method should only accept wires that propagate down from the dynamic dispatch input of the invoking VI. In other words, only the wires that have the gray background should be able to wire to the dynamic dispatch input of the Call Parent Method, and the VI should be broken if anything else is wired. That is not enforced today, mostly because it never occurred to anyone that you might ever try something like this. I could be completely off base in my understanding of what you're asking. But if I've hit the nail on the head, can you please explain *why* you are passing this D object to the Call Parent Method without climbing up through the hierarchy, starting at D:M.vi? If there's a real-world use case for this, I am going to be absolutely stunned. My bet is that you're just creating a situation in which D is not being updated correctly. Now, it is legit to have this situation (steps 1 to 4 are identical to the previous steps): Top level VI is "Caller.vi" Caller.vi has an instance of B on its diagram. Caller.vi makes a dynamic dispatch call to M.vi, which dispatches to B:M.vi. On the diagram of B:M.vi, you somehow obtain an object of type D, either from a diagram constant directly on the diagram or retrieving this D object from some data store (global variable, queue, etc, or maybe just by unbundling data stored in the B object). You make a new dynamic dispatch call to M.vi, passing the D object as the dynamic dispatch input. This will call out to D:M.vi and may eventually make a recursive call into B:M.vi, if all of the override VIs keep invoking the Call Parent Method. This eventually results in a recursive call to B:M.vi, which will either panic stop if the VI is not reentrant or will allow the recursion if the VI is reentrant. You'd need in that case to make sure that B:M.vi is written such that infinite recursion does not occur. Does this sound more like what you're intending to write?

I don't think it has anything to do with data copies. I'll bet it is just the time needed to do the thread swapping. If you are "same as caller", then the same execution thread can run the subVI and you can just keep working. If you force a change of execution systems, the VI has to stop, put itself back on the run queue, and wait for a thread from the chosen execution system to come along to execute the subVI. Then it has to go back on to the execution queue to switch back when returning.

Place it outside of the loop. There is a square on the border of the loop where the wire crosses from inside to outside. That's called a tunnel. Pop up on the tunnel and select "Enable Indexing". The result will be an array of your data, each element of the array being one iteration of the loop. You can then write the entire array to disk.

I put in a request to up the priority of getting it fixed.

Use the Type Cast primitive to cast your strings to an array of uInt8. Then you can compare each element.

Those VIs are just a way of declaring instructions for what to script. They do not constitute a save format at all.

Actually, it is a standard design pattern in LabVIEW. NI has presented it in many places. Most recently, it was in the spring 2009 Developer Days conference presentations for "Design Patterns in LabVIEW." The slides are here.

In fact, that's the entire point. :-)

VI Analyzer has a test that looks for this.

You joined at a good time. The whole site crashed last month and had to be rebuilt from backups and along the way got a MAJOR facelift, so everyone on the forums is "finding their way around" right now. So if you find any good tricks that others don't seem to be taking advantage of, do flag them on the Site Feedback forum! We could all use helpful tips in this brave new world. ;-)

I thought the whole point of being a contractor is that you could get your assignment and then go off and do it... and if that means writing code while you're sitting in the Austin Convention Center between sessions, so be it. I take it your particular contract precludes such untethered work?

Done! There's been an OO training course available for a year now. Ask your local sales engineer to sign you up! We have a really really really good Fundamentals of OO document that is part of LabVIEW's online help -- and has been since we first released in LV 8.2... the tech writer won awards for that bit of documentation. It is both a "why should I do this" and a "how do I do this" manual. Online, we have the LVOOP FAQ and the Details Behind The Design documents, both of which have been updated for each LV release. The Design Patterns document on the community forums was developed specifically to bridge text programmers into LabVOOP. Go ye forth and learn! :-)

Steve Rogers says 1992.

Every item added to the error code cluster is a MAJOR increase in the size of every VI's memory footprint. I'd rather see a single Variant and have all of these be attributes of that variant. The allocation space in VIs would be SUBSTANTIALLY less. (Assuming you stay as a cluster... if it becomes an object, well, load it up as much as you want... the top level data size is just one pointer.)

Not only is there NOT an advantage to the first over the second, there's a substantial advantage to the second over the first: Because LV knows exactly which VI will be invoked in the subVI model when the caller is compiled, we are able to do a better job reducing data copies*. Technically, we know which VI will be invoked in the second, but the compiler hasn't started constant folding such items at this time, mostly because the Call By Ref is generally not called with such static conditions, and spending time recognizing that diagram setup and optimizing it has been too much of a corner case to spend time on it given that users usually go directly for the solution of "just drop the subVI" in cases where we could apply the optimization. * The next version of LV will improve the situation some, but there will still be overhead to the CBR compared to the subVI direct.

If you have Alpha.vi that calls Beta.vi and you are running Alpha.vi, you cannot use the Run method on Beta.vi. A VI cannot simultaneously be both a top-level VI and a subVI. (A VI can be a subVI of two different top-level VIs.) I believe that if you make the VI reentrant and then in Open VI Reference you set the Options input to give you a new reentrant clone that then you can call Run on the reentrant clone.

You may have heard of the scripting method "Read Linker Info"... people ask about it from time to time on the forums. The path information of a LV file can be extracted from the file without loading the VI itself into memory. The linker info for various VIs is cached between runs of LabVIEW to accelerate the population of the dependency information.

That had the trick of it. Thanks, Yair. Here's the VI I built from the pieces (saved in LV 8.5): Scale Picture String Image.vi

I do not generally promise future features, but last year at NI Week, for the first time on any topic, I went so far as to say that classes would be on RT in the next version of LabVIEW even if that meant trying to hold up the entire LV release until it was ready. I can't say anything further except to say that I'm spending this week writing NI Week presentations, not working on LV features. ;-)

I'm a bit busy putting together NI Week presentations about OO features at the moment, but if I get time next week, I'll try to write up a big summary document of queues and notifiers, pulling together all the various parts I've posted over the years.

Can anyone point me toward a VI that given a picture string and a scale factor returns a picture string of the image scaled by that amount?

Both assumptions are correct, but there is something you can do with respect to assumption #1 depending upon your particular queue.Suppose you have a queue of arrays of 32-bit integers. The queue is filled by 20 arrays each of 100 elements. If you flush the queue, the queue will simply note that its current buffer index is zero and the length is zero, but no elements will actually be deallocated. No help there. But if you flush the queue and then enqueue 20 empty arrays, the bigger arrays in the queue buffer will be deallocated, giving you a bit over 400 bytes of memory back, but the queue buffer itself, 20x(size of pointer [4 bytes on 32 bit machine]), won't be deallocated unless the queue is destroyed.

Congratulations!

My opinion: All applications can be designed as every VI is a member of some class. Not all (but still most) applications can be implemented with every VI as a member of some class. Sometimes the class is too much overhead to actually translate the class in the design into an actual class in the implementation. But it works for most applications, and it turned out to work for the CLD exam question. Indeed, all three (1, 2, 3) of the sample questions for the CLD appear to be in the set of apps that are amenable to full OO implementation. The exercise I posted that was purely theoretical was that all data crossing any conpane boundary can be a class.