I am using a VI in the LV 2014 distribution called "NI_AALPro.lvlib:3D Coordinate Conversion (Scalar).vi". This uses DBL inputs and outputs, and has several Build Array functions in it as well as a Call Library Function. I need to perform a massive number of Cartesian to Spherical conversions with SGL values, and so I would like to re-write this VI using LV primitives in the most efficiant manner possible. The math appears to be quite simple, and I have attached a VI that does this. However, there is an issue with calculating the polar angle. From what I read online, it is just arctan (y/x), yet I get incorrect values when x is negative (but not when y is negative). From what I read on the Wolfram site, "the inverse tangent must be suitably defined to take the correct quadrant of (x/y) into account". I have searched online for more detail on the calculation, but I am lost. Any trig whizzes out there who can help me?

Definitions are extremely important in defining coordinate systems. The documents that you include with your Cart_to_Sph VI contain numerous mistakes and inconsistencies. Here is a convention that I use and that seems to have a reasonably wide acceptance (I'm not sure that this is the Wolfram convention, however). Let X, Y, and Z be a right-hand coordinate system. Let P be a point whose X, Y, Z coordinates we know. Define a Spherical Polar Coordinate (SPC) system as follows:Project a line from the Origin to P.Radius (rho) -- Length of the line from the Origin to P.Project the line onto the X-Y Plane.Azimuth (theta) -- Angle measured counterclockwise from the X axis to this Projected Line. By convention, theta ranges from minus pi (radians) to pi.Polar angle (phi) -- the angle between the Z Axis (or "pole") and the line from the Origin to P. By convention, phi ranges from 0 to pi.Under this coordinate system, the following code (very similar to Altenbach's, which uses a slightly different coordinate system) maps X, Y, Z into Rho, Theta, Phi:Let's check some "known quantities". Start with the Unit X axis, [1, 0, 0]. This clearly has length, Rho = 1. The X axis lies in the XY plane, so the angle between it and the Z axis is 90°, so Phi should be pi/2. Finally, the projection of the X axis in the XY plane lies along the X axis, so the angle between the two X axes is 0, so Theta should be 0. The first Re/Im to Polar will give 1, 0, so Theta = 0. The second will give 1, pi/2, so Rho = 1 and Phi = pi/2. How about Unit Z, [0, 0, 1]? Again, the length, Rho, is 1. Technically, since the Z axis projects onto the origin, the azimuthal angle cannot be properly defined (as both X and Y coordinates are 0), so we'll do a "math cop-out" and just say it's zero. The Polar angle is easy -- the angle between the Z axis and the pole, the Z axis, is 0, so Phi = 0. Now "do the math". Putting [0, 0] into the first Re/Im to Polar gives [0, 0], so Theta = 0. The second Re/Im to Polar takes [1, 0] into [1, 0], so Rho = 1 and Phi = 0. It is easy to show (especially by coding this up and putting in test numbers) that negative quantities work properly. Rho is always non-negative, Phi is always in the range 0 .. pi, and Theta is always -pi .. pi, with the sign dependent on the sign of Y (as it should be). Bob "Just Do the Math" Schor P.S. -- if you think this is fun, just try 3-D rotation matrices ...

LabVIEW

Efficiency of Cartesian to Spherical coordinate conversion

Solved!

When debugging is disabled, most likely all you see is constant folding due to use of diagram constants (the result never changes so the compiler calculates it only once). You should also wire some output to prevent "dead code elimination". If the result is not used anywhere, all code leading to it is eliminated by the compiler.

(If you come to NI week, come to my talk in room 15. :D)

LabVIEW Champion.