brain fog moment with Gcode. Coordinate shift on mills

huleo · Jan 11, 2019

We have been doing internal subs for years using separate offsets for each position. However, we have some gang loaded parts where using offsets does not make sense. The last time we did this was on a Dynapath so the language was a bit different. Refresh me.

So we need to do mill ops with T1 at G54 X0Y0, then G54 X0Y4, etc. Then run em again with T2. Is this a G52 call?

So maybe...

T1
G54
G52 Y4
G52 Y8
Ops here
M99
Can I do that?

??

If I am on track here, I should be able to make slight tweaks to each G52 work shift for each tool and position if needed? The goal here is using the same tool path codes for T1 over and over like an internal sub for different offsets, but without the offsets and use work shift.

Hazzert · Jan 11, 2019

Why not just use subs and use incremental (G91) to move over a distance and run the sub again?

huleo · Jan 11, 2019

What I would like to do is gain control over each tool and each position. When we use multiple offsets, we cannot say adjust Z for T1 without affecting T2-T4. Other than that and having to use an assigned offset for each position, it works fine. We use it daily and mostly fine with it.

I guess I don't see how we can take advantage of G91 but its late.... I don't think you can say list out the shifts one after another can you? Like with our internal subs, we just have a list of the offsets at the beginning of an operation and machine will run that operation, then M99 and return to the next offset and use the same code.

SeymourDumore · Jan 11, 2019

huleo said:
I should be able to make slight tweaks to each G52 work shift for each tool and position if needed? The goal here is using the same tool path codes for T1 over and over like an internal sub for different offsets, but without the offsets and use work shift.

Yupp, you should be OK with G52 shifts.

I typically write a multi-part first as a single offset, single part program if fingerCAM is used.
Then, when all is good I just modify it and add the G52 shifts to multiply.
Make sure you have a G92 X0 Y0 Z0 in the beginning and at the end of the main program so you can restart whenever and wherever.

But for the record, I will NEVER use incremental programming unless there is absolutely no other way!!! ( sorry Hazzard, but incremental should be in the sub and never in the main )

SeymourDumore · Jan 11, 2019

huleo said:
When we use multiple offsets, we cannot say adjust Z for T1 without affecting T2-T4.

Well, you've just lost me right there!

Why would T1's Z affect anything but Tool1 and nothing else???

huleo · Jan 11, 2019

I suck at explaining myself. assume that T1 is just not quite right on the 3rd part down the line. All others are fine, I should be able to adjust the Z, say .001" for that 3rd position and return it to Z0 on the next part. As well, because the G52 is called at each tool and position, other tools would not be affected on the 3rd part. ??

What we have now is say we have G54, 55, 56. If G56, T1 needs adjusted, I cannot just adjust G56 because it will affect all other tools that use it!

EDIT!!! What I mean to say is use G52 as an adjustment to the offset, not actually adjusting the Z for T1. We do this a lot where minor tuning is done in the offsets.

huleo · Jan 11, 2019

SeymourDumore said:
Yupp, you should be OK with G52 shifts.

I typically write a multi-part first as a single offset, single part program if fingerCAM is used.
Then, when all is good I just modify it and add the G52 shifts to multiply.
Make sure you have a G92 X0 Y0 Z0 in the beginning and at the end of the main program so you can restart whenever and wherever.

But for the record, I will NEVER use incremental programming unless there is absolutely no other way!!! ( sorry Hazzard, but incremental should be in the sub and never in the main )

Could you give me an example of what this might look like? I am trying to see how much work we will have to do on our post for this. Need to play with code that works first though.

DavidScott · Jan 11, 2019

I use G52 or G10 to shift locations for parts on pallets. Here are two programs using each. Controls are Yasnac.

O20
G0 G17 G40 G49 G52 G80 G90 Z0
T6 M6(ENGRAVER)
T1M8
G0 G43 X-.0466 Y1.173 Z.1 H6 G54J2 S15000 M3
G52Q2Y-2.25
/M98P13
/M98P12
G52Q2Y-3.75
/M98P13
/M98P12
G52Q2Y-5.25
/M98P13
/M98P12
G52Q2Y-6.75
/M98P13
/M98P12
G52Q2Y-8.25
/M98P13
/M98P12
G52Q2Y-9.75
/M98P13
/M98P12
M9
M5
M1
G0 G49 G52 X-8. Y-.1 Z0
M2

Or G10

O1(VAC PLATE 24 PARTS)
G0 G17 G40 G49 G53 G80 G90 X-10. Y-.1Z0
G52
G92X5.8905Y6.2908
G10Q2P1X0Y0
T4M6(1/4" FINISH)
T3
G0G43X0Y0Z.1D4H4G54S7000M3
M8
G10Q2P1X0
M98P4G54
G10Q2P1Y-2.58
M98P4G54
G10Q2P1Y-5.16
M98P4G54
G10Q2P1X6.25
M98P4G54
G10Q2P1Y-2.58
M98P4G54
G10Q2P1Y0
M98P4G54
G10Q2P1X0Y0
M5
M9
G0G49G53X-10.Y-.1Z0
M30

Hazzert · Jan 11, 2019

For comparisons sake here is a 3x 1 inch box with 1 coordinate system on a Haas:

Code:

( OUTPUT IN ABSOLUTE INCHES )
( PARTS PROGRAMMED, 3 )
( FIRST TOOL NOT IN SPINDLE )
N1G0G17G40G80G90
M31
T1M6( 1/2 INCH SC 4FL FINISH EM )
T1
( OPERATION 1, CONTOUR )
( WORKGROUP )
( TOOL 1, .5 FINISH ENDMILL )
M97P2L3
G92X3.47
G91G28Y0.
G90
T1
M6
M30
 
N2( SUB NUMBER, 1 )
G54G90G0X-.25Y.75S4000M3
G43Z4.H1M8
Z1.1
G1Z0.F80.
G41Y.5D1
G3X0.Y.25I.25
G1X1.Z-.1795
G2X1.25Y0.Z-.25J-.25
G1Y-1.Z-.4295
G2X1.Y-1.25Z-.5I-.25
G1X0.Z-.6795
G2X-.25Y-1.Z-.75J.25
G1Y0.Z-.9295
G2X0.Y.25Z-1.I.25
G1X1.
G2X1.25Y0.J-.25
G1Y-1.
G2X1.Y-1.25I-.25
G1X0.
G2X-.25Y-1.J.25
G1Y0.
G2X0.Y.25I.25
G1X.02
G3X.27Y.5J.25
G40G1Y.75
G0Z2.
M9
G91G28Z0.M19
G90
G92X-1.33
M99
%

huleo · Jan 11, 2019

David, this seems close to what I was thinking. So instead of their being a separate offset for each postion, the post out might look exactly the same and repeat the same offset (G54 as example) then under each M98 call, there would just be the G52 shift for each?

Hazzert, if I am looking at your code right, I think that would not work as well for us as the L is the count or how many times to repeat, then the G92 is the incremental shift value? So it shifts X3.47 at each repeat? This would mean we could not adjust each position if we needed to. We always seem to have that one position that just a little different and needs some tuning.

angelw · Jan 12, 2019

huleo said:
David, this seems close to what I was thinking. So instead of their being a separate offset for each postion, the post out might look exactly the same and repeat the same offset (G54 as example) then under each M98 call, there would just be the G52 shift for each?

Hazzert, if I am looking at your code right, I think that would not work as well for us as the L is the count or how many times to repeat, then the G92 is the incremental shift value? So it shifts X3.47 at each repeat? This would mean we could not adjust each position if we needed to. We always seem to have that one position that just a little different and needs some tuning.

Hello huleo,
It would help if you were to specify the control you're using. The last time was using a Dynapath, but what now?

G52 is used in various ways depending on the control. David's Yasnac example requires a Q address to be used in conjunction with G52 to result in a Shift amount. G52 without the Q results in the Machine Coordinate System being used. With a Fanuc Control, G52 specified with coordinate address will result in a Shift amount being applied to all Work Coordinate System Offsets. To cancel, simply program Zero Values, with G52, for the specified axes.

G92 with a HAAS, set in HAAS mode via Setting 33, will shift the current position in the current work coordinate by the values specified in the G92 Block. In Hazzert's example, the shift is X-1.33 for the three iterations of the Subprogram. To revert back to the original Work Coordinate System Offset, you have to program a G92 with the opposite shift of the accumulated shift resulting from prior use of G92.

G52 will probably be your best choice, but how its implemented is dependent on the control.

Regards,

Bill

huleo · Jan 12, 2019

Bill, I agree the actual control will make a difference. We will probably do doing mill work like this on our Dynapath, Fanuc 16M, and one that is on its way which has an NUM control. I don't yet have the books for the NUM to figure it out yet.

We are using offsets on the Dyna right now and I think looking to make a change on all mills.

I think what is primarily at issue is getting a firm handle on what is going to be a machine control setting issue, how it might be programmed in MCX, and/or if this becomes more of a post processor issue. I was talking with another guy that supposedly uses the "output subprograms" tab in MCX but could not elaborate on how the program gets posted out. I tested it and was nothing close to what I was looking for.

What might be at issue is if we are to use incremental or work shifting, these would be for instances where the steps would probably be well known and want to program them with CAM, not enter them at the machine. I think this overlays into the CAM programming as much as figuring out what each control wants.

Where I potentially see issue as in Hazzarts example, it will shift the X-1.33 for each part but I cannot adjust each part if needed. If you change that value, it will change the shift for all parts?

angelw · Jan 13, 2019

huleo said:
Where I potentially see issue as in Hazzarts example, it will shift the X-1.33 for each part but I cannot adjust each part if needed. If you change that value, it will change the shift for all parts?

Hello huleo,
It comes down to the particular job at hand. Hazzert's example is fine where the incremental distance between the repeat of the Subprogram is the same; its efficiently programmed as a multiple execution of the Sub from one call. Where the Offset distance is different, or there is need to tweak each position shift, then Dave's example of specifying the new G52 before calling the Subprogram is the way to go. Hazzert could have used the same procedure, had it been required, by specifying the G92 shift before individual calls of the Subprogram and conversely, G52 could have been specified within the Subprogram in the same manner as G92 in Hazzert's example.

G52 will still be your simplest option in my opinion.

Regards,

Bill

Vancbiker · Jan 13, 2019

Just to add another method to the mix...

When I need to shift X and/or Y coordinates to run a subroutine, I assign by system variable.

M98H100
#5202=2. (2" Y positive shift)
M98H100
#5201=2. (2" X positive shift)
M98H100

After running subs and at the beginning of the program I call

#5201=0
#5202=0
#5203=0

to cancel the shifts.

DMF_TomB · Jan 13, 2019

#5241=#5241+10.0000
.
#5241 is G55 X work offset
.
so it changes the work offset you can obviously change it back if needed
#5241=#5241-10.0000
.
some machines when reset pressed a work shift might get cleared and or if G92 is in effect it stays maybe when you do not want it too needing a zero return to undo the G92 on some machines
.
my experience just change the work offset, if using G55 you can have it auto change in the program
.
there is different numbers for G55 X Y Z and G54 X Y Z....... etc

angelw · Jan 13, 2019

Vancbiker said:
Just to add another method to the mix...

When I need to shift X and/or Y coordinates to run a subroutine, I assign by system variable.

M98H100
#5202=2. (2" Y positive shift)
M98H100
#5201=2. (2" X positive shift)
M98H100

After running subs and at the beginning of the program I call

#5201=0
#5202=0
#5203=0

to cancel the shifts.

Hello huleo,
To further explain Kevin's suggestion, he is using the Macro System Variables for the External Workshift and has the same effect as executing G52 in the program. Its a superior method to that suggested by DMF_TomB, in that its cancelled by setting the respective Variable to Zero. Accordingly, if you have to tweak the Shift amount, as you have suggested in a previous Post, you only have to edit the value where its applied to the Variable and not where its cancelled.

David's example in Post#8 does the same using G10.

DMF_TomB said:
some machines when reset pressed a work shift might get cleared and or if G92 is in effect it stays maybe when you do not want it too needing a zero return to undo the G92 on some machines

Programs should be written in as fool proof a method as possible. Equally, it may be that retaining the current value of the shift when a Reset is executed could be detrimental. Accordingly, maintaining the correct value for all circumstances should be done within the Program.

Regards,

Bill

DavidScott · Jan 14, 2019

angelw said:
Accordingly, maintaining the correct value for all circumstances should be done within the Program.

Can not be overstated! My G10 program is one I made around 10 years ago, before learning about G52 shifts, but is a handy tool to know about.

rainman · Jan 15, 2019

Note to all Haas users:
Setting 33 controls whether G52 and G92 behave as a Fanuc or Yasnac. Make sure it's set the way you want to use these codes.

brain fog moment with Gcode. Coordinate shift on mills

Hot Rolled

Stainless

Hot Rolled

Diamond

Diamond

Hot Rolled

Hot Rolled

Diamond

Stainless

Hot Rolled

Diamond

Hot Rolled

Diamond

Diamond

Diamond

Diamond

Diamond

Cast Iron

Similar threads