Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: rcaffin on April 25, 2011, 09:07:25 PM
-
Hi all
I am machining a lot of objects in a grid, so the code is quite parametric.
Each object has a ring of N holes around the middle.
So I have parametric code to go to the centre of each object, then a subroutine to run a ring around to drill the holes. For the holes I want to use g16.
If I code thus it fails with really wonderfully weird results. I have deleted non-critical parts of the program of course.
#3=[360/#36] % define the angle step
#4=0 % zero the angle register
g0 x#1 y#2 % go to centre of this object
g16 % GO INTO POLAR COORDS
g0 x#28 y#4 % GO TO 1ST HOLE POSITION AT RADIUS #28, ANGLE #4
m98 p192 L#36 % DRILL THE RING OF HOLES
g15 % kill the polar angle bit
m99
% this routine drills one hole at a polar position
o192
g0 x#28 y#4 % GO TO THE POLAR POSITION
g0 z1 % prepare to drill
g83 z[0-#29] q3 r1 % DRILL THE HOLE
#4=[#4+#3] % next angle
m99
The first hole is drilled correctly. Motion to the next position by g0 X#28 y#4 is also correct. But the g83 command moves to a different XY position even though no XY values are given for it. The manual implies that omitting XY values should use the current position, but clearly the Mach3 code for g83 is using a different XY position from what the g0 command created. Subsequent holes are all over the place.
But if I change the g83 command to explicitly include the polar XY values thus, it works smoothly every time
g83 x#28 y#4 z[0-#29] q3 r1
It seems that the g83 command is not able to handle the polar mode when it is in a subroutine. The examples in the manual do not use subroutines.
Has anyone else had this problem?
Cheers
Roger
-
Here is an example of using the G16/15 in a sub program. It drills 4 holes on a 4" radius 90 deg apart starting at 3 0clock from X0Y0
#1=0
G0X0Y0Z1
g16
M98 P1 L4
G15
G0X0Y0
M30
%
o1
g83 X4 Y#1 z-1 r1 F100
#1=[#1+90]
m99
%
(;-) TP
-
Hi BR
Yes, I know that works fine, but you have the X and Y positions in the G83 command.
The M3M manual states (via the example given) that you don't have to include them when using polar coords, but my experience is that you DO have to state them IN the g83 command itself, at least when using subroutines.
Cheers
-
I only declared them the one time that is REQUIRED to use the G16. SOMEWHERE you have to tell it the radius offset AND the rotation angle.
THe X value in the G83 defines the G16 Radius offset and the Y defines the G16 polar offset JUST like it is suppose to do. (;-)
(;-) TP
-
Hi BR549
Yes, I know you have to tell Mach3 where to drill the holes. In the code I quoted in my first posting I have these lines:
g0 x#28 y#4 % GO TO THE POLAR POSITION
g0 z1 % prepare to drill
g83 z[0-#29] q3 r1 % DRILL THE HOLE
What happens when this is in a subroutine, as shown in the first posting, is that the g83 instruction does NOT drill the hole at the XY position. It goes off elsewhere first, then drills the hole.
What I suspect is happening is that Mach3 converts the polar values into cartesian values in the first line here and moves the controlled point to that position. But when the g83 is being executed it forgets that the current XY position it has are cartesion values and converts them again into polar values - again! Obviously this will produce the wrong results.
I think this is what is happening because the farther away from the cartesian origin this subroutine is executed, the wilder are the errors. That is how it behaves, anyhow when I try to execute this in an XY grid of positions.
Why does this happen in my example and not in others? I think it is because the g16 call is NOT in this subroutine but in a higher level subroutine. A flag is not being passed correctly with the subroutine call, or perhaps there is some confusion over pointers to the different sets of coordinate registers.
Cheers
-
The G16 works just like it is suppose to work(;-) It is very specific as to what moves you can make AFTER the G16 is invoked. You are making G16 moves outside the sub then trying to get the G83 to run correctly from inside the sub. It aint gonna happen that way Sorry(;-) You cannot split the moves across the two sections of Main/Sub routines.
(;-) TP
-
> It is very specific as to what moves you can make AFTER the G16 is invoked. You are making G16 moves outside the sub
> then trying to get the G83 to run correctly from inside the sub. ... You cannot split the moves across the two sections of Main/Sub routines.
A valid comment, except that it does not apply here. I am making NO moves outside the subroutine. (Call a subroutine with M98 and you can't make moves outside the loop anyhow.) The only moves made in the XY plane are the g0 x#28 y#4 moves within the subroutine, and Mach3 correctly interprets that command as being in polar mode every time it is executed. The manual states that you must only make G0 and G1 moves. There is no fancy compensation of coordinate movement or rotation.
It may be that the instructions in the manual need to be amplified to further limit what can and cannot be done with a G16 command. That is quite possible. But at present I can see nothing in the manual which says what I am doing is wrong. If i am missing a section please tell me the page and para numbers.
Cheers
-
AH but you did make a polar move outside the sub in the main just after you called the G16 and before the sub call (;-)
The Mach manual is NOT the holy grail for Gcode. Most of the explainations are from the EMC manual and may or maynot apply as ART modified the code to his and our liking much of which was not updated in the manual.
I don't even think the manual covers The G16 in a sub enviroment. Most of the G16 protocal is Fanuc in nature.
(;-) TP
-
> AH but you did make a polar move outside the sub in the main just after you called the G16 and before the sub call (;-)
So I removed that line of code, and the effect persists.
I also removed every other move in the region apart from the g0 x#28 y#4 and the g83 from the code, and the effect still persists.
It's a bug. That should not happen.
> The Mach manual is NOT the holy grail for Gcode. Most of the explainations are from the EMC manual and may or maynot apply
> as ART modified the code to his and our liking much of which was not updated in the manual.
That's fine. I can handle that.
Perhaps I should explain that I have been programming at Assembly language level for maybe 40 years now, for everything from device drivers to very high level apps. I can just about see the data structures which must underlie Mach3, and I can see where the problem is. No, I am not boasting here: I have done that sort of debugging before. In commercial code, without the sources, successfully.
> I don't even think the manual covers The G16 in a sub enviroment.
No, it doesn't. And the Fanuc protocols are not used everywhere either.
I am happy to look at the code if ART wants me too. My concern is that the problem may be structural, although a different interpretation for the g83 command when both X and Y parameters are missing would solve the problem. Hum ... but that leaves the really messy problem of handling the Y-only case, which will be very common. Nope - the data structure flags need to be fixed for the g83 case.
Cheers
-
It has always worked here and I showed you the way it works (;-). 46 years of slinging chips here(;-) most of those with those fancy auto machines(;-).
Art is no longer in charge of Mach. Brian is in the middle of recoding everthing.
Wait till you try tool radius offsetting in the SUB (;-)
********OK I could not stand it I tweeked YOUR code just a touch and presto.
#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
m98 p192 L#36 % DRILL THE RING OF HOLES
g15 % kill the polar angle bit
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
%
Have a good one, (;-) TP
-
> 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
-
(;-) 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
-
> 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
-
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
-
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
%
-
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
-
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
-
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
-
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
-
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
-
You can very the R level for each hole
G16
G0X#28 Y#4
G91
G83 Y#4 Z#6 Q.050 R1
Y#4 R2
Y#4 R1
Y#4 R3
Y#4 R1
There are a million ways to do about anything in Gcode (;-) , TP
-
Roger and TP,
This thread is the most interesting (to me) and informative of any that I’ve followed recently on any of a dozen forums that I routinely follow. Thanks guys for all the info and examples that I hadn’t picked up on from the manuals.
Excuse me for butting in, but I just wanted to express my appreciation.
Thanks ,
Al Lenz
-
Glad you enjoyed. Gcoding can be fun in many ways(;-)
(;-)TP