Hello Guest it is March 02, 2021, 06:52:56 PM

Author Topic: g16 / g83 interaction ??bug??  (Read 7993 times)

0 Members and 1 Guest are viewing this topic.

Offline rcaffin

*
  •  1,035 1,035
    • View Profile
Re: g16 / g83 interaction ??bug??
« Reply #10 on: April 26, 2011, 09:43:55 PM »
> Wait till you try tool radius offsetting in the SUB (;-)
Ah ... pass! Hairy stuff.

> OK I could not stand it I tweeked YOUR code just a touch and presto.
g83 X#28 Y#4 z[0-#29] q3 r1             % DRILL THE HOLE

Yes, that works, and is exactly what I posted in my first posting. One has to put the X and Y parameters in the g83 command itself to get it to work. I KNOW that.

But sometimes I want to make the XY movement first with the head way clear of the job, because there are bits in the way. It avoids breaking drill bits ... :-)

I can do it by using the code I have in my first posting: make the XY move with a g0 then do the drilling with g83 with the same XY coords in the g83 command. This is not in the manual.

Yes, I know that the g83 command could do the movement all by itself without a preceding g0, but it seems (I may be mistaken) that it goes first to the R height before doing the XY move. That can be disastrous for me (or rather, the drill bit).

The SW should be able to discriminate between polar coords and cartesian coords, and mostly does. In this case it gets confused. Perhaps Brian could comment?

Cheers


Offline BR549

*
  •  6,944 6,944
    • View Profile
Re: g16 / g83 interaction ??bug??
« Reply #11 on: April 26, 2011, 10:00:27 PM »
(;-) Sorry but I don't get your logic. In order to use the G16 you must move to the center point of the rotation.  That you did. You would rapid at a safe Zheight and that you did.

SO you have a clear path to the first drill point

The part I don't get is WHY do you need to Rapid to the first drill location  when the G83 is going to take you to the same spot anyway. AND follow that exact same path(;-)

Not to make light of your coding but I have never seen anyone do it that way with G16/15. I have ALWAYS seen it done as I showed you.

Just a thought, (;-) TP

Offline rcaffin

*
  •  1,035 1,035
    • View Profile
Re: g16 / g83 interaction ??bug??
« Reply #12 on: April 26, 2011, 10:19:20 PM »
> Sorry but I don't get your logic. In order to use the G16 you must move to the center point of the rotation.  That you did.
> You would rapid at a safe Zheight and that you did.
> SO you have a clear path to the first drill point
Yes.

> The part I don't get is WHY do you need to Rapid to the first drill location  when the G83 is going to take you to the
> same spot anyway. AND follow that exact same path(;-)
Not quite the same path. It seems that g83 goes to the R height FIRST - at least when I have been watching, then it rapids to the XY coords. If there is a clamp or a wall in the way ... cra$h tinkle. So I always rapid at a safe Z height first, then drop to near the surface before drilling. Yes, that means some of my drilling is done in cavities.

Of course, I may be mistaken about the sequence order, but I do have some broken drills and cutters lying around. So I am rather cautious.

Cheers


Offline BR549

*
  •  6,944 6,944
    • View Profile
Re: g16 / g83 interaction ??bug??
« Reply #13 on: April 26, 2011, 11:25:52 PM »
The Z height depends on your retract setting G98/99 It can be either the R setting OR the inital Zheight.

I agree it does pay to be cautious. Most youngster laugh when they see me do the dry run on the first part( mach does not have that option) But it has saved many a machine crash over the years.

I think what is happening is when you make the first move to the G16 polar point mach has set the rotation point. Then when you switch to the sub the G16 resets the rotation point during the G83 call and that confuses each consecutive call for a location.

About the same thing happens with Tool Offseting and the sub. The geometry of the offset is NOT carried over to the sub and mach gets lost and it gets worse with every loop throught the sub.

Have a good one,(;-) TP

Offline BR549

*
  •  6,944 6,944
    • View Profile
Re: g16 / g83 interaction ??bug??
« Reply #14 on: April 26, 2011, 11:54:37 PM »
OK I was able to work in your PREMOVE for you. Look at this approach. It will run multi subs each with the premove added.



#28=4
#36=4
#1=0.000
#2=0.000
#29=1
#3=[360/#36]   % define the angle step
#4=0         % zero the angle register

F100
G0 Z1
g0 x#1 y#2      % go to centre of this object
g16                 % GO INTO POLAR COORDS
G0 X#28 Y #4 Z1.000

m98 p192 L#36   % DRILL THE RING OF HOLES
g15                          % kill the polar angle bit
G0 X#1 Y#2
#1=[#1+10]
G0 X#1
G0 X[#1+10]  Z1.000
G16
G0 X#28 Y#4 Z1.000

m98 p192 L#36   % DRILL THE RING OF HOLES
G15
G0 X#1 Y#2
#1=[#1+10]
G0 X#1
G0 X[#1+20] Z1.000
G16
G0 X#28 Y#4 Z1.000

m98 p192 L#36   % DRILL THE RING OF HOLES
G15
G0 X#1 Y#2
#1=[#1+10]
G0 X#1 
m30

% this routine drills one hole at a polar position
o192
g0 z1                                    % prepare to drill
g83 X#28 Y#4 z[0-#29] q3 r1             % DRILL THE HOLE
#4=[#4+#3]                       % next angle

m99
%



Offline rcaffin

*
  •  1,035 1,035
    • View Profile
Re: g16 / g83 interaction ??bug??
« Reply #15 on: April 27, 2011, 12:09:36 AM »
It's 10:57 pm at your place. When do you sleep? :-) I'm in Australia: its the middle of the day here right now.

I should explain that the ring of holes is drilled over a grid of up to 8 x 4 = 24 centres. That explains why the X & Y values are parametric. The grid is of variable size too.

I will investigate the g98/g99 stuff before making any further comments. But it should be possible to get the g83 code to run as I was trying to do. Granted, keeping track of offsets and rotations is likely to be ... entertaining. :-)
Hey - who said that Mach3 (or Windows) was entirely bug-free anyhow?

Cheers

Offline BR549

*
  •  6,944 6,944
    • View Profile
Re: g16 / g83 interaction ??bug??
« Reply #16 on: April 27, 2011, 12:36:07 AM »
Actually it is 12:41 am here.  Working on Parametric code is a lot of fun.  Getting odd combinations of Parametric/Sub programing to work is even more fun(;-)

(;-) TP

Offline rcaffin

*
  •  1,035 1,035
    • View Profile
Re: g16 / g83 interaction ??bug??
« Reply #17 on: April 27, 2011, 04:34:21 AM »
Hi TP

Sorry, missed your reply. I was working on the CNC this afternoon. Only one USB/SS hiccup ... most annoying though.

Parametric code: fun, yes, but the only way to do production work. I need to machine batches of 18 - 20 units at a time, and lots of different ones. Multiple tools needed, and no auto tool changer on the machine. Ganging them up on the table is the only way of doing this with any pretense at cost-effectiveness.

The jump from parametric to subroutines is very easy for me as I have spent my life coding. Also, it lets me write the programs in the most efficient manner. Unrolling the loops would be horrible! And almost impossible to manage too.

Cheers
Roger

Offline BR549

*
  •  6,944 6,944
    • View Profile
Re: g16 / g83 interaction ??bug??
« Reply #18 on: April 27, 2011, 06:46:33 PM »
HAVE you thought about not using the SUB and just using the loop function for the G83 cycle.

It will work as well as the sub and is even smaller code block (;-)  I was playing with it last night as well.

In your method you do not need the X call after you make your prestage move BUT the G83 DOES require the Ycall (polar index value). Mach tracks the Offset value of X but does not store the polar index value.

IE:   G16
       G0 X#28 Y#4 Z1.0
       G83 Y#4 Z-1 Q.05 R1 F10

To use the Canned cycle loop method You program the canned cycle in incremental mode G91 and the value of 4 becomes the amount to index each loop. It will miss the zero point in the circle but you program 1 extra loop to drill the empty space.

G16
 G0 X#28 Y#4 Z1.0
G91
G83 Y#4 Z-1 Q.05 R1 F10 L4
G80 G90


Just a thought, (;-)TP

Offline rcaffin

*
  •  1,035 1,035
    • View Profile
Re: g16 / g83 interaction ??bug??
« Reply #19 on: April 27, 2011, 07:39:04 PM »
In your method you do not need the X call after you make your prestage move BUT the G83 DOES require the Ycall (polar index value). Mach tracks the Offset value of X but does not store the polar index value.

I am very conscious that my knowledge of g-code programming is limited, and I had completely forgotten about the L option in g83. Thank you for reminding me. However, it does not solve all the problems - at least as far as I can see.

What g83 does do is peck drilling with a retract to the defined R position at the end. If I loop that with the L option, the traverse to the next hole is done with the drill tip at the R height. But sometimes I need to retract the drill tip another 20 mm up before doing the traverse, to clear things. I could put R=20 , but that then wastes a lot of time for every hole and for every peck move. It wastes a lot of time doing the slow feed from +20 mm  down to the surface in multiple peck cycles before it starts drilling, and it also wastes a lot of time doing the retract/return over the extra 20 mm on each peck cycle after that. What I would love would be two more parameters:
Z: where to drill to (existing)
R: where to retract to for clearing swarf (existing)
T: where to retract to for the next traverse
S: where to rapid feed to before starting the drilling
This is unlikely to happen!

Fortunately I can achieve all of this with a full subroutine call. All I have to do is to over-ride the bug in the mach3 implementation of the g83 code by directly specifying the current XY position inside the g83 command.

To explain what is happening in the code: specifying the XY values in the g83 command over-rides the default fetching of a stored previous XY position. The bug is that it fetches from the wrong data structure - it fetches from the 'final cartesian' data structure rather than from the 'last program-specified data structure'.

In more detail, what then happens is that the g83 command assumes the 'final cartesian' XY values it has fetched are polar values and converts them into cartesian values because it knows it is in polar mode. Specifying the current XY position in the g83 command over-rides the default fetch and passes genuine polar values to the code.

But I must remember the L parameter in future. It will be useful somewhere, I am quite sure. Thanks.

Cheers
Roger