Michael Aivaliotis

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:

QUOTE (vugie @ Mar 19 2009, 05:41 PM) It depends. How do you install LV on a remote Linux box?

Two questions: Which URL are you visiting? What browser and version are you using?

QUOTE (vugie @ Mar 19 2009, 04:06 AM) LAVA runs on a linux server. If you have a plan for how we can accomplish this, I'm all ears.

QUOTE (crelf @ Mar 12 2009, 08:27 AM) Ya that would be great. Now back to reality...

QUOTE (gmart @ Mar 18 2009, 03:13 PM) This is important to note. Thank you gmart for reminding everyone. If some of you see the "loading VIs" dialog popup when you are opening a project, this is because you either use LV classes or lvlibs. Only VIs called by the classes or contained in the lvlibs are loaded into memory, other VIs are not. Watch out for this.

QUOTE (Aristos Queue @ Mar 18 2009, 03:07 PM) It depends. Can the VI that is being aborted tell if it is? If so then it can exit gracefully. Otherwise, it's a no-no in my books. I would only abort a VI if it's a runaway process, a very very simple VI or I've exhausted all other forms of communication. Like a divorce is to marriage.

I also use a similar stop functional global concept to trap aborts from parallel processes. Mine also has a reset input so you can clear the abort after you've acted upon it. I'd like to address the use of cases to "case-out" code after an abort. Depending on the granularity of your state machine, you may be able to get away with handling the abort up front and avoiding the need to place the abort checking too deeply in your code. here's how I handle it using the JKI state machine. I try to avoid putting looping code inside subVIs where I have to later abort them. Instead I use the natural looping of the state machine to repeat test tasks.

I remember watching this back in the 70s as a kid. However, I can't remember the context. Was it before a movie or what? Maybe I saw it on SNL. Not sure. I remember thinking at the time: "That's brilliantly funny".

No idea, I just hopped in to comment that I think your post title is awesome!

I always try to post screenshots. That was the LAVA policy way back at the beginning. Now it seems people are not bothering. Now that the tools have caught up, I think screenshots should always be included. I think we should all make an effort to post screenshots. Nowadays I prefer video. It's so easy with Screencast.com and Jing (is screencast.com blocked Cat?).

LabVIEW uses Ctrl+G and Ctrl+shift+G to jump to the next or previous item in the Search results list dialog. I want a similar key combination to navigate to the next error in the Error list. Currently my process is: Click broken run arrow (or ctrl+L) Scroll the Items with errors list to the top item in the list. Highlight the first VI in the Items with errors list Doubleclick the first item in the Block Diagram Errors list. Fix the error in my code press ctrl+L to bring the list frontmost Doubleclick the next item in the Block Diagram Errors list. Fix the error in my code press ctrl+L to bring the list frontmost Repeat process until errors are fixed in the first VI in the list Continue doubleclicking in the errors and warning list until I'm done. I would like to see a shortcut key that would iterate through the errors in the errors list. Edit: I'd like to add that LabVIEW needs to be smart so that it wouldn't jump to the next error if it doesn't exist anymore due to a previous fix. However, I don't see this as a big problem since the Error list dialog already performs that checking in real-time anyway.

I can attach an 8.6 VI with that property but it won't help you much since you can't generate the sub-properties from it. You need to do all your work in 7.1. I think there is a wind of change which may see scripting come out of the shadows. Hopefully sooner than later. If you feel strongly about it post your support here.