Jump to content

Recursive LabVIEW Calls


Recommended Posts

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

Link to post
Share on other sites

Hi

In a 2 step process, one can put a VI with the (attached) diagram on the palette with merge option. Step one is to select the vi in the palette and put it on the diagram.That will put code for the VI to call itself. Step two is to drag and drop the VI icon in the VI reference control to set the connector pane.

It is possible by scripting to create the VI reference to match the pane of the caller, programmatically doing step 2. Now how to trigger this script when the code snippet is merged on the diagram? Would it be possible to intercept the merge call?

One far fetch possibility is to add a CIN or CLN in the merged VI code and have the CIN(CLN) initialisation code (when loaded in memory) to execute the script. The script could also get rid of the extra CIN(CLN) node

Any thoughts?

post-29-1086288261.png?width=400

Link to post
Share on other sites
It is possible by scripting to create the VI reference to match the pane of the caller, programmatically doing step 2. Now how to trigger this script when the code snippet is merged on the diagram? Would it be possible to intercept the merge call?

One far fetch possibility is to add a CIN or CLN in the merged VI code and have the CIN(CLN) initialisation code (when loaded in memory) to execute the script. The script could also get rid of the extra CIN(CLN) node

Jean Pierre,

I actually investigate this quite a bit about 8 months ago, and I could not find a way to intercept the merge call. :(

One thing that I was trying to do was to drop some VI that will execute upon merging with the BD; again I was not sucesfull. It did not occur to me to think about CIN (CLIN), may be it will work. The only way I was partially sucessfull was through the use of "custom" express VI. When the flag "configure express VI immediatly" is set to true, Express VI can launch some code. While it does work, I though it was not generic enough to be very usefull.

Because of that, I start a project to extend the existing LV palette (I called it "OpenG Palette Extension"). The goal is to have a palette with the "feel" that the existing LV palette, but where we can associate methods to each click on an icon (ex: run, Open FP, Open Diagram ...). I have not investigate about merging code or primitive with the diagram using that tool, but I will in the future.

PJM

Link to post
Share on other sites

The CINLoad() or CINInit() functions launching a shell command "labview.exe somecleverscript.vi" would allow to execute VIs as soon as the CIN node is loaded into memory. Possibly, a VI could execute code as soon as an instance of itself is created, then allowing some creative/evil scripting. Why do I feel like opening a Box of Pandora?. :unsure:

Link to post
Share on other sites

When Express VIs are dropped onto the diagram, their configuration panel is automagically launched. It appears that express VIs are tagged with information about thier configuration panel VI location, LabVIEW looks for this information when they are dropped onto a diagram, and if found launches the configuration panel. Perhaps this mechanism can be exploited somehow.

VI:SetTag: ..\National Instruments\LabVIEW 7.0\vi.lib\express\express signal manip\ConvertfromDDTConfig.llb\subSetVIProperties.vi

Posible use: Create Express VI ?

Link to post
Share on other sites

I opened the express VI "Elapsed Time.vi" <LabVIEW 7.0\vi.lib\express\express execution control\ElapsedTimeBlock.llb\Ex_Inst_Elapsed Time.vi> in a text editor. I found the following:

_Wizard v 2

Link to post
Share on other sites
  • 3 months later...

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.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.