LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Calling Recursive Vi's

Solved!
Go to solution

Did not let it run to completion but AAA should be

 

Frequency 2000000000.000000
Frequency 2000000000.000000
Frequency 2000000000.000000
Frequency 2100000000.000000
Frequency 2200000000.000000
Frequency 2300000000.000000
Frequency 2400000000.000000
Frequency 2500000000.000000
Frequency 2600000000.000000
Frequency 2100000000.000000
Frequency 2000000000.000000
Frequency 2100000000.000000
Frequency 2200000000.000000
Frequency 2300000000.000000
Frequency 2400000000.000000
Frequency 2500000000.000000
Frequency 2600000000.000000
Frequency 2200000000.000000
Frequency 2000000000.000000
Frequency 2100000000.000000
Frequency 2200000000.000000
Frequency 2300000000.000000
Frequency 2400000000.000000
Frequency 2500000000.000000
Frequency 2600000000.000000
Frequency 2300000000.000000
Frequency 2000000000.000000
Frequency 2100000000.000000
Frequency 2200000000.000000

The order seems strange.

 

mcduff

0 Kudos
Message 21 of 27
(1,147 Views)

Try ABC, will make sense how AAA would work.

0 Kudos
Message 22 of 27
(1,141 Views)

Most of my time spent programming is protecting the user from entering crappy commands.

 

Not sure what you VI is doing, but yes, if ABC is entered then you get the right thing. But if the user enters AAC, what happens? Does your machine blow up? Does loop spin forever with no way to exit except ctrl-alt-del?

 

I highly recommend looking at Bob Schor's solution. His solution seems fail safe.

 

mcduff

0 Kudos
Message 23 of 27
(1,137 Views)

@Threshold10 wrote:

Based on your code you made a consecutive looping. I needed recursive looping.

 

Move the recurse inside the AMove the recurse inside the A.


Wow!  You really don't understand Data Flow, do you?  (Nor recursion, probably).  There is no difference in putting the Recursive Call inside or outside the Case Statement -- the "ABC" Case Statement executes one function, then the "Recurse" Case executes (most of the time) the Recursion.  Putting it inside the first Case Statement requires that the second Case Statement must be placed inside every Case of the ABC Case (which I didn't think was the idea -- you'd do A, or B, or C, and then Recurse on whatever is left, which is exactly what my code does.  What makes it Recursive is that the function calls itself.  The simplest way to call a function in LabVIEW is ... to put the Function on the Error Line and have Data Flow cause it to execute.  There are more "complicated" ways to call a function -- you could use VI Server (as you seem to have done), but why bother?  More steps, more places to go wrong, more confusion, harder to explain to beginners, ...

 

I took a look at your "Solution".  I don't "get it" -- it doesn't (to me) bear any resemblance to the problem you originally posed, but if you are happy with it, that's fine.  What I was hoping to do with my example was to demonstrate the close relationship between some recursion models (such as "Tail Recursion", which this demonstrates) and iteration.  A fun example to test if you understand what recursion is and how it works is to generate the number of combinations of N things taken R at a time, C(N, R) (these are also called "Binomial Coefficients").  The recursive formula to get them is C(N, R) = C(N-1, R) + C(N-1, R-1) with the "end case" being C(N, N) = C(N, 0) = 1.  [Note that N can't be negative, and R can't be negative or > N].  I understand that there's now a native LabVIEW Function to calculate this, but a recursive routine should beat the pants off any attempt to solve this using factorials (and doesn't need any multiplication nor division!).

 

Bob Schor

Message 24 of 27
(1,126 Views)

Just sets same parameter twice. All of this is done to generate a instrument queue of commands.

 

Its wastes cycles but if the user wants it, that's what he gets.

 

 

 

0 Kudos
Message 25 of 27
(1,123 Views)

Its a good idea to ask for more clarification on a problem if you don't understand the question.

0 Kudos
Message 26 of 27
(1,120 Views)

@Threshold10 wrote:

Its a good idea to ask for more clarification on a problem if you don't understand the question.


No argument there.

 

Although this wasn't a question, asking for clarification still applies.

 

Feels like a sneer at someone. I'm not against a little sneer every now and then (in good taste and good fun). But without reference to a post, it's not clear how your sneering at (if it was a sneer of course, could also be reflection). (Imagine a question mark here, or it won't be an official question).

 

0 Kudos
Message 27 of 27
(1,105 Views)