Plotting more than 1 xyz surface in one diagram

[jtc]

Hello. I am trying to configure the following but I cant find the proper solution yet. Any advise from the forum I would greatly appreciate..

I have three identical systems as follows. I am using the concept of Spherical Coordinates. I have a fixed radius (R), an encoder sensor to give me Theta θ (0-360 deg), and a potentiometer sensor as Phi φ (0-90 deg).

Using Spherical Geometry I can calculate for the (x,y,z) for each system;

x = r cosθ sinφ

y= r sinθ sinφ

z= r cosφ

Kindly see the attached example VI.

I made a three stick with bases, height, pivot and endpoints to illustrate what i wanted to do.  If you will run the VI, and look on the top view of the 3D Curve (to check if the calculated XYZ points really are accurate), and rotate either knob 2 (sensor 2A) or knob 3 (sensor 3A), the calculated XYZ points are not the same with the location on the 3D curve.  For knob 1 (sensor 1A) its is accurate since the point of origin is at (0,0).

Am I missing any calculation? Is the representation of 3D curve in this example correct?

Thank you very much for any advise.

[RavensFan]

I think one problem you may have is some race conditions with your local variables.  It is possible that a local variable gets read before its value gets established in another part of the loop.  Instead of using local variables, you should wire from one part to another so that the order of operations is established.  Though I think in your case since there is only 1 writer, it may get straightened out in the next iteration of the loop.

You may want to consider creating some simple VI's that are re-entrant.  You are doing the same trig calculations on 3 different towers.  You are also doing the same array manipulations on the 3 towers to feed arrays into the object functions.

I don't understand why you cluster X1, Y1, Z1 and that becomes moving point 1.  But for systems 2 and 3 you take X2, Y2, Z2, add the base point foundations, then they become moving point 2 or 3.  Why isn't the base point foundation 1 added for the first system?

Both the front panel and the block diagram take up more than a screenful of real estate.  Sub-Vi's could help consolidate the block diagram.  Smaller controls might help for the front panel as well as tighter placement of the controls.

Why do the potentiometers go from 0-90 in your description, but the controls only go from 0-75?

Message Edited by Ravens Fan on 02-05-2007 12:17 AM

[RavensFan]

There is a big race condition problem.

Your moving points are set as controls, but they are also calculated through the functions of the other points and angles.  They should be set as indicators.

[altenbach]

Race condition is not a problem, because everything will rectify after 20ms (i.e. in the next iteration). 😉

Still, there is absolutely no reason for any of the local variables, you could just wire things up directly. There is also no reason to calculate Pi/180 6 times in parallel. It could be done once before the loop and the value reused everywhere.

The "moving point # xyz" on top of the VI are correct. The yellow xyz indicators are incorrect because you tap into the wire before the translation is done. Just unbundle "moving point2 and ...3" to get the real x, y,z values.

The attached modification shows one quick correction. It still needs to be cleaned up a bit.

[jtc]

Thanks Raven Fan for the comments.

To Mr Altenbach.

Thank you very much. You made it very simple. Now I can make multiple Towers in one diagram. I am very thankful.

bong

[jtc]

Sorry for the one star-----that should be five star...finger error....

[altenbach]

---

@bong wrote:

Sorry for the one star-----that should be five star...finger error....

---

Oh well... 😉

Anyway You probably noticed that you have large sections of repeated code. This makes code maintenance difficult, because if you need to change something, you need to change it is three different places. The diagram is also 3x bigger than it should be and the chance of an arbitrary wiring error is 3x higher and 3x harder to find later.

In this particular case it would be easy to write the code once, then repeat it in a FOR loop. You can use Built Array on your various indicators as shown in the attached simple draft. (Typically, you would make the controls and indicators arrays directly, so you can autoindex to do the repetitive work and don't need ot built any arrays on the diagram. Now expanding the code to e.g. four objects is trivial.).

Makes sense? 😄

[jtc]

Thank you very much for correcting my sample VI. Yes, adding two more towers was trivial. But this will be the case in actual, 1 to 5 towers operating simultaneously. I also added some boundary lines. But boundary lines are also a lot !!(i just showed two lines).

In this example, the function of auto-indexing is while the For Loop executes all the control data executes with the For Loop? (sorry, but until now i get confuse on how to use indexing)

On the other hand, when you do disable auto indexing means you are just passing the data inside the For Loop? Please correct me if my understanding is incorrect.

Again, thanks a lot.

[altenbach]

Autoindexing a 1D array at a loop boundary input means that the elements of the array are spoon-fed to the code inside the loop, one element per iteration. Iteration zero gets element zero, iteration 1 gets element one, and so on. The loop will run until the shortest of all autoindexing arrays runs out of elements (or you wired an even smaller number to N in the upper left).

On an autoindexing output tunnel, elements again turn into an array, one element for each iteration.

If a tunnel is not autoindexing, the data is passed as-is.

Autoindexing is one of the great basic LabVIEW features. 🙂

Always remember that controls and indicators have their own data copies, so they retain their value until specifically changed. If you look at your "boundaries" plot (#6), you'll notice that the data does NOT change during the FOR loop, so why should you draw plot #6 N times, once for each iteration of the FOR loop? Once overall is enough!!! Take the plot#6 before the FOR loop and draw it only once per iteration of the while loop.. If the "boundaries" never change during the run, feed it diagram constants and take it before the big While loop so it draws exactly once at the start of the program, which is plenty. 🙂

Message Edited by altenbach on 02-05-2007 06:34 PM

[jtc]

--------------------------------------------------------------------

Always remember that controls and indicators have their own data copies, so they retain their value until specifically changed. If you look at your "boundaries" plot (#6), you'll notice that the data does NOT change during the FOR loop, so why should you draw plot #6 N times, once for each iteration of the FOR loop? Once overall is enough!!! Take the plot#6 before the FOR loop and draw it only once per iteration of the while loop.. If the "boundaries" never change during the run, feed it diagram constants and take it before the big While loop so it draws exactly once at the start of the program, which is plenty.

--------------------------------------------------------------------------

Sorry for the mistake. I revised the attached VI. The boundary Control values are optional. Sometimes they are zero but sometimes i have to input number depending on the project site location. If i will have about 40 boundary control points (20 lines) which means i need to make 20 - 3D Curve.VI, Will this be the proper way to do it?