Mike Ashe

I have seen and tried to use this before. Sometimes it worked fine and in other areas it did not let me run my code. I had a snippet of code that I wanted to comment out, and the coditional worked fine for that. When I commented out a non-executable VI, the diagram looked like it compiled (good run arrow) but I could not run the VI, it errored on execution. Too bad, since this would be a very good feature to have to share sections of the same VI that is being worked on by more than one person. Mike

I removed XP-SP2 due to problems with multiple programs, not just LabVIEW. I think this is more of a Windows (Uncle Bill...) issue. They (microsoft) tried to clamp down on everything so hard to solve security issues their way, that a lot of apps that used to work now have problems.

Almost like having a LabVIEW Service that is invisible and a Monitor/UI (in System Tray or not) that is the only part we "see". This is the method I am implementing at the moment on a project that spawns communication handlers. I had observed that occasionally the spawning would hang. Not good in a distributed Client-Server architecture. Mike

Download File:post-45-1095776403.llbDownload File:post-45-1095776446.vi Hi again, Sorry that this took a while to Post. Here is a beginning stab at a General Recursion call method. Its not "drag a VI's own icon" but it works. The enabling VI is: General Recursion Call (Variant).vi I have included it in the library: Factorial using General Recursive Call (Variant).llb and also included a comparison and benchmark VI: Factorial Comparison Benchmark.vi The method is saved in LV 6.1 so that those who are a few versions behind can try this out. You do pay a performance penalty, see the default values on the benchmark. Thanks to various other people on the LabVIEW Scripting forum for pointing out the "New VI" primitive. I am sure that this method can be improved. Note in the: Factorial using General Recursive Call (Variant).vi the code before and after the recursion call that does the clustering/unclustering and variant transformations. I think this could be handled by a couple of general VIs, perhaps JK or JPD already now how to do this using the OpenG LV Data VIs. Cheers, Mike PS: Sorry I missed you all at NI Week this year, maybe next year.

Code Challenge: (originally posted to IFLV) PART 1: But I think that it will soon be possible to do exactly what you say above, grab a VI's own icon, drag and drop, and (if you have a switch or two set and some LabVIEW scripting in place) have the VI replaced on the diagram with a subVI created from a template (like the Factorial VI) modified by LabVIEW scripting, with the name of the VI replaced, or Run Method calls, etc. We just need to be able to capture the LabVIEW error/exception before the error dialog pops up and script away. Now that I think of it, I don't know of anything concrete, but I'd be pretty surprised if someone at NI doesn't either already have this or could code it up pretty quickly. Sounds like it would make a good IFLV/OpenG/LAVA/NIDevZone coding challenge considering that the scripting interface has been unofficially exposed recently. Any thoughts anyone? (or better yet, code) PART2: Just thought of a possible easier alternate method, the: "General Recursion Call (Variant).vi" 1. Use Call Chain or OpenG vi to get reference to calling VI. 2. Use LabVIEW scripting to get calling VIs connector pane. 3. Use Get Controls (Variant) from OpenG to read the indicator(s) of the calling VI. 4. Use Set Controls (Variant) from OpenG to write to the control(s) of the new instance of the calling VI. 5. Use Run Method with Wait for Completion = TRUE 6. Use Get Controls (Variant) to read the indicator(s) of the new instance VI. 7. Process and return... Granted, it is not "grabbing own VI icon", but include in \user.lbi\... etc... Did I forget anything? Now, who will come up with the most elegant :beer: :thumbup: implementation, or a proof :headbang: that this will not work? As my college prof's all said, "the rest is left as an excercise for the student..." Ciao, Mike

Since the variant carries data type information with it it is possible to create a generic unpacking VI. Also by passing an array of variants rather than just one, (or a cluster) you can have a generic variable/data list that can be passed to subVIs in the State Machine. These subVIs can have a strict typedef VIServer interface _or_ free form front / connector panels and still communicate with the State Machine. This lets you implement the subVIs as plugins. Essentially, with a little extra work you can have arbitrarily complex subVIs plug in to your State Machine, add new ones at any time and never have to change the main state machine interface definition to the subVIs. For a hint of the interface power of variants look up the Universal_Probe.vi that Jim Kring did. This has a generic variant parser built in, which populates a tree control with whatever data type you point to. :thumbup:

When you close a VI with subVIs you will often be asked if you want to save "such-n-such" VI. When you click on the Explain button you get a dialog that tells you that a subVI, etc has changed locations _or_ its connector/front panel. You are then told to check the VI to make sure that the connector is still wired correctly, but they don't give you the list of changed VI(s). In a 2 VI project this is no problem, but most of us work in the dozens at a minimum and hundreds of VIs routinely. How about a list of changed VI(s) :headbang: