LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Calculating intersection of circles giving NaN first 'round'.

Solved!
Go to solution

See attachment.

When I give the correct parameters as input, the output is always NaN.

However, when I run the VI again, the correct x,y coordinates are returned.

Obviously this is not correct behaviour I want in my VI. What did I do wrong here?

 

Thanks,

Marvin

0 Kudos
Message 1 of 5
(2,786 Views)
Solution
Accepted by topic author marvin117

It's your use of local variables.  Even though a Sequence structure is designed to make you think that everything will happen in order, it's just an illusion.  All of the local variables are read as soon as the VI is executed, but they're all zero until the calculations take place.  Wire your results and dump both the locals and the Sequence structure and you'll have what you expect.

 

Oh, and, race conditions.  Something to keep in mind as you learn to program in LabVIEW is that you'll rarely need a local variable.

Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

Message 2 of 5
(2,778 Views)

Thanks, I'll try this.

What's the point of local variables if they don't work that way? I'm used to OOP, so for me this takes some getting used to.

0 Kudos
Message 3 of 5
(2,764 Views)

@marvin117 wrote:

 

What's the point of local variables if they don't work that way?


Although local variables are often demonized, there are proper uses for them.  Coming from a text-programming background, you're used to using variables and, presumably, not accustomed to things happening in parallel.  The first thing I noticed, which is certainly not obvious to anyone, is that your local variables are read in every frame of the Sequence structure immediately, but the indicators aren't written until the calculations happen in the first frame.  In this way, the Sequence structure is highly non-intuitive.  National Instruments owes you an apology for that.

 

The second thing I noticed was, in your second frame, that you were using the results of calculations with a local variable in the same frame.  You'll never be able to know that the calculations will happen before the locals are read.  There's your classic race condition.

 

I (almost) only use local variables to update front panel control values.  If I find myself using them to read control values, I hang my head and wish I had designed my code better.  Try to think in terms of "The wire is the variable."  It's almost always the right way to think about data, and data flow.

Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

0 Kudos
Message 4 of 5
(2,750 Views)

Hi Jim,

 

I found the problem in my code. 

In the original 2nd frame I used a local variable of an indicator (p) I calculated in the same frame.

I moved the bottom part to a new frame, which solved my problem.

Thanks for the insight though.

 

Regards,

Marvin

0 Kudos
Message 5 of 5
(2,722 Views)