LAVA 1.0 Content

I remembered reading this BLOG entry some time ago. It may be worth a read.... Note his last comment: "If you're a student of computer architecture or parallel programming (as I once was), always pay attention to the overhead of distributing your workload because it may swamp any savings you hope to gain."

My guess: IE ~ 45% FF ~ 50% Other ~ 5%

Hi! Current processors have multiple cores and therefore taking advantage of parallel computation has become more important. Even though LV is highly parallel programming language, it still lacks parallel looping. I'd like to suggest a new LV structure, namely "parallel loop" that would evaluate the content of the loop in parallel and not sequentially as current loops do. The parallel loop would be a variant of "for-loop". When the parallel loop structure is encountered, LV would execute multiple parallel diagrams with the loop content instead of executing the loop itself. The parallel loop would not have shift registers but it would be otherwise similar to current "for-loop" from the programmers point of view. The following image emphasises how the evaluation of an expression would be really done using parallel loop.

Perhaps I can fix it if NI hires me with good enough salary

... how about WabVIEW? uh-hah-hah-hah

You just need to right click the red-underlined word and add it to your personal dictionary. Your last name "Ashe" has a red underline and offers me five alternate spellings. I will add your spelling to my dictionary

No, I was just using different notation for the same thing... Instead of writing "Integer.Add(...)" I wrote "Add(dyn Integer,...)", which means exactly the same thing. However I prefer the "dyn" specifier in LabVIEW context as it is closer to LabVIEW implementation of OOP. However, there is no such thing as OOP abuse, if something can be implemented more easily and elegantly using OOP then it should be used. OOP patterns are often oversimplified in many books as the books are often targeted for people learning OOP. For OOP newcomers certain patterns should be discouraged so that these people really learn how to use OOP correctly. After you have passed this stage and know how to use OOP well, then you can begin to "abuse" OOP to achieve more interesteing functionality. If you read Java programming blogs, most advanced users are exactly trying to overcome Java limitations by "abusing" OOP.

Something very very simple indeed. I'm encapsulating numeric data type into a class. But as I know that OOP is all about reusability, I derive my numeric type from a general class Numeric. Numeric is an interface class. It has dynamic methods such as (in pseudocode): Numeric Add(dyn Numeric A, Numeric B) Numeric Negate(dyn Numeric A) Numeric Substract(dyn Numeric A, Numeric B) In all these three methods, terminal A is dynamic dispatch terminal as is the return value terminal. Terminal B is not. Numeric class has an implementation for method Substract that relies on Negate and Add, namely A-B := A+(-B). Since class Numeric is only a interface class, I create one or more implementations of this Numeric class. Let's call one implementation Integer, which implements an unbounded Integer type. So we need to create override methods for Add and Negate. They will look like the following: Integer Add(dyn Integer A, Numeric B) Integer Negate(dyn Integer A) As you can see, we now have a problem with Add, since the inputs are of different class type. But we just want to add A and B of both Integer class. So we need to at runtime typecast B to Integer and return an error if this fails. It would be easier and cleaner to program if we could force both terminals to of Integer class type in this override VI. So I'd like to see the following interface for the Integer class Add method: Integer Add(dyn Integer A, dyn Integer B) So it would be possible to mark multiple input terminals as dynamic dispatch inputs. Then in the override VI, these inputs would not be of parent type but rather of child type. This forces the child class user to connect wires of correct type to the VI and the class developer doesn't need to typecast input B into Integer every time he/she uses this kind of pattern. I hope I made myself clear. I've a habit of thinking that others naturally understand what I mean, which of course is often not the case

Currelty there can be only one dynamic dispatch input terminal in a dynamic VI. If you want to compute for example A+B where both A and B are objects of Numeric class, only either A or B can be a dynamic input terminal and the other must be a regular terminal. It's natural to assume that A+B is computable only if both A and B are of the same subclass of the Numeric class i.e. complex + real cannot be computed togerher but integer + integer can be computed. What I suggest is the following. There could be multiple dynamic dispatch terminals in a VI. However only the first one would be used for dynamic dispatching, no double dispatching would be allowed (not at least in the beginning). The clue is that LV would require at compile time all of the dynamic dispatch terminals to be of the same class type. This doesn't naturally guarantee that the terminals are of the same type at runtime, but makes it much more unlikely. In addition, the LV would add runtime type chekcing code to verify that all the dynamic terminals are of the same class type before executing the VI. If they were not, a runtime error would be generated. This way the VIs could be a little simpler as the user doesn't need to explicitly typecast all the classes to the same class type. The downside is that if a type mismatch runtime error occurs, it's very hard to handle programmatically. Of course the runtime error could be written to error cluster control (not necessarily connected to connector pane) of the VI to allow the VI to handle the runtime error.

Hi, If I connect a child class type to a static class member VI of the parent class, the static member VI preserves the child class type passing trough the VI. This is a very nice feature and simplifies programming. However, if I connect a dynamic dispatch wire to such a VI, the class type is preserved but the "dynamicity" is not. This is a bit annoying since I cannot then pass a dynamic wire to a static member VI as I have no way of casting it back to a dynamic wire. So is this intended feature for some reason or a bug? EDIT: Oops... This problem occurs only if the static member VI is inside a polymorphic VI and you drop the polymorphic VI to the block diagram instead of dropping the static VI directly. So it sounds like a bug to me as I assume polymorphic VIs should act exatly as the VIs inside it.

It is "human readable" text, but the part that makes XML useful is the application of a schema. LabVIEW's XML functions use a LabVIEW schema to read and write data. If the data to be graphed is not originally from LabVIEW, your effort to read and process the XML goes up considerably.

Or "Lab View". It is one word, thank you. If you search Monster.com or Yahoo!, it will almost always be (mis)spelled this way... I used to drink ginseng tea, but it made me too nervous. Now I drink Dunkin' Donuts coffee only (Note proper use of Yahoo! and Dunkin' Donuts)

IE Tabs does not not fix Kronos problems... My company uses Kronos for timekeeping. I've never been able to use Firefox because specific Java scripts fail to run. I tried this extension with great hope, but the same problem occurs; a critical UI dialog is opened in a Firefox window, not an IE window. It fails to render anything... I still have to do my timekeeping in IE. I'm still Googling and experimenting with my FF settings....

I'm mysterious in the ways I use LabVIEW Well, I think this bug was project specific as I've not seen it any more. The class doesn't in general break even though the polymorphic templates are not functional.

Perhaps these annoying features can be made optional so that professional users can turn them off from LabVIEW options. Microsoft Word has lots of features that tend to "correct" language incorrectly at least in my native language, so I turn them off. I'd prefer LabVIEW to allow users to turn off features as well, such as this I complained about. Another thing I'd like to see is a feature that would allow to use standard dynamic VI template for override VIs instead of the present call-parent-VI created using scripting the content of which I 99% need to replace with the normal error case template. Perhaps this could also be an option that the user could select...

This is maybe more like an annoyance than a bug but still. If one tries to add a new VI into a class, LabVIEW uses the class icon template to create the new icon for the class. However it overwrites that icon with a number on the lower left corner. If the template happens to have some colored pixels in this region, the they are also overwritten with this useless number. I see no reason why the number should be added to the icon in the first place, but if LV developers insist adding some additional stuff to the icon template, it must not overwrite non-white regions in the template. If at least one pixel in the template is non-white in the region where the number should be written, it must not be written at all.

I'm a fan of the OpenG toolkit too, but don't forget that there has been a way to do this since 7.1 using the Time Delay and Elapsed Time "Express VIs" ( Did I say that?!) They look bad on your diagram when placed, but you can right-click and select "view as icon" to make them less obtrusive... Just a thought when you get stuck somewhere without "OpenG on a stick" There's a thought for the prize of a coding challenge; a nice sized USB stick drive (>=2GB) preloaded with OpenG tools and everything in the Code Repository...

Thanks, but no D: references found. The code was small enough that I could just recreate it. No problems now.

Get a good book on OOP in general. OOP is so large a paradigm shift that it's hard if not impossible to fully comprehend by just looking trough a few examples. I like "Thinking in C++" books by Bruce Eckel, but they are specifically about object oriented programming in C++. However the emphasis is on the mind set required for object oriented programming in general. The books guide trough different OOP concepts starting from the most simple ones and going to steadily to more complicated ones. There is a similar book on Java, namely "Thinking in Java" by Eckel as well which I haven't read and therefore cannot comment on.

I'm also using XP, and 8.2 does the same here... :thumbup:

I have not really ever understood the point of developer certifications. From a developers point of view, a certification may be some sort of competetive advantage. I however expect past work to prove much more than a certificate. From customers point of view a certificate doesn't really prove anything as the most important thing in software development is never the actual straigth forward problem solving that the certifications most often test.

I've been on 8.0 for a while, and couldn't find it until I went looking now. It was originally on the top-most pallete, for 8.0 its under: I thought it was removed in 8.0. Ugh. Guess my age is showing...

Hi, Try to open the .lvproj and .lvlib and .lvclass files with your text editor to check if the file paths are correct. If so, you can try to remove files from your project to see if the problem is related to some specific file. There are so many bugs in the new LabVIEW 8.20 that makes LabVIEW crash that it's hard to say which one you have encountered or if you have found a new one. I submitted some of these LV crashes bugs but then I got tired of submitting the bugs as there seems to be so many of them. Something that seems to help in some cases is rebooting the computer. Restarting LabVIEW is not enough. Another thing that seems to help is to open all the top level VIs and all the classes related to a project and then pressing ctrl+shift and clicking the run button of one of the top level VIs. Then save all. This fixes invalid inter-VI references.

Damn! I learn something new every day! :thumbup: Thanks Mike! :worship: For grins, I pinned the Decorations Pallete, then with the Front panel active (Decorations Pallete visible) drag-and-dropped various decorations to the block diagram window. I got the No-Can-Do circle with slash, then let go anyway and still get the decoration on my BD. Stupid is as stupid does... See this I wonder if there is a LabVIEW.INI file option to enable the decorations pallete with the block digram active?

I've worked a bit with XControls, and played around with what you uploaded. I've attached version that you can play with and look at XControls a bit more if you like... I went with a transparent gauge, then placed a LED behind it. I Set the foreground and background colors of the LED. You can get a nice 3-D shading effect with this. (The names of the files in the XControl are defaults, this was just a quick hack to show you what can be done) I created XControl properties for the lower and upper limits as well as the scale limits for the gauge itself. Thanks for making me play a bit more with XControls. I think they can be fun, but are a lot of work.. The nice thing is you can simplify your block diagram ALOT. Download File:post-949-1161867842.llb (LV 8.0.1)