g16 / g83 interaction ??bug??

[rcaffin]

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

[BR549]

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

[rcaffin]

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

[BR549]

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

[rcaffin]

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

[BR549]

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

[rcaffin]

> 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

[BR549]

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

[rcaffin]

> 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

[BR549]

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