Michael Aivaliotis

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)

I have done this and it works nice now.

http://lavag.org/old_files/monthly_04_2009/post-2-1239043846.jpg' target="_blank">

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)

"here I'm actually going to do some work instead of building a framework".

That's why you use templates.

...After twenty plus years of software development there is one thing I have learned for sure and that it that virtually everything is subject to change at some point regardless of how much we believe it won't. I would rather prepare for the possibility of change rather than write that something that is rigid and very difficult to change.

QUOTE (Pollux @ Apr 6 2009, 08:45 AM)

And also from the close botton (x) on the title bar. If I close a called vi from that button apparently it closes only the front panel but keeps running, blocking the main.vi. How should I correct this bug?

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)

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)

...Now you need sequence locals for each step, and if you need to insert a step later on you need to rewire things.

Exactly. This is why you don't use sequence structures.

QUOTE (psychomanu @ Apr 3 2009, 02:54 AM)

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)

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)

Most people use LabVIEW professionally and in production environments. They rarely have the time, inclination or ability to dig up stuff like this.

Personally, I feel it would be a huge waste of time for me to try to reverse engineer it (even if I did know something about the original format), as there is other stuff to do and this, while nice to have, is never something that I really needed.

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)

This is actually what I do in most all of my code.. All my parallel processes are implemented as active objects. The object takes care of allocating all necessary stuff before spawning the process and cleans up afterwards. Depending on the nature of the task of the process, I'll simply use an "Abort VI" to stop the process or a message with response notifier. For me, the usage for one over the other is about 50/50 I guess.

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.

If you have an SSH access to the server and your hosting provider premit you to install application, maybe you can

QUOTE (Aristos Queue @ Mar 20 2009, 06:57 AM)

I'm still not saying this method is good or bad; I'm just walking through arguments to see if this path works. It seems like a more effective way to stop a process than having to code boolean checks all over your code, especially when LV has such nice hooks right in the assembly code at the end of each clump of nodes to detect abort.

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)

...and I also own Conway and Watts "A Software Engineering Approach to LabVIEW". I found the book to be much more helpful in easing me into the OOP world. It doesn't get you all the way there, but it does show you why you should explore OOP and teaches you how small modifications to your current coding practices can give you many of the advantages of OOP.

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)

...Specifically, You can place only the stuff you want to access frequently in the virtual folders and thus ignore all the boring subVIs.

Also, you can have links to documents, etc.

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)

Do you mean it IS possible (and realistic) to have LV development environment on this server?

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?

The "only" thing required for that would be a development environment running on server...

It would be great if there was a board plug-in that could show a web-preview of the diagram of uploaded VIs...

A clarification. A project ,by itself, does not load VIs into memory when it is loaded. It is able to determine what dependencies are needed/used without loading VIs into memory. The project does load project items such as libraries or classes which may load VIs.

Is that more or less dirty? Can it be made acceptable somehow?

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".