Aristos Queue

I think there is a world of knowledge and possiblities in OO in LV. Just look at all the different implementations (by reference, by value, LVOOP, GOOP, Endevo, etc., etc. ). The whole topic is overwhelming and a little intimidating. Some of us are still a little too nervous to jump right in simply due to the number of choices. I think it would be good if NI took the lead (hint hint) and really worked on some training material in OO programming and the native LV OO implementation.

Done!

1. There's been an OO training course available for a year now. Ask your local sales engineer to sign you up!
2. 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.
3. Online, we have the LVOOP FAQ and the Details Behind The Design documents, both of which have been updated for each LV release.
4. The Design Patterns document on the community forums was developed specifically to bridge text programmers into LabVOOP.

Go ye forth and learn! :-)

Anyone out there know when LV 2.5.2 came out? I need the info for the "It's all about me" page here on LAVA. I've done some searching and turned up a sorta date for 2.5, but nothing for 2.5.2.

Steve Rogers says 1992.

(Just in case I'm missing something... is there any advantage to using the first method as shown over calling the vi directly?)

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.

If non-library vis in a project aren't loaded when the project is loaded, how does LV populate the Dependencies section with its non-project sub vis?

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

Great! When will native OO be available for cRIO? I am currently using 8.6.

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?

So, I'm assuming: 1) just flushing the queue isn't going to deallocate the memory, and 2) destroying the queue will deallocate the memory.

Are both of these assumptions correct?

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!

I know you had mentioned this kind of thing before on the NI site (All VIs are objects) but I thought even you referred to it as a theoretical exercise at the time. Now I really want to see your code......

Makes me very curious as to the question and answer.....

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.

You were being worked on by who?

*grin* I should clarify... the biggest *software* time sink is being worked on.

That's a *great* idea! I would *soooooo* buy that! What do you think Stephen?

I think I'm having a hard time finding enough time to get my NI Week presentation written. I would like to do a book sort of thing, but I suspect that the design patterns and the "decisions behind the design" docs are about as large as I'll ever bite off in a single chunk.

Is it possible to view a VI that was created on previous versions of LV(e.g. LV3.1) with L.V7.1? I have VI s I wish to see that were created on older versions than L.V7.1

You need LV 4.0 or 5.0 to be able to read the 3.1 VI. LV 6 and later cannot read anything before 4. Someone on NI.com can probably load the VI in 4.0 and save it for you if you can share the VI with them.

Once a queue grabs space, it does not deallocate it. That is intended, designed behavior.

When I said in my previous post that I'd comment more about it in a couple weeks, this is what I meant.

Tab controls have a fixed number of pages compiled into them. If you're not working in the development environment, you cannot add more pages. And even if you are in the dev environment, you cannot add more pages while the VI in question is reserved for run.

The only workaround I can think of might not be too appealing: You could drop a picture control and draw your own tabs. (Note that Norm's alternative is a better solution generally... I was just trying to workaround the "you need tabs" problem, not solve the wider UI issue...)

Ok. I have figured out how the "View New Content" page works... and I like it. It is very good. But I would like a way to wipe it.

When I visit a particular forum, I can click the "Mark as read" link that will flag every topic in that forum as read by me. That removes those topics from my View New Content page. What I would like is to have that same link on the View New Content page so that I can look at a list of topics, respond to the ones I'm interested in, and then mark the others as read so they stop showing up in my View New Content list.

This isn't a bug, but it is a feature I'd like to see added.

After running the application the program occupying the most of the system memory.

After running --- by this I assume you mean that the VI has come to a complete stop and yet lots of memory is still being used. If the VI is still running, there are lots of things that could be taking up memory that we could talk about. But after a VI finishes, here's the list:

1. You could simply have a very large VI hierarchy. When you load the VIs into memory for the first time, look at how much memory is being used. It could be that it is already using lots of memory. That probably isn't your problem -- it takes a lot of VIs to make an impact like that, but I have seen some apps get big enough that their raw code size is huge.
2. When the VI finishes running, what front panels are open? Every open front panel will store data in its controls/indicators. If you have lots of panels open and a giant array or a long long long string gets passed through those VIs while the VI is running, every single control/indicator that shows the array/string will have stored a copy of that array/string as part of its display.
3. The dataspaces of VIs expand to contain the data that passes through them (large arrays, large strings), just like the front panel, and LV does not deallocate that space on the assumption that if you're leaving the VI open, you are probably going to run the VI again and the second execution will be faster because memory is already allocated for data of that size. You can use Tools>>Profile to see which subVIs are getting to be the largest. Consider dynamically loading and unloading those subVIs --- open the VI that calls the subVI and then pop up on the subVI node call and select "Call Setup...". In the dialog that appears, click "Reload for each call".

Hope that helps.

Here's an example of this sort of thing. I'm assuming the classes there are more complex than what I'm thinking about, but we can't know unless Daklu steps in. In any case, this is exactly the sort of thing I'm concerned about.

I just posted a reply in the ni.com thread.

Thanks for the explanation, Yair. I hadn't clued into that change.

It appears that when I click "View New Content", the list that gets displayed is all the posts that have been made to LAVA NOT including my own posts. Although I can imagine someone thinking this is a good feature, for me it means I have to know where in the "new content" list to stop reading. My posts being in that list are a good indication that everything prior to that point is stuff I have already read/skimmed.