LabVIEW
LV class recursion
I have a LabVIEW class. The class has a VI that performs a small amount of work on the content of the class data, which might require a recursive call to itself. I can set the VI to recursive, drop a copy of itself onto it's block diagram, but as soon as I try to save it all LabVIEW disappears rather ungracefully.
I've attempted to repair the VI, recreate the VI (assuming it might be corrupt), and recover/recreate the class project, but no matter what I do, LabVIEW just pops at save time.
Please someone tell me recursion is supported in LabVIEW classes and that this isn't a bug!
LabVIEW 2010 SP1 (I don't have 2011 yet)
I hate it when this happens - I've fixed my problem just after posting for help on the forum!
LabVIEW appears to crash in this scenario if the Execution > Reentrant Execution > Preallocate Clones radio button is active. I realised it ought to be Share Clones between Instances. Selecting this solved the problem. 
Thoric,
Do you have a small class that could reproduce this crash? If so, could you post the files? I could not the the crash to happen by using the settings you described.
Chris M
OK Chris, attached is a zipped LabVIEW project (2010 SP1).
It contains two classes:
- container_class
- recursive_call_class
Class 2 has a VI called "Read ALL loop_elements gIDs recursive.vi" which is the recursive VI. It is currently set in VI Properties > Execution > Reentrant execution to "Share clones". If you change this to "Preallocate clones", select OK then try to save the VI, LabVIEW will crash.
Hi Thoric,
Thanks for posting your project. I am also seeing the crash with 2010 SP1. I wanted to make sure the crash isn't still present in the latest version. Fortunately, the crash does not happen in LabVIEW 2011.
Chris M
修改时间 - 上次编辑时间 编辑者
Content Cleaner
richjoh wrote:I have not opened your VI's but I remember using LV2010 (not SP1) you get broken arrow whenever a reentrant class member is set reentrant with Prellocate clones set. I was forced to use Shared Clones only!
That is the expected behavior. Recursive VIs must be set to share clones reentrant execution. This is because LabVIEW cannot know ahead of time how many instances of a recursive VI will be needed. Using the share clones option allows clones of a VI to be created on demand, which makes recursion possible. There is some more info on creating recursive VIs here in the LabVIEW help.
Chris M
@richjoh wrote:Are you saying your saving a broken VI in LV2010 SP1?I have not opened your VI's but I remember using LV2010 (not SP1) you get broken arrow whenever a reentrant class member is set reentrant with Prellocate clones set. I was forced to use Shared Clones only!
Richjoh, yes, when I choose to save, the VI is saved and then LabVIEW immediately crashes (disappears). If I then restart LabVIEW and reload the VI, it loads ok (no broken run arrow) but you cannot ever save again because LabVIEW will always crash. This means that LabVIEW is indeed saving a corrupt VI.
Once the appropriate reentrancy setting is chosen (Share Clones) and the VI recompiled, everything is fine
This does appear to be a bug in 2010 (SP1). Why it works for you and not me is a mystery.
