Leaderboard

Have you ever been editing a bunch of VIs in your project and then decided to run the main VI to see if the edits worked, but you left a modal dialog VI front panel open somewhere? The result is it becomes frontmost, but is not actually running so you are stuck because you cannot get to your main VI UI and you cannot interact with the modal VI either. I do this all the time and it just ticks me off. So, I threw together this simple VI to avoid all that. I drop it down on the block diagram of my main VI so it runs first. If this happens to you, give this a try and let me know what your think. -John Stop on Modal VI Open.vi

Hello hello, My name is Veronica and I'm new to LAVA, so I thought I'd stop by and introduce myself! I'm currently about to start my last semester of software engineering at McGill university in Montreal, Quebec, Canada (please see informative video at end of post). I've been an intern at National Instruments for the past two summers, and although it's taken a little while for me to tear myself away from the land of text based coding, I must say I've become quite fond of LabVIEW! Last summer I worked for the RF Product Marketing group, and got to build a signal jamming demo using high speed digitizers for wideband spectrum analysis, and signal generators for jamming. This year I'm building a demo for a FlexRIO adapter module, and I also worked on some top secret slides for the day 2 NIWeek keynote. All in LabVIEW (/LabVIEW FPGA)! Exciting stuff. I'm actually here in the LAVA lounge at the moment thanks to some ongoing harassment from Norm, el capitan or whatnot... he sits two cubes behind me here at NIC, and since I'm going to the BBQ at Stubb's, he insisted I come say hi first. Such treatment we interns must suffer on a daily basis here at NI . So it's nice to meet you all! And for anyone attending NIWeek or going to the BBQ, I look forward to seeing you in person and discussing the power and awesomeness of LabVIEW. Cheers v ( )

I've copied the Smishy Smashy functions from BD Minion and made them into a RCF plugin. It takes the selected control terminals and puts the labels on the side (right for indicators, left for controls) and stacks them up. I do this all the time, now I'll do it faster. You can download it from SVN here (LV 8.2). Reference NI LabVIEW API Community - Getting started automating development through LV Scripting SmishySmashy.llb

Hello, Remember that you are limited only* by your imagination LabVIEW has a function in the "File function" Palette to list the content of a folder : So you can use it to get the content of your folder and then use a while loop to read each file : Of course you can then add improvements to only read text files, etc.. Hope this helps *: well.. almost..

Interface The concept interface doesn’t exist in LabVIEW yet, but I hope that it will be added in the future. An interface class is an abstract class that only contains empty methods/VIs. So when someone calls this method/VI the call should be forward to the real implementation of this method in the class that implements this interface, just like normal inheritance, but instead of deriving for this Interface class the OO term is to implement this interface. Many design patterns uses the Interface concept e.g. Command Pattern and Observer. So how do you implement an interface in LabVIEW? Of cause you can make your classes all inherit from the Interface class they need to use. But is really a UUT a kind of command? Is a Player a kind of Observer? You should always be able to say the <child class> is a type of <parent class> E.g. A car is a type of vehicle. But maybe you can ignore this rule for those classes, but maybe you want to implement several interfaces, then you’d run into trouble. The way I implement this in LabVIEW is by using an Interface Helper class. So if I have this example where 2 different classes like to implement MyInterface. I have to create an extra Interface child class to the Interface parent class, so I can make use of the powerful dynamic dispatch. These are two very small classes only containing the methods defined by the interface. So when someone calls the Update method/VI in the Interface class, that call will be directed to the Update methods in my X_MyInterafce class which only forwards the call to the Update method in the Player or Spectator class. This way I can implement several interfaces. I’ve made a small example code that uses this approach together with the observer design pattern ( PartII). Project: TennisGame.zip You need some Class VIs you get when installing GDS Key: COMM-UNIT-YEDI-TION-2009 The main VI does these things: Creates the TennisBall, 2 Players, X no of Spectators Creates the Help classes PlayerInterface and SpectatorInterface These 2 help classes are used as inputs to the Ball:AttachObserver method. The AttachObserver method stores the reference to all observers/subscribers The main VI updates the Ball's position using the SetBallPosition method. This method sets the new positions and also calls the NotifyObserver method. The NotifyObserver calls the update method on all Observers that are attached. The Update method in the Player and Spectator class, has now been informed that the tennis ball has been moved and they update their private attribute they have of the balls position. This might not the best way of implementing this problem, but shows how the players and spectators can be notified when something they have subscribed to happens. Cheers, Mikael

Over on the dark side it is possible to see who gave kudos to a post. You can also view various statistics about who you have kudoed the most, who has kudoed you the most, etc. Is it possible to see this info on LAVA as well? I would like to at least be able to see who "voted up" a post. Since we don't allow "voting down" a post, there is no risk of hurt feelings when person A sees that person B (whom they have always admired) is willfully and wantonly voting down every post that they make. Not that that would happen here. -Toby

It's only inappropriate in that it doesn't show enough skin Welcome V - see you at the barbie.

And just to put a 'face' with a name with a photo that Veronica says is probably 'LAVA inappropriate' and 'the most skin LAVA has ever seen' (she must never have seen the Coyote Ugly photos)....

LAVA search is just a joke.. I gave up using it, try "site:lavag.org OOP Benchmark". Maybe the post you're referring to is the post 13 of this LAVA 1.0 thread (in google cache)

Hi Angelo Definitely the Master Slave architecture is superior to polling, don't go back. I don't know why in your case you can't call it as a subvi and display in a subpanel, the Notifier shouldn't be killed, take a look at the attached demo. MasterSlave.zip I just built it up from a LabVIEW template in 8.5. If you need more help post some code up that replicates the issue.

Hah! I knew there was a reason I hadn't signed up for twitter! On the slightly more serious side, I have a real hard time feeling bad for somebody who got skunked while blatently fishing for kudos. And if they then get offended because you didn't vote it up? Puh-leze. That person needs to get out a little more and develop a sense of self-worth that isn't based on an arbitrary rating from strangers. PPPPS: Are you misusing the abbreviation for 'post script'? PPPPPS: Yes, you are. ("Post script script script?") PPPPPPS: Am I a total lamer for calling in the grammar police? P^7S: Yes, I am. This issue really makes me question the point of having kudos in the first place. Kudos are meant to reflect that someone has contributed to the LAVA community--either with humor, by helping others solve problems, sharing tools, etc. The minute social pressure contributes to the decision to give kudos is the minute they become absolutely worthless. Personally, I think it is interesting to be able to trace kudos on the dark side. It gives me another way to find people and topics that match my interests. It also lets me discover that AQ's 29 kudos were all given to him by Darren and a lurker named 'Aristos Notifier.' It's a feature that would be nice to have.

Hi Bjarne I just ran the two demo's on my machine running LV 8.6.1 and the difference between the Traditional and the LVOOP implementations is that the LVOOP solution takes 100 msec longer to test 148 boards, each board having 13 tests. So 0.7 msec per board overhead using LVOOP, not too bad I tested under 8.2.1 and I get 350 msec to do the 148 tests, so a bit longer, I suspect LVOOP has been optimized a bit since then. Note that these tests were performed on my crusty but trusty 5 year old Dell Inspiron 1150 2.4GHz Celeron laptop. For me, the benefits of implementing LVOOP would greatly outweigh the performance hit, especially when I wanted to implement new tests and new boards. The code is simpler and self documenting, easier to farm out within a team of developers and easier to debug.

To further assist in avoid confusion (or creating more of it), "GOOP" is a registered trademark of the Endevo corporation, and is usually only used when refering to their implementation of by-ref OOP in LabVIEW. I'm not sure if Sciware's "GOOP Developer" actually develops GOOP, or a different LabVIEW OO implementation. There are, of course, many implmentations of OO in LabVIEW: VISTA Class Generator (V I Engineering, Inc - the first OOP implmentation AFAIK) GOOP (Endevo - the real powerhouse in OOP in LabVIEW for many years) LVOOP (NI - the by-val implementation that comes with LabVIEW 8.2 and higher) dqGOOP (DataAct - fast and has little footprint, but I've never tried it for inheritance) OpenGOOP (OpenG - open source implmentation) GOOP Developer (SciWare - never tried it, don't know anything about it) more...? Also, Endevo have OO tools that help you manage your OO in LabVIEW (whether it's LVOOP or GOOP - in fact, the latest version of GOOP is really a by-ref implementation of LVOOP - how cool is that?) with their GOOP toolkit and UML modeller (you can create UML and it will automatically build the classes for you, and vice versa!) I think the next release of LabVIEW might make things even more interesting (if used appropriatley - that'll be the real challenge...)

Thank you so much!