Jump to content
Francois Normandin

Recursive VIs cannot be built in package

Recommended Posts

I've implemented a very simple VI in LV2009 using recursion and I can't package it.

The OpenG builder waits infinitely for the VI to load in memory, thus preventing VIPM to complete its tasks.

 

I don't get error log because I need to abort the execution with Task Manager. But I stripped down my package to include only the recursive VI and the OpenG builder progress bar gets stuck until I kill the process.

Share this post


Link to post
Share on other sites
I've implemented a very simple VI in LV2009 using recursion and I can't package it.

The OpenG builder waits infinitely for the VI to load in memory, thus preventing VIPM to complete its tasks.

 

I don't get error log because I need to abort the execution with Task Manager. But I stripped down my package to include only the recursive VI and the OpenG builder progress bar gets stuck until I kill the process.

 

Thanks for reporting this. I'll take a look to see if we can figure out what's happening. My guess is that OpenG Builder is trying to list the VI Hierarchy (using the VI Server VI.Callees property) and doesn't handle the recursion well.

Share this post


Link to post
Share on other sites
Thanks for reporting this. I'll take a look to see if we can figure out what's happening. My guess is that OpenG Builder is trying to list the VI Hierarchy (using the VI Server VI.Callees property) and doesn't handle the recursion well.

 

Something along those lines.

The only clue I've got (haven't tried to correct it myself) is that one of my two CPUs is running 100% until I stop the process, so there's a condition to add to stop that loop.

I'm sure it's not a serious bug and that a fix will be easily implemented.

 

thanks,

François.

Share this post


Link to post
Share on other sites

I don't know if there are other fixes needed for it to work in every case, but I managed to get it to work by modifying these two VIs:

 

Find VI Hierarchy__ogb.vi >> Filtering out the array from VI.Callees to remove self prevents from entering an infinite loop.

Sort VI Hierarchy__ogb.vi >> Had problems sorting out because Caller and Callee Links had duplicate pointers. Removing the callers links from the callees links clears the problem.

 

 

Find_VI_Hierarchy__ogb.vi

Sort_VI_Hierarchy__ogb.vi

Share this post


Link to post
Share on other sites
I don't know if there are other fixes needed for it to work in every case, but I managed to get it to work by modifying these two VIs:

 

Find VI Hierarchy__ogb.vi >> Filtering out the array from VI.Callees to remove self prevents from entering an infinite loop.

Sort VI Hierarchy__ogb.vi >> Had problems sorting out because Caller and Callee Links had duplicate pointers. Removing the callers links from the callees links clears the problem.

Find_VI_Hierarchy__ogb.vi

Sort_VI_Hierarchy__ogb.vi

 

Ya, these were the places I was going to look. Thanks for clearing the path :)

Share this post


Link to post
Share on other sites

Hello to all, boys,

 

I'm using VIPM ver 2011.0.1 (build 1692) dic 07/2011 Community Edition with OpenG Builder ver 3.0.1-2.

 

I am trying to create a package to a library for LabVIEW 2011 that uses recursion native, but Package Builder gives me the same problem described by Kring to "Known Issue (Case 8006): VI Package build hangs in LabVIEW 2009 when recursive VIs included in package" and stated fixed from version 3.0 and later ...

 

I think in my case the problem is that recursion is not "direct" ... Let me explain ...

 

In my library there is the following sequence of calls: VI_A call VI_B that call VI_C that call VI_A!

 

If I realize the simple recursion VI_A call VI_A, the Package Builder executes with success, but building my library, it fail waiting infinitely for the VI to load in memory... the same issue reported by Normandine... Even in may case, I have to kill the process.

 

I do not know if Package Builder maintains a global list of calls, but I think the problem may reside in the test that checks for the sub-VI called the list of callers ...

 

I'm sorry it could not provide a possible solution ... :-(

 

Thank to all!

 

Osvaldo

Share this post


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.

Loading...

×
×
  • Create New...

Important Information

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