How to read the "zMatrix" property of CWGraph3D object

[550nm]

Greetings,

Once a 2D array is written to "zMatrix" using CWGraph3D.Plot3DSurface, is it possible to read-back the value of zMatrix?

I'm attaching a VI that uses the CWGraph3D control.

Notice the zMatrix output of Plot3DSurface - is it possible to invoke this function to obtain the current value of "zMatrix" and without changing it?

Any help is appreciated!

[KathrynTheGreat]

Hi 550nm,

It looks like when the 2D array is sent into the Invoke Node, it’s being converted to a variant. Because of this, if you were to right-click on the output for zMatrix and choose Create> Indicator, LabVIEW wouldn’t know how to display the data on the front panel. Because variants are very generic datatypes, if you’d like to create an indicator for that value, you’ll want to convert it back from a variant to a 2D array of longs- one method for converting the output is illustrated in the snippet below.

As far as reading the current value without writing to it, is there a reason you can’t just branch off of the wire that feeds into the Invoke Node and use that instead?

[Ben]

Answering your specific question and assuming you have only the CWGraph3D with the data saved as the default...

I never figured out how to get in directly but I did figure out how to move a cursor around on the surface to "probe" each point and read the Z value one at a time to re-assemble the matrix.

So it can be done but not in a way that is graceful.

Ben

[550nm]

Hi Ben, KTG,

I'm using a functional-global to "manage" the CWGraph3D and that global is storing a copy of the zMatrix-data in a shift-register ( the control's reference is also stored in a shift-register).  Sometime after the 2D data is rendered, the user may request an arbitrary cross-section of the data.  Right now I'm getting the cross-section from the [shifted] copy of the original 2D array.  The FG could be coded a little more efficiently if I could reuse the zMatrix value stored in the CWGraph3d control.

Ben:

That's a very creative solution! (however...).

I suspect it would necessarily be a "lossy" conversion as data-density exceeds cursor position resolution.

Thanks again for your efforts.

Cheers!