Jump to content

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.

Link to comment
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.

Link to comment
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.

Link to comment
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

Link to comment
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 :)

Link to comment
Share on other sites

  • 2 years later...

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

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

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