Two reentrant subVIs in separate time loops causes a crash. What am I doing wrong?

[TaurusTiger]

I am new to LabVIEW, but I am not new to programming.  I have a degree in Computer Science and experience in many languages.  I ported code from Python 2.5 to LabVIEW 2009 f2.  See the Python code below:

def fibonacci( n 😞

   if n == 0 or n == 1:  # base case
      return n
   else:

      # two recursive calls
      return fibonacci( n - 1 ) + fibonacci( n - 2 )

number = int( raw_input( "Enter an integer: " ) )

if number > 0:
   result = fibonacci( number )
   print "Fibonacci(%d) = %d" % ( number, result )
else:
   print "Cannot find the fibonacci of a negative number"

The program takes a numeric input greater than or equal to zero and returns the integer at index(input) in the Fibonacci sequence.  The LabVIEW version of this program works without any unexpected issue.  I tested input values from 0 to 20.  Input values beyond 20 take a great deal of time, and I know at some point the recursion would blow the stack and fail, as it does in Python.  I am satisfied with the results there.

My system has two cores.  I decided I wanted to try forcing code execution on different cores.  My rouble began when I decided to use Timed Loops to force the calling of SubVIs to different cores.  Initially I set the Processor input to -2.  This setting worked for the inputs 0 to 9.  An input value of 10 causes LabVIEW 2007 f2 to stop responding for hours.  I tried setting the Processor input for each loop to a different core (0 & 1). I have also tried setting the Processor input to the same core.  I get the same results each time, 0-9 works and 10 fails.

I have attached the VI for review.  Your feedback will be greatly appreciated!                   

[Ben]

i get a hard crash when I try your code with a value of "10".

I seem to recall reading about a bug with timed loops and re-entrant VIs. You may want to check the Known issues list.

Ben

[TaurusTiger]

You are quite correct. Naturally, there is a list of known issues.  I checked the issues which applied to timed structures and reentrant VIs.  I don't think  any of them apply to the VI posted.  Do you have another idea I can look into?  Thank you for your response!

~Bill

[Ben]

1) Toss the timed loops.

2) Wait for an NI App Engineer to reply to this thread to confirm or denigh new or old bug.

3) Log a Call with NI support and get an Ae to look at it now.

I saw no other options.

Ben

[Hueter]

TaurusTiger

Thank you for reporting this error with reentrant VI's in timed loops. This issue has been reported to LabVIEW R&D (CAR 201244) for further investigation.

Is there a reason you wanted to use timed loops for this application? Is there a need to explicitly divide the load between cores and not just let LabVIEW do it automatically? Please let me know if you need to help find a work around. Here is the standard LabVIEW recursive Fibonacci calculator.

Hunter | Applications Engineer

[TaurusTiger]

Hunter

I am happy to read the issue has been reported to LabVIEW R&D (CAR 201244) for further investigation.

The VI was a professional exercise to help me explore LabVIEW as a programming language.  I was able to port a common example from a text based language to LabVIEW successfully.  I am very pleased with the results there.

 

I remembered the talk about parallelism at NI Week in 2008.  Programming parallel operations in most languages is complex.  I know LabVIEW does it automatically, but I wanted to try dividing the recursive operations through LabVIEW code.  I didn't think the recursive example would give it any trouble. 

 

I do not currently have a project or future product the algorithm applies to.  I suspect others might have a need for it, and I would venture the algorithm could be applied to a future product.  I am curious as to what the work around would be; but at this time, I will not actively pursue a work around.

Please keep informed about if a work around comes up and or about the status of the error. 

 

Thank you for your response, Hunter!

  

Sincerely and Respectfully,

Bill