Results from contourc in MathScript not match

[MengHuiHanTang]

Tom, 

Thanks much for the effort. That overlay image explains a lot. It seems that both contour lines,either from LabVIEW or Matlab, have a lot of duplicate or near-duplicates points along the line. I don't know why it is, but I don't see any reason to keep the duplicates. I will have to try it out in the program. 

My application is an object shape calculation algorithm. So the first step is to get the contour line of the shape, sample some points along the contour and do the calculation. I will have to try before I can say for sure whether this point reduction affects the result. Do you still have that VI whose front panel you showed in your post to overlay the contours from LabVIEW and Matlab? I can run more images to confirm what you said. 

Again thanks for the help. I will continue the experiment. 

[0utlaw · Accepted solution]

Hi MengHuiHanTang,

I no longer have that code (looks like I forgot to save before an auto-shutdown), but here's the basic process once both contours have been generated:

1) Remove the first column from the arrays (as it's not a point on the contour line)

2) Cast all double-precision values to integers of some sort

3) Swap row 1+2 in one of the sets of points so that the x- and y- coordinates match.

4) Step through the contour lines generated and eliminate duplicate points (if you've got LabVIEW 2012 then I highly recommend the conditional loop terminals, I'm fairly sure I also transposed the arrays before auto-indexing them.)

5) Extract the x- and y-rows and bundle them together

6) Plot on an XY Graph

That's just a rough outline, the order of operations isn't particularly important for steps 1-4.  If I have time to re-create it I'll definitely post it!

Regards,

[MengHuiHanTang]

Tom,

Thanks again.

I do have another two questions about MathScript Node.

1). Can the .m code within the mathscript node run in parallell mode, say in a FOR loop?

2). Is it true that there is an equivalent VI for each Mathscript function? Like what you showed me, for the contourc function in MathScript, there is the 'Contour Line.vi' in LabVIEW which generates very close results. What about other functions, such as 'gradient', 'difference', and other basic functions?

[MengHuiHanTang]

I do have another two questions about MathScript Node.

1). Can the .m code within the mathscript node run in parallell mode, say in a FOR loop?

2). Is it true that there is an equivalent VI for each Mathscript function? Like what you showed me, for the contourc function in MathScript, there is the 'Contour Line.vi' in LabVIEW which generates very close results. What about other functions, such as 'gradient', 'difference', and other basic functions?

---

http://zone.ni.com/reference/en-XX/help/373123C-01/lvtextmathmain/rt_determ_guide/

I found this Mathscript guilde to be very helpful. And it answers my first question and also explains the best way to set the MathScript Node to be re-entrant. 

[0utlaw]

MengHuiHanTang,

I've attached (more or less) the same code used to create the overlay in that screen capture, hope it helps!

[MengHuiHanTang]

Hi, Tom, 

I have this question about the perfomance of MathScript Node. In the 'Guidelines for Using LabVIEW MathScript', it suggests placing MathScript Nodes in a time-critical VI to boost the performance.

Well, I have many MathScipt Nodes in a VI. (I cannot find the page, but I think I read somewhere that says it is better programming to keep each MathScript Node short. That's one of the reasons I have many nodes in a VI). 

My question is whether it is better to put each MathScript Node into a SubVI and make this SubVI time-critical, instead of putting all Nodes into one single VI. Or maybe it does not make much difference either way?. Thanks. 

[0utlaw]

Hello MengHuiHanTang,

Either approach should work; there is a very small amount of additional overhead when calling into a subVI, but relative to the time it would take to execute your code this should be negligible.

The real advantage to putting your nodes into individual SubVIs is that you can easily create reusable libraries out of the functions you create, and it will make it much, much easier to quickly look at and interpret your block diagram.  I believe it will also improve your load and compile speeds, since the SubVIs won't need to be recompiled when the top-level block diagram is changed.

In summary- yes, I think it would definitely be worth it to put each function you've designed into a subVI and I don't think there would be much of a runtime performance difference.