Michael Aivaliotis

QUOTE (joshxdr @ May 29 2009, 07:29 AM) I think you should lobby NI strongly to get them to add these pro features to the version of LV for FRC, including integrated source code control. If we are trying to teach the students proper software engineering then we should give them all the tools.

It's nice to see this finally come to fruition for sure. :thumbup: Thank You NI. I'd also like to see scripting discussions continue here on LAVA and hopefully y'all won't abandon us for the dark side. We have some excellent gurus on LAVA that were able to do cool things even with scripting locked. I can only imagine the possibilities now that it's been unleashed. As far as complaining... of course we'll still complain. Let's not forget XNodes and project environment integration.

A new article is up with info on how to unlock scripting: LabVIEW Scripting Here are the links for scripting download: LabVIEW Scripting API - Vista.zip (6.0 MB) LabVIEW Scripting API - WinXP.zip (6.0 MB)

This is an excellent suggestion Ton and something I have thought of myself.

I saw this movie with my family. It will definitely spark a new generation of trekers. Great movie!

Some news over here on this topic.

NI has started a new group on their communities page called LabVIEW APIs. At the top of the page they announce that LabVIEW Scripting is on the way:

I'd really like to find out how they fold this t-shirt:

This looks like the Patent for VI Scripting. SYSTEM AND METHOD FOR PROGRAMMATICALLY GENERATING A SECOND GRAPHICAL PROGRAM BASED ON A FIRST GRAPHICAL PROGRAM

QUOTE (Pollux @ Apr 6 2009, 11:10 AM) Sorry, I must have been daydreaming when I wrote my suggestion. Yes, separate calls to the VIs but in separate parallel loops!

QUOTE (Yair @ Apr 6 2009, 09:42 AM) That's why you use templates.

QUOTE (Mark Yedinak @ Apr 6 2009, 09:24 AM) Amen Brother!

QUOTE (Pollux @ Apr 6 2009, 08:45 AM) If you want to use the (X) button then you need to use another event case called this VI panel close. QUOTE (Pollux @ Apr 6 2009, 08:45 AM) Vhat I'm really trying to do is a interface in which main.vi is able to call a subvi (take achizitie.vi for example) but at the same time, main.vi should remain active so the user can call another subvi (calibrare.vi for example). (I hope I am clear enough...) Using an event structure is fine. The problem is you can't do what you want with the existing design. When LabVIEW is inside an event structure executing your subVI code, it is stuck in there and cannot respond to other user events like button presses. Actually, it queues-up events and executes them upon the next iteration of the while loop. If you want to be able to launch multiple UIs in parallel (provided that your hardware can be accessed in parallel), then you need a different approach. See image: http://lavag.org/old_files/monthly_04_2009/post-2-1239034898.png' target="_blank"> This, in my opinion, should get you to your desired goal faster. The alternative is using dynamic calls to parallel process VIs which might be too much for your level of experience.

QUOTE (psychomanu @ Apr 3 2009, 02:54 AM) Exactly. This is why you don't use sequence structures. QUOTE (psychomanu @ Apr 3 2009, 02:54 AM) I use local variables to propagate the error cluster, but that's 'bad practice'. No, 'bad paractice' is using sequence structures. Using local variables on top of that just makes things worse. QUOTE (psychomanu @ Apr 3 2009, 02:54 AM) Looking forward to reactions, Manu It seems, from your example, that you already have error clusters going into and out of your VI. What is the point of the sequence structure? Just daisy-chain all your subVIs together. I'm not sure if this design is intended as a quick prototype or if this method is used in real working code. If it's real code, please consider changing your design to use a http://wiki.lavag.org/State_Machine' rel='nofollow' target="_blank">state-machine.

I apologize in advance if this has already been mentioned. Sometimes, when I'm creating a Data Member Access VI, I end up with a new broken VI. The problem is the new input or output terminal is not wired to the bundle or unblundle node and it is not wired to the terminals. See image: I notice this happens mainly when I'm selecting a subcluster of a larger data cluster.

If I rename a parent dynamic dispatch VI, the children override VIs don't get renamed. I assume this is a known issue. I'm not sure if others think this is an issue that should be fixed but it's bugging me lately. This is in 8.6.1

I know in the recent versions of LabVIEW you can select a group of controls and edit properties on them. This is great. Even better would be to be able to: Select a group of front panel controls (or blog diagram terminals). Right-click on one of the group Perform any of the actions on the create menu. For example: Create Reference would create one reference for each selected control Create Property Visible would create one Visible property for each selected control

QUOTE (Yair @ Mar 23 2009, 12:40 PM) Talk about buzz kill!I love that this (supposedly 15 year old) is poking around. Hack away flarn2006! Let us know what you find.

QUOTE (Jeffrey Habets @ Mar 21 2009, 03:28 AM) Jeffrey, I also do this however I use dynamic events or queues to stop the process. Never abort. I don't like imposing rules on things like this because even though you can have general guidelines and best practices, it really depends on the specific application at hand, the corporate style guidelines and (at the end of the day), the comfort level of the programmer. So I'm not saying you should never use abort, but it needs to be designed-in and all editors of the code must understand the caveats of this method.

Here's an example of how to implement it in your state machine. The while loop would be your state machine loop. However with a little smarts you could probably make this into a subVI function.

QUOTE (Ale914 @ Mar 20 2009, 06:53 AM) Well, It's a dedicated server, so I can do whatever I want. The problem is Linux scares me. My fear is performing an installation that will somehow crash the server, which even a reboot can't fix. I can't afford to have the server go down because you guys will start yelling at me.

QUOTE (Aristos Queue @ Mar 20 2009, 06:57 AM) You might have some point here but understand that you are arguing against an ingrained and taught (even by NI) philosophy that says you should never abort a VI (or use ctrl+period). Using abort has very limited uses. I can see it used if you are absolutely sure that it won't cause problems or if you've designed it in to be aborted from the start.

QUOTE (SULLutions @ Mar 20 2009, 03:23 AM) I also unfortunately own this book. The words "Software Engineering" threw me off. The main useful sections are the ones describing how to create and use functional globals. There is an introduction to OO concepts but it's very weak. If you're a total novice then this book will help a bit, but don't count on it changing your life. The book had a very short lifespan when it was first released. It was relavent at the time but is way out of date and boring now. Is there an LVOOP book out? Is anyone writing one? I'd buy that!

QUOTE (Yair @ Mar 19 2009, 11:33 AM) Yes! You don't have to put all your VIs in the project. I typically put only my main user interfaces, process VIs and other toplevel code.

I took an object oriented analysis class many years ago (before lvoop was released) and after I finished it I got a much better understanding of OOP. There is no coding at the analysis stage. I actually had a lot of fun. Honestly, I don't know how anyone can program OOP without a better understanding of analysis. Just my 2 cents. :2cents: