Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations waross on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

G03 interpreted as linear move. 3

Status
Not open for further replies.

knobhead

Aerospace
Mar 6, 2001
184
0
0
GB
Can anyone tell me why my integrex 200y is deciding that the G03 commands in this program would be intrepreted as linear moves? This code just machines a diamond shape.

I'm totally confused.



T0101
S5372 M203

M212
G00C0.0 X100.0 Z10.
M210
G00 X0.00 Z5.0


(Fast feed to depth)
G01 X0.000 Y0.000 Z-11.500 F1671.3
(Feed to arc in start adding rad comp)
G01G41 X2.241 Y-2.241 Z-11.500 F835.6
(Arc on)
G03 X4.481 Y0.000 R2.241 Z-11.476 F439.4
(Machine thread)
G03 X0.000 Y4.492 R4.492 Z-11.142 F439.4
G03 X-4.502 Y0.000 R4.502 Z-10.808 F439.4
G03 X0.000 Y-4.512 R4.512 Z-10.474 F439.4
G03 X4.523 Y0.000 R4.523 Z-10.139 F439.4
(Arc out)
G03 X2.261 Y2.261 R2.261 Z-10.116 F439.4
(Fast feed to centre removing rad comp)
G01G40 X0.000 Y0.000 Z-10.116 F835.6
(MOVE OUT OF JOB)
G00 X0.000 Y0.000 Z5.000
M205
M09
M212
G28U0.0V0.0W0.0





Excessive accuaracy is a sign of poor breeding. -Socrates.
 
Replies continue below

Recommended for you

yeah, it's odd rads because it's threadmilling. The actual moves are given by the tool manufacturer as the optimum to use.




Excessive accuaracy is a sign of poor breeding. -Socrates.
 
I've done a lot of thread milling, but never with that technique. What's the purpose?

Have never had a problem using a 360 degree G03 command combined with Z move of one pitch. I've seen more complex programming for tapered threads. Is yours a tapered thread?

Now you've got me curious!

Manufacturing Freeware and Shareware
 
Interesting. I laid the arcs out in AutoCAD, and if my interpretation of your program is correct, they don't share the same center point. Heree's what I see:

ARC Layer: 0
Space: Model space
Color: 3 (green) Linetype: BYLAYER
Handle = 82
center point, X= -0.0110 Y= 0.0000 Z= 0.0000
radius 4.4920
start angle 0.000
end angle 89.860
length 7.0450

ARC Layer: 0
Space: Model space
Color: 3 (green) Linetype: BYLAYER
Handle = 85
center point, X= 0.0000 Y= -0.0100 Z= 0.0000
radius 4.5020
start angle 90.000
end angle 179.873
length 7.0617

ARC Layer: 0
Space: Model space
Color: 3 (green) Linetype: BYLAYER
Handle = 88
center point, X= 0.0100 Y= 0.0000 Z= 0.0000
radius 4.5120
start angle 180.000
end angle 269.873
length 7.0774

ARC Layer: 0
Space: Model space
Color: 3 (green) Linetype: BYLAYER
Handle = 8D
center point, X= 0.0000 Y= 0.0110 Z= 0.0000
radius 4.5230
start angle 270.000
end angle 359.861
length 7.0937


Don't really know what to make of it.


Manufacturing Freeware and Shareware
 
Ok, should have put a bit more backgound in here...

It is a taper thread, it's for a 3/8-19 BSPT.

All the thread mill code I've seen from tooling suppliers do the weird thing with offcentre arcs. One guy did explain why, and it was a good reason, but I've forgotten it! Maybe something to do with follow on error, I'm not sure. I do a lot of NPT threads using a similar method. (which works!)

I've tried:

Taking off the comp to see if that's doing something strange.
Reprogramming it in incremental mode.
Taking off the Z moves, so it's just a straight circle.
Reprogramming it using I and J instead of the R value.
Knocking the feed rate right down to see if it's something to do with it ramping up to speed.
Putting stupid values in the offset table,just to try and see whats going on.

Everyone at my place is stumped. I think I'm going to have to tap it, but it's still annoying.


Excessive accuaracy is a sign of poor breeding. -Socrates.
 
Some threadmill examples have a lead-in and lead-out. Gibbscam kicks it out like this also. Here's an example of how I manually program a threadmill, no lead-in or out.

(.250 DIA THD MILL)
G0G90X0.0Y0.0 ( just happens to be at origin )
Z2.350 ( rapid into part )
G1G41D40X0.5313F3.0 ( cut to start of circle )
G91G3I-0.5313Z0.055L7 ( circ interp 7 threads incriment in Z, calculated to come out of hole)
G90
G1G40D40X0.0F10.

Good luck,
 
It looks like you are starting at the bottom and working out trying to cut a spiral.
Although we have never thread milled a pipe thread, I would start at the top and work down using the taper ground into the cutter rather than programming a spiral. The code you have does not look like it will cut a spiral either.
 
Thanks for all the replies, much appreciated!

But the problem isn't the thread milling - it's why is my machine going in straight lines when I call a G03? It should just error out if there is a problem with the code, so what's going on here?


Excessive accuaracy is a sign of poor breeding. -Socrates.
 
I can't answer the question about why it's milling a diamond shape.

If you're using a CAM system, can you force it to output a lot of small linear xyz moves in place of the G03's? I've had to do that in the past with controls lacking helical interpolation. If you have a lot holes to do on the workpiece, you could make it an incremental subroutine to conserve paper and control memory.

Manufacturing Freeware and Shareware
 
EdDanzer,

We were told by a sales/tech. guy to threadmill from the bottom up. I believe his reasoning was that if chips build up in the hole, you'd be sending the threadmill down into them (possibly crashing the tool or at a minimum recutting chips). But to be quite honest, the chips the operation produces are very small so the chances of it really making a difference which z-direction you do are probably negligible.

Ken
 
knodhead,

I don't see anything wrong with your code either. Maybe it's got something to do the the tool diameter or the cutter comp.? I'd try this: program in a (much) smaller tool diameter and see if you still get a diamond shape. If that reveals nothing, then program in a tool diameter of zero. Next I'd try deleting out the cutter comp. all together.

I suppose after that I'd try a slimmed down version of your program with just the linear move to the arc start point and then do one arc. See if each one of those behaves correctly?

Just trying to eliminate possibilities since I have no idea either. We messed with our Fadal for 2 days one time trying to figure out why it was acting strangely when doing a 600" radius arc (output from our CAM for a 3D surface). Turned out that a Fadal is not capable of cutting an arc larger than 400" (maybe they fixed that one on the new machines, but as of 1998 they had that limitiation).

Let us know if you find anything else out.
Ken








 
When I compile the program, I get the following error: ERROR: CIRCULAR_TRAGET FULL

I get this on every G3 in your program, but not exactly sure what it means.


If I'm understanding correctly, you want to do a HELICAL move. Here is what my help file says:

--------------------------------------------------------
Helixes and Dual Circular Motion

To produce helical interpolation it is necessary to program two axes to generate circular interpolation and a third axis to generate linear interpolation. This is accomplished by specifying a G2 / G3 (or G12 / G13 ) and a G1 on the same line.

Also, the user can specify two circles to execute simultaneously (on four different axes) via the second coordinate system G12/G13 circular commands. However, in this case the F feedrate determines the velocity for the circular motion in both coordinate systems.

Note: To produce a helix or dual circular motion, the G codes and their associated parameters must be grouped together, as follows:

G1 Z5. G2 X1. Y. I1 J0. F100. ; Helical motion
G2 X1. Y1. I1. J0. G13 x1. Y1. I1. J0. F100 ; Dual circular motion

In other words, the parameters to the G1 command must follow the G1 command, the parameters to the G2 command must follow the G2 command, the parameters to the G13 command must follow the G13 command, etc.
--------------------------------------------------------

I went an inserted a G1 before the Z and the errors went away. Not sure if this is the correct solution.


 
knobhead,
I've got another senerio to try, get the tool to the start point and the program the thread cutting in incremental mode (G91) and see if that matters.
Ken
 
Ah ha!

Servocam, your post made me think maybe there was something basically wrong with my G03 call to do a helix.

So, I bracketed out the Z move just to see what happened.
Still straight lines.

Tried the G01 before the Z. Um, just went weird and moved all over the place.

So, I tried using a G3.1 (helix) instead of G03
Error, this control doesn't recognise a G3.1

Right, so I've turned off the comp, and made the G03 as basic as possible, and it still goes in straight lines.
I must be missing something fundamental here...

Dug out the manual and looked up helical interpolation in case the integrex has some weird foible about them.

Yes it does, it insists you define the plane with a G17 in the G03 line.

So, tried that and then it errors out on the comp. You can't select a plane with comp on. Bracket out the comp call and it does circles. Getting somewhere!

Right, so why is the G17 plane selection I always put at the top of the program not being picked up...

..ah. Because I've missed it out. [ponder]

Problem solved!

Thanks everyone for all your help and suggestions!


Excessive accuaracy is a sign of poor breeding. -Socrates.
 
kenbolen, I've come across that degree limit too on fadals. Another one is don't ever put more than 15 lines of comment in a program without a gap, or it won't run.

Took me nearly a week to work that one out!


Excessive accuaracy is a sign of poor breeding. -Socrates.
 
Sorry, I missed the pipe tap comment. Why we go from inside out is the chip issue of course and it's easier to see what's going on on a new program. I didn't hink about it, but I probably could have cut and pasted your program in Preditor and back plotted it.
 
Status
Not open for further replies.
Back
Top