[labuda]

So I've repeatedly ran this G-code, and it always causes my mill to seize up during the rapid traverse in the y-direction, causing me to loose exactly 8.9mm of steps every single time.

I tried performing the G-code in different locations of my mill in case there was some friction in that particular y location, but that didn't change anything.

Code that works well:
N364 G02 X-5.413 Y-34.23 I12.666 J21.716
N366 G02 X-7.128 Y-31.967 I3.903 J4.741
N368 G01 Z0. F100.
N370 G00 Z1.
( OPERATION NAME : Profile Contouring.121)
N372 X24.128 Y-23.467 S7619 M3
N374 Z0.
N376 G01 Z-1.
N378 G02 X22.945 Y-25.236 I-5.618 J2.478 F30.
N380 G01 X22.944 Y-25.241
N382 G02 X24.128 Y-31.967 I-4.434 J-4.248

Code that fails every time during the rapid traverse at the N164 line:
N156 G03 X16.941 Y-17.627 I-45.311 J-88.989
N158 G02 X14.119 Y-16.084 I10.624 J22.785
N160 G01 Z0. F100.
N162 G00 Z1.
( OPERATION NAME : Profile Contouring.102)
N164 X14.12 Y-34.394 S7619 M3
N166 Z0.
N168 G01 Z-1.
N170 G02 X16.941 Y-32.851 I13.445 J-21.242 F30.
N172 G03 X20.049 Y-31.336 I-42.203 J90.503

The way that I fixed it is by changing "N162 G00 Z1." into "N162 G01 Z1." to avoid the rapid traverse all together. However, it would be nice to understand to prevent this from happening in the future!

Any thoughts?!

[positiverake]

Maybe try fast feeding to that spot? or if you can move the part a bit and try and re set work coord.

[CitizenOfDreams]

What happens if you separate X and Y rapids?

N162 G00 Z1
N163 X14.12
N164 Y-34.394 S7619 M3

[deadlykitten]

hy i looked a bit over your code ... yes, is a bit weird

can't you ask the machine provider about this error ? or did you build this yourself ?

seems there is an error with in-position during rapids

i wonder, if you rotate with 90* :
... the 1st toolpath, do you get the same error ?
... the 2nd toolpath, do you fix it ?
* thus maybe there is something 'only' with y axis / kindly

[mejasont]

Are you hand writing your code or is it from the post processor in your CAM.
Im confused why you have rapid moves whilst the tool is engaged in the work piece ie Z0, Z-1. normal behaviour would be to extract to a safe height before rapid moves.
from what i can see your G0 rapid acceleration or velocity appears to be too fast for your machine, have you had issues with other job files before.
Just trying to get my head around what you are doing

finished milling an Arc under a G1 with a previous pre defined feedrate of F30 (N378)
now sending a Z move with a feed rate F100
N160 G01 Z0. F100.
then rapid back up 1 ( I presume 1 mm) why feed slowly down then rapid back out
N162 G00 Z1.
( OPERATION NAME : Profile Contouring.102)

so this is your rapid move to a new position and a rapid back to the work surface 0 in Z
N164 X14.12 Y-34.394 S7619 M3
N166 Z0.

now running commands with G1 (the feedrate is still 100 from N160
N168 G01 Z-1.
etc.

code reads fine, makes sense
Are your axis motors screaming during the move, louder than usual.
it looking very much like the velocity is a smidge too high, i say a smidge as it must not have been an issue before. on long moves it will probably show more than it will on short moves.

Your fix explains a lot, when you are not using your machines maximum acceleration an velocity in maximum speed moves ie a linear move under a slower feed rate instead then the machine is happy.
rapid is too bloody fast, if you dont get the axis motors screaming at you you are lucky - its the rate at which the pulses are sent to the stepper/servo drives if they are too close together and the motor has not had enough time to move an increment before the coil is energised again then it like hitting the brakes, you will notice that when the power is on to the motors but no signal is provided the motor shaft will be locked in position (effectively electronic braking). the closer your rapids speed gets to the coils being simultaneously energised at the same time the motor will stall and miss steps.

Im keeping an open mind and look forward to being corrected, so please don’t take my explanation as gospel. Its only my perception of your issue.

It would be helpful if you could have provided some information regarding your machine, The CAD application/postprocessor you are using and if you were in metric or imperial.
it would be a fairly large machine with moves of 43 inches so it seemed a reasonable asumption to make. The whole z move thing just looks a little wrong to me thats why i asked if you manually wrote your code. Im asuming your work surface is 0 in Z, if your stock material isnt flat you could end up running your cutter into stock on moves. A "Z axis" clearance of 3mm for example would just help that little bit to get your cutter clear of the surface, I certainly wouldnt consider making rapid plunges/moves into a workpiece either. A feedrate of 100 and depth of cut of 1mm ummm interesting. With my limited intelect im thinking a depth of cut of 0.5 x diameter would be a 2mm end mill with a feedrate of 100 sounds very slow. Are you rubbing this thing to death lol.

[RCaffin]

No idea what machine.
No idea what software.
No idea what motors.
No idea what tooling.
No idea at all.

[mactec54]

So I've repeatedly ran this G-code, and it always causes my mill to seize up during the rapid traverse in the y-direction, causing me to loose exactly 8.9mm of steps every single time.

I tried performing the G-code in different locations of my mill in case there was some friction in that particular y location, but that didn't change anything.

Code that works well:
N364 G02 X-5.413 Y-34.23 I12.666 J21.716
N366 G02 X-7.128 Y-31.967 I3.903 J4.741
N368 G01 Z0. F100.
N370 G00 Z1.
( OPERATION NAME : Profile Contouring.121)
N372 X24.128 Y-23.467 S7619 M3
N374 Z0.
N376 G01 Z-1.
N378 G02 X22.945 Y-25.236 I-5.618 J2.478 F30.
N380 G01 X22.944 Y-25.241
N382 G02 X24.128 Y-31.967 I-4.434 J-4.248

Code that fails every time during the rapid traverse at the N164 line:
N156 G03 X16.941 Y-17.627 I-45.311 J-88.989
N158 G02 X14.119 Y-16.084 I10.624 J22.785
N160 G01 Z0. F100.
N162 G00 Z1.
( OPERATION NAME : Profile Contouring.102)
N164 X14.12 Y-34.394 S7619 M3
N166 Z0.
N168 G01 Z-1.
N170 G02 X16.941 Y-32.851 I13.445 J-21.242 F30.
N172 G03 X20.049 Y-31.336 I-42.203 J90.503

The way that I fixed it is by changing "N162 G00 Z1." into "N162 G01 Z1." to avoid the rapid traverse all together. However, it would be nice to understand to prevent this from happening in the future!

Any thoughts?!

You can not have the spindle speed on the same line as a Go move S7619 M3 this needs to be on it own line at the start of the program and you only need it one time in your program

So remove the S7619 M3 and it all should run

[RCaffin]

Whether or not you can have an S command on the same line as a G0 command is one thing, but what does bug me a lot is the habit of some CAM programs of sticking an S command and an M3 at the end of a move command. That is just very poor programming, even if it is permitted by the manual.

As the instruction which fails is the first G0 in the sample, I would also wonder whether the commanded G0 speed was not way more than the steppers can handle. Changing G0 to G1 to get success seems to support this concern.

Cheers
Roger

[deadlykitten]

You can not have the spindle speed on the same line as a Go move

... habit of some CAM programs of sticking an S command and an M3 at the end of a move command. That is just very poor programming

hello there is nothing wrong if the controller can handle that; it may :
... execute 1st S, than axis movement
... execute 1st axis movement, than S
... start to execute them both simultaneously : at least okuma machines can change rotary axis status ( acc/dec/stop/orient ) during axis movement, as one of their many cycle time reduction functions ( requires M codes, maybe parameter settings, thus the behaviour can be toogled and controlled : block confirmation may occur when axis movement is confirmed, or when also rpms are confirmed) / kindly