Jake, thank you very much, very useful example cdl-file, I will use it for my UDE.
But, when I wrote "impossible in NX85", I mean not UDE dialog box, but customised dialog for sub-operation in probing.prt template. Looks like UDE, you can add integer, double, point, vector, but - impossible to add image or "help" link.
I think - good idea for NX developers for future versions NX.
Thank you and my KUDO.
We use UDE to control the use of the standard Renishaw macro's, we have standard cycles that are called from template.
From here we can then use Gauge pointing for in cycle measuring and level checking which is a custom operation using the standard macro's and a few arguments thrown in.
We have found this to work well for us and behave in a robust manor we have also added pictures to the UDE for one of our machine types.
This is all in NX7.5 and controlled via postbuilder using the internal Tcl code.
Hope this is of some benifit.
I'm still tweaking and enchancing the posted output of the Renishaw probing cycles with NX UDEs. I'm trying to get standard output for checking the setup before running the program. My issue is that when I have multiple points defined in the cdl file they seem to change what is passed to the post depending on what point is toggled on or off. Has anyone else run into this issue?
Here's an example.
with all points toggled to "ON" note my probe_z_value_flag position in z is ~0.3"
mom_probe_stk_pt_1(0) = 0.00000000000000000 mom_probe_stk_pt_1(1) = 0.00000000000000000 mom_probe_stk_pt_1(2) = 3.10000000000000010 mom_probe_stk_pt_2(0) = 5.99999999999999910 mom_probe_stk_pt_2(1) = 5.99999999999999910 mom_probe_stk_pt_2(2) = 3.10000000000000010 mom_probe_stk_pt_3(0) = 1.50000000000000090 mom_probe_stk_pt_3(1) = 1.49999999999999930 mom_probe_stk_pt_3(2) = 2.99999999999999960 mom_probe_z_value_flag(0) = 5.99999999999999910 mom_probe_z_value_flag(1) = 0.00000000000000000 mom_probe_z_value_flag(2) = 0.30193401522749902
same exact UDE only I now toggle probe_stk_pt_3 to "OFF"
mom_probe_stk_pt_1(0) = 0.00000000000000000 mom_probe_stk_pt_1(1) = 0.00000000000000000 mom_probe_stk_pt_1(2) = 3.10000000000000010 mom_probe_stk_pt_2(0) = 5.99999999999999910 mom_probe_stk_pt_2(1) = 5.99999999999999910 mom_probe_stk_pt_2(2) = 3.10000000000000010 mom_probe_z_value_flag(0) = 1.50000000000000090 mom_probe_z_value_flag(1) = 1.49999999999999930 mom_probe_z_value_flag(2) = 2.99999999999999960
It now puts the value that was in probe_stk_pt_3 into probe_z_value_flag and my z value is 3.0"
This is super annoying. How do I know if the values I have are valid or not?
Am I doing something wrong? Is this a known issue? If so is there a work around?
if you have a param toggled, FIRST chaeck the state of the "_defined" variable -
should be true/false (1/0) if it is (or isn't) toggled.
Why the values are in the wrong variables? - I'd contact GTAC with a simple case as shown - could be a bug
Production: NX10.0.3.5 MP16/TC11.2
I'd rather be e-steamed than e-diseaseled
That's not what I meant when I said I don't know if the numbers are valid or not, I'm checking to see if they are toggled. The post is doing a boolean check with the xxx_defined variable and it will change what values the post uses for the cycle output based off the result.
I'm saying that I don't know if one of them was turned on/off and I'm getting bad numbers. I was hoping someone had run into this and knew of a solution. I'd figure with you being the local guru around here if anyone had run into this it's be you
Oh well, I guess a call into GTAC it is.
We are probing on both fanuc and mazak. The macros are several different series of numbers, PQI had to install them whever the machine tool builders left open space. We have 94XX, 95XX, and 98XX I'm just setting a base number in the machine post and calling the cycle with subsitution like this
G65 P[expr ($base_number + 10)] Z$mom_probe_clearance F$mom_probe_fast_feed
What limitations are you refering to?
I have read that there are limitations with certain controllers, I didn't know if this was a cause of the issue you were having? given the controllers you are using I can't see this as being the problem.
We too use all custom UDE's to handle all our probing requirements using the same method as you do G65P9811 D** R** and so on.
Being still fairly new to the TCL language I have had some success (and a few more head scratching moments!) with getting the relevant data to output in order to keep the shop floor happy.
Sorry this has been no help.