cancel
Showing results for 
Search instead for 
Did you mean: 

Probing with udes - op of choice

Phenom
Phenom

I recommended generic motion to a customer to create probe sequences. On his system - it was unusable because every move you make (say creating a subop) - there would be long pauses. I have noticed this before - it may have to do with tool models - but in this case we made the tool a barrel mill parametric. My system (laptop/no network files) - generic motion moves faster.

 

So - I told him to use Mill Control (Op) and Goto ude's to move around - the problem with this is that the motion created with these udes does not set mom_out_angle_pos to drive rotaries - the mom_tool_axis is there - but NX seems to fail to set the rotaries. The variable mom_sys_abort_next_event is set by NX (in this case) and the move is aborted. All other ops/moves at this orientation are fine with my kinematic setting. Plus the goto ude is togh to work on - since it looks like a ude - but comes out of NX as motion events. There is no goto ude event fired.

 

How do other people use probing udes (in what op?) Do you have these problems?

 

NX10.03
Windows 7 Pro
6 REPLIES

Re: Probing with udes - op of choice

Esteemed Contributor
Esteemed Contributor

Roughly...

I add the UDEs to drill ops (legacy, not holemaking).

Set the cycle to "standard text", then set depth appropriately

Except for probing holes, use "generic points" & set tool axis (typically I don't allow changing rotary axes WITHIN an operation, as Renishaw "safe moves" don't seem to support rotary motion, although I may be wrong on that)

 

Then over-ride proc "MOM_drill_text_move".  Add checks - if probing UDE variable exists (different ones for each probe cycle) then call the appropriate routine to handle that cycle.

You have mom_pos (point on surface), mom_cycle_rapid_to_pos, and mom_cycle_feed_to_pos to get positions.  D"Stanard text" cycles will automatically handle rotary output

 

I also add a PB_CMD_* to linear & rapid move events to over-ride the normal G1/G0 output with calls to the "safe move" macro (9810 or whatever).

 

You'll need to handle when to turn on the "safe move" mode (I use the probe UDEs relative to Start_Marker & avoidance "Start" point) and turn it off (end of path before any "go home" motion)

Hope this gives you enough info...

Ken Akerboom Sr CAx Systems Engr, Moog, Inc.
Production: NX10.0.3.5 MP5 + patch/TC11.2
I'd rather be e-steemed than e-diseaseled


Re: Probing with udes - op of choice

Phenom
Phenom

Hi Ken,

Yes - point to point cycles may be a good option. Especially for a series of single point touches with the same probing requirements. Especially touches along the spindle axis. Not sure how that would look with radial touches - and where tool axis would come from - probably a vector in the ude.

Dan  

NX10.03
Windows 7 Pro

Re: Probing with udes - op of choice

Esteemed Contributor
Esteemed Contributor

Note tool axis can come from the PTP cycle, depending on how you define it ("normal to part surface" works well, but only for ONE surface at a time.  And sometimes it is rather dumb and uses the wrong direction).  Note you can add "avoid" geometry in-between specific points to get larger clearaces if needed

 

Another option I used (once) is variable axis contouring -> Point (point/curve) drive method.  Set intol/outtol to huge values (10 inches+) so you ONLY go to the selected points (also set max distance between points to huge value, also angular change between points to large value).  Tool axis normal to part. 

You have to watch out for NX adding points in-between what you selected.

Also (I think) it requires a minimum of 2 points per operation.

Ken Akerboom Sr CAx Systems Engr, Moog, Inc.
Production: NX10.0.3.5 MP5 + patch/TC11.2
I'd rather be e-steemed than e-diseaseled


Re: Probing with udes - op of choice

Phenom
Phenom

Hi Ken,

 

What I mention about tool axis means if I use a cycle for an X touch - the tool axis (if it comes from the point vector) would show the drill 1/2 into the part (if touch point is the cycle point.) And all the cycle related points would be in the Z direction - where I would want them in X. Like I said - if probing points along the spindle axis - I think ptp cycles translate well - otherwise - not so much. I think I would have to set a tool axis vector for the post to use for each touch - other than the cycle point vector. Maybe I am not visualizing what you are explaining. I know that ptp cycles would be quick to program for probing when it matches requirements.

 

Thanks, Dan

NX10.03
Windows 7 Pro

Re: Probing with udes - op of choice

Esteemed Contributor
Esteemed Contributor

Ahhh...*that* direction :-)

I have the user select the PROBING direction in the UDE.

If (typical mill case) Tool axis is 0,0,1 (up Z axis) then handler for output:

1) positions to mom_cycle_rapid_to_pos

2) adds move sideways (opposite probing direction) (distance also a param in UDE)

3) adds move down to mom_cycle_feed_to_pos(2) (corrected for probe tip or ball center as desired)

4) outputs call to probing routine

5) adds move to point (2) above

6) Adds move to mom_cycle_rapid_to_pos (so tool is where post thinks it is)

 

Ken

Ken Akerboom Sr CAx Systems Engr, Moog, Inc.
Production: NX10.0.3.5 MP5 + patch/TC11.2
I'd rather be e-steemed than e-diseaseled


Re: Probing with udes - op of choice

Phenom
Phenom

Yes that seems to be a workable method. Thanks.

NX10.03
Windows 7 Pro

Learn online





Solution Information