LAVA 1.0 Content

QUOTE (crelf @ Jun 10 2008, 08:33 PM)

...

One word: http://www.langmaker.com/calculatorwords.htm' rel='nofollow' target="_blank">5318008

"SHIBBOLETH" It took me a couple of minutes to remember were I heard that word before. It was the Old Testament version of a sign I spotted in a Simpson episode that read;

"Noone who uses the word NUCULAR permitted beyond this point."

Ben

I want to be able to update a picture control that represent a set of objects using a "update" method in one loop while handling user events for those same objects in another loop.

I slapped together an action engine that uses a SR to store an array of the objects and then added actions that corespond to the methods. So far it seems to work fine but I have to ask;

"Am I defeating the purpose and intent of LVOOP by using an Action Engine to store the LVOOP objects?"

I ask because I have often read LVOOP as being an alternative to AE's and am concerned I am failing to get the whole LVOOP idea and am "just putting lipstick on a pig".

Your thoughts?

Ben

QUOTE (crelf @ Jun 11 2008, 03:30 PM)

I think that's an excellent idea.

Some cleaning over the week-end and off we go !

QUOTE (neB)

Ohh, ok... Then I hope you'll have time to participate in the improvement/developpement when it starts

QUOTE (Antoine @ Jun 11 2008, 09:18 AM)

With the aim of sharing it on LAVA's Code Repository ?

...

Don't hold your breath. Those kind of things only get developed in my spare time and between re-modeling of my rental property, plus a modular home my son is purchasing, along with car maitenance, I will not be dropping any nodes for that project until well after the snow starts to fly.

Ben

QUOTE (neB @ Jun 11 2008, 03:02 PM)

A high capacity chart/graph and tables are on my list of XControls to write.

With the aim of sharing it on LAVA's Code Repository ?

QUOTE (neB @ Jun 11 2008, 03:02 PM)

Thanks for the link to this article. Interesting code attached !! I haven't been that far

QUOTE (Antoine @ Jun 11 2008, 02:21 AM)

LOL

It really does, I've been working on a set of VIs to efficiently -well as efficiently as I could- manage large data sets to be displayed on a graph.

I'll share what I came up with. I guess the amount of work to wrap this into an xcontrol is not huge..

I was concidering putting a OpenG package request on this, and share my code as a starting point. Has anyone been working on this too ?

A high capacity chart/graph and tables are on my list of XControls to write.

Dr. Gray's article on http://zone.ni.com/devzone/cda/tut/p/id/3625' target="_blank">Managing Large Data Sets would be incorporated in to same.

Ben

QUOTE (FLAnatic @ Jun 10 2008, 08:21 PM)

I was actually really into this and was hoping to solve all of the problems at some point. I've solved 90 of them but haven't visited in several months. Most of my solutions have been using c++ although I did solve the pathfinding problems using LabVIEW.

Wow... 90, well done !

I've got 20 (all in LabVIEW since it is the only language I know) at the moment but I won't stay here, it's great fun !

QUOTE (crelf @ Jun 11 2008, 02:38 AM)

(yes, there's a flood of posts from me in the last few minutes - I just got off a plane after an 11 hour trip and I need my LAVA fix.)

LOL

QUOTE (crelf @ Jun 11 2008, 02:38 AM)

It really does, I've been working on a set of VIs to efficiently -well as efficiently as I could- manage large data sets to be displayed on a graph.

I'll share what I came up with. I guess the amount of work to wrap this into an xcontrol is not huge..

I was concidering putting a OpenG package request on this, and share my code as a starting point. Has anyone been working on this too ?

QUOTE (Eugen Graf @ Jun 10 2008, 11:06 PM)

Hello LAVAs,

I have a big table 25 Columns and about 800000 Raws and user can select which column(s) he want to plot. My plot VI is always the same, I configured it as reentrant and start it using Invoke Node. I did Dispose Ref as True and hope if one clone will be closed, than used memory will be deallokated.

Thank you

Hi,

I don't really know how graph memory is handled but anway my best advice is : do not put 800k values, just put about 5-10 values per pixel (-> check the graph area size). I've saved a lot of memory with this technique.

Hope this can help.

QUOTE (Eugen Graf @ Jun 10 2008, 09:44 AM)

Thank you Ben for links.

...

The problem is, that this data is not only duplicated, much more the problem is the table with data

....

Not easy to handle this big dataset, so it's realy necessary to reduce the memory usage.

Too many issues for me to address all durring a break!

For tables makes sure you are using LV 8.5 or above. Older versions had slower tables. "Defer FP updates" before updating tables usally helps.

Action Enginces are great for situations were the same large set of data is accessed in different ways for different functions. Just make sure you "work in-place" as much as possible.

have fun!

Ben

QUOTE (Aristos Queue @ Jun 9 2008, 06:56 PM)

VIs that use dynamic dispatching can be public or protected, but not private.

This is one of those decisions that could have been made either way and really comes down to my team's philosophy of design. There are good arguments on both sides (and, in fact, C++ made the opposite decision and allows private virtual). Our reasoning goes like this:

A VI marked as "private" is contracted to never be called outside of the class.

A dynamic dispatch subVI call chooses at runtime which of several VIs to actually invoke. Each of those VIs is at a different level of the hierarchy.

There's no way for the contract of "private" to be kept if you allow dynamic dispatching to work -- somewhere there must be a caller that is not inside the class that is invoking the method, and thus is occassionally dispatching ot another level of the class.

C++ made the opposite decision, under the argument that "private" for a virtual (aka dynamic dispatching) function means "only the parent class can call this method set, but each level of the hierarchy is free to define the behavior for that private call".

Neither decision is wrong, but, in my not-so-humble opinion, one is a lot easier to explain to folks.

Thanks in advance* for that reply!

I am working my way through all of the documentation I could find on LVOOP. The above question came up as I was moving from page 3 to page 4 of the http://zone.ni.com/reference/en-XX/help/371361D-01/lvconcepts/creating_classes/' target="_blank">Creating LabVIEW Classes article.

The LAVA Wiki articles are next in my stack of print-outs.

Ben

* Thanks in advance since it will take me some time to fully conceptualize the reply.

Hi Eugen,

You are trying hard so let me help out a little.

In this link you will find my collection of "LabVIEW_Performance" tags. You will find a lot of postings by Greg McKaskle in that list since I am working my way through the forum chronologically.

One of those links (this one) has been called teh "Clear as mud" thread but it illustrates what Aristos Queue was talking about.

Ben

QUOTE (tcplomp @ Jun 10 2008, 12:07 AM)

So how do Ben's initial programs look like?

Ton

They bear a strong resemblence to ones and zeros floating randomly off into that big bit bucket in the sky.

Sea Story Time: (I don't think I have shared this one on LAVA yet)

I used to work as district support for DEC specializing in large disk drives. After spending an evening working with a customer to recover (well sorta) from a disk crash, one of the engineers described his adventures as follows;

"

After rebuilding the drive and running diagonstics the drive looked OK. So we put the customers backup pack in the drive and it mounted fine. We were standing behind the disk drive cabinet and we noticed what looked like a cloud of fine brown dust coming out of the back of the drive.

The customer looked at me and asked "What is that?"

I replied, "Data".

"

Story orignally told by Bill Thomas of Digital Equipment Corporation.

Ben

QUOTE (TobyD @ Jun 9 2008, 10:59 PM)

This is fun stuff. Thanks for posting the link. I'm up to number 9! WooHoo!

I requested that it be added when I signed up and right away the admin replied that he had added it. He said something about me getting my friends to request it as well so he must have received more than one email

I did ask for it, but I didn't receive the mail form the admin :thumbdown:

Altough I can not prove it, I believe VI's are better the second time I write them.

Ben

QUOTE (Omar Mussa @ Jun 9 2008, 03:46 PM)

... This is a desired/expected behavior. You wouldn't expect private VIs to allow ancestors to override them.

Thank you Omar!

OK I'll trust you on it being expected. Now I I have to do is figure what ancestors are and and what override means.

Ben

PS: please excuse my dumb questions on LVOOP. I have been reading and I'm trying but OO is still a forign language. Learning the machine instruction set of a KL-10 seems easy to getting this old hardware guys head around the terminology.

Why does changing the scope of a VI within a class to "private" break the class?

In the attached zip you will find a folder complete with project and required files.

I started by defining a generic class and then create accessor (?) for all of the values in the class.

Whenever I set any of the VI within that class scope to "private" the class breaks (they all dynamic).

So how do I set a accessor(?) as private?

Not knowing LVOOP I was guessing that I keep everything private and only make protected or public what I absolutely needs to expose. I have to admit I am a complete loss as to what I am doing wrong.

[Edit] Are there rules about dynamic dispatch and private not going together?

[Edit again] After creating a new project blah blah blah, I manually set connectors as required and issue went away. So private and dynamic do not mix. I am not sure exactly what dynamic really means (I thought it was a way to let LV choose a polymorphic instance at run time) but I am not sure what that has to do with breaking when it is made private.

Ben

feeling very LVOOP stupid at this point.

QUOTE (Aristos Queue @ Jun 9 2008, 11:25 AM)

More exactly, the *act* of copying data can be considered a node. Wires are data. Nodes are actions. Specifically, nodes are actions on that data.

But not all branches are data copies. Ex: Get array size (does not mod data) can be scheduled before array is used.

Ben

QUOTE (ragglefrock @ Jun 9 2008, 11:08 AM)

I don't think that's a valid test. You're opening two references to the queue, so even if you stop one of the VIs and let it go idle (or even close it), you still have a top-level VI running that has a reference to the queue.

I couldn't manage to create a VI that failed, but I believe the danger is if you only use Obtain Queue once from a VI that eventually goes idle, then that queue reference won't stay valid in other parts of the program that continue running after the VI that created the queue goes idle. But again, I tried to reproduce this and was unable...

Notes on how I got the queue to fail in LV 6.1

The VI that created the queue was a top level VI that was only loaded into memory when the Windows machine opened it. The top level VI was an action engine where the first action was "Init" creating the queue". Latter calls invoked other actions including reading from the queue. When the ref to the top (crator) went invalid due to network timeout, the queue went invalid.

At least that is what my memory tells me.

Ben

QUOTE (JiMM @ Jun 6 2008, 03:51 AM)

Holy Mackerel! I am stunned by how fast the Coding Chalenge winner did this. Of course it was obvious that clever math tactics would be necessary to minimize time, but .... just WOW. I got less than 1ms with that VI on my PC. AMAZING! :worship: I am not worthy!!!!!!

I had a quick look at your VI "IsPrime.vi", one thing you can improve is the number of time you run the loop to see if the tested number is prime ; it's no use to test a prime divisor if it is bigger than the square root of the tested number

EDIT :

My solution takes less than 2 secondes on my old laptop and it is not really different rom yours .

A few other advices to improve performance :

- avoid to use "build array" primitive,

- avoid cohersion dots,

- inline code.

One interesting hit I found, in my solution there is one subVI, if I inline the code to have only one VI, it runs faster ~10% ; I guess this is due to the way LabVIEW passes inputs to callees and outputs to callers.

Here is one appropriate for a Friday afternoon.

Image on NASA web site shows water on mars.

http://apod.nasa.gov/apod/image/0504/WaterOnMars2_gcc.jpg

Ben

QUOTE (rolfk @ Jun 6 2008, 01:31 AM)

Actually I think the Call By Reference call will handle arbitration nicely so if you can provide VIs with atomic access to a particular queue you should be fine.

Rolf Kalbermatter

One subtle note of caution:

Make sure the queue is not created by the VI that is the target of the CBR. If the connection fails and the target VI is not active in any other running code, LV will clean-up the resource of that VI including the queue it created. This means your queue would go invalid when a network interuption occurs. (This was observed in LV 6.1 with the queue running on a cFP running RT).

Ben

QUOTE (Justin Goeres @ Jun 5 2008, 09:41 AM)

http://forums.lavag.org/member-list.html' target="_blank">Members is showing a blank page again this morning. It was OK yesterday.

Well now that you mention it, same thing with the Top 20.

Ben

QUOTE (Phillip Brooks @ Jun 5 2008, 07:35 AM)

...

(All your VIs is belong to us.)

Only the ones you post to the Dark-Side (or at least that is how I read the EULA).

I never get any phone calls from NI but that could be for a number of reasons.

1) I have a "Gate-Keeper" that screens my calls.

2) All of the NI training in our region are taught by us and the Training Coordinator is generally more interested in why I refuse to take any of the candy from the office candy jar (even after she purchased Mint Three Musketeers!) (BTW: She tracks what courses students have taken and only offers the next class in the series).

Ben

QUOTE (Jim Kring @ Jun 5 2008, 09:29 AM)

I took an online sample CLAD exam, recently, as a favor to someone at NI who wanted some feedback from advanced users. After I completed the exam, I started getting lots of emails from NI recommending that I sign up for LabVIEW training (even though I already have a CLA and other LabVIEW credentials). It's great that NI is giving us a personalized relationship with them, but if they don't put any effort into making it smart, then it's going harm more than it helps. :headbang:

are you sure that you did't get those LabVIEW training mails because of your CLAD test result