LabVIEW
circle concentricity
Solved!
I took a look at your code - I'm not certain it's doing what you want it to do.
Firstly, by wiring the 'i' value into your sin and cos, and then dividing by N, you're biasing your points to be in the positive quadrant. This can be seen very easily with small N. An alternative is to just wire the Random Number instead of random*i/N.
Secondly, your 'ovalicity' calculation doesn't do what the comments say it should. You specify in comments that it should be (Dmax - Dmin/Dnominal) but your calculation is for (Circumference - Dnominal)/Dnominal.
A simple way to fix this is to use the Complex Numbers instead of bundling X and Y, and then use Complex to R/theta to get R values. You can't measure D, since you won't necessarily have opposite points, but if you assume that for any point, D = 2R, then you can do as follows:
This still doesn't tell you that much though, because although now you have some noise in your points, if you take only one point (for example) the 'ovalicity' will be 0. The number of points will only be able to increase the error you measure. Maybe that's not unreasonable though.
In answer to the original question, I think you probably want to find the largest deviation from the nominal radius. You can modify the code in the snippet above quite easily to do this - subtract R from the array coming out of the z -> R,theta node, take the absolute values, and find the largest value.
Effectively what you're saying in that case is that all points do lie on exact, R radius circles, but that those circles might not all have the same centre. This movement of the centres of the circles is what is measured when calculating concentricity (the word being derived from con - "with, together" and centrum - "circle, centre" - wiktionary)
Hi,
Yes - that looks fine. Just double the radius values to get an estimate of diameter. For a true circle, you'd be fine with 2R=D. (note, you wrote R=2D - I think this is just a typo but be careful not to do it. 100 is the right value if R=50 🙂 ).
Like I mentioned, the problem here is you can't actually measure the diameter if you only have radius measurements, but doubling it seems reasonable, so long as what you have can reasonably be called a circle/oval.
You are not really measuring "ovality", but more something that depends on the difference between x and y noise. What's the purpose of all this?
You don't need any FOR loops to do all that. And to find the center and radius of a circle, simply use fitting on a sphere" with Z set to zero.
Here's a simple way to generate a noise circle, and fit it to get the center and radius. If you really have elliptical data, you should fit to an ellipse and get the two main axes. Are the axes aligned with the coordinate axes or can there be arbitrary rotation?
bhuvanesh1191 wrote:kindly see the ( ovality another method .vi ) and tell me .. where i wrote wrongly ?? send the modified VI to me ya .
I don't quite understand what you mean by that. Your VI seems to work and if you like your analysis better, you can add it to my VI. However, your analysis does not make any sense because you throw away any angular information and just look at the range of radii. It would also not work at all once the center of the circle is no longer at 0,0. The range of r in your case is only a measure of data noise instead of any measure of ovality. For correct result you need to include x and y direction into the calculation. You want to actually fit to an ellipse, you need to generate an ellipse, e.g. you could simulate a unit circle and then scale the x and y differently before trying to fit. Search the internet how to fit to an ellipse.
Some general code comments to your VI.
- You would turn off auto-scaling of the graph axes and make the graph area square, then set the axes so the x and y axis have the same range. This makes a square a square and a circle round and is much easier to look at.
- I don't understand why all your labels on the diagram are over-sized and underlined. Any particular reason? Very distracting!
- X-noise and y-noise controls belong before the loop because they should be treated as constant for the duration of your FOR loop. If you place them inside the loop, the compiler assumes that they can change at any time and it must re-read the terminal with every iteration. Very inefficient.
- Equal distributed noise does typically not exist for measured data. Noise typically has a Gaussian distribution. Use the signal generation tool to create Gaussian noise or use the box-muller transform two generate two random values with Gaussian probability from two 0..1 random values.
