Slow feed on first side of cut out?

Post general information and questions relating to Cut2D in this Forum.
Mackerethwoodcraft
Posts: 10
Joined: Sat May 21, 2022 1:13 pm
Model of CNC Machine: Quintax pacer 2500

Re: Slow feed on first side of cut out?

Post by Mackerethwoodcraft »

Got it! Changing the z rate did it. For some reason it was keeping the very slow plunge rate for the first leg of the y movement.

User avatar
Leo
Vectric Wizard
Posts: 4082
Joined: Sat Jul 14, 2007 3:02 am
Model of CNC Machine: 1300 x 1300 x 254 Chinese Made
Location: East Freetown, Ma.
Contact:

Re: Slow feed on first side of cut out?

Post by Leo »

I think, maybe, that is only part of the issue.

That plunge rate "should" only have effect on moves that have a "Z" command on any line of code. Even if that line is "Y" and "Z".

If the commanded line is "Y" ONLY - it "should" be at the feedrate of 5m/mn NOT at the Plunge Rate.

That may not seem like an issue right now, but on future programs is may be.

So - at this point can you post your .CRV with the corrections - PLUS - your G-Code.
Imagine the Possibilities of a Creative mind, combined with the functionality of CNC

User avatar
adze_cnc
Vectric Wizard
Posts: 4325
Joined: Sat Jul 27, 2013 10:08 pm
Model of CNC Machine: AXYZ 4008
Location: Vancouver, BC, Canada

Re: Slow feed on first side of cut out?

Post by adze_cnc »

You've made things work. But making things work and fixing the problem are not synonymous.

In Adrian's posted g-code from his Pacer post-processor there are only two lines (consecutive in the file) that mention a speed change—lines N90 and N100:

Code: Select all

N90 G1Z0.000 F254.0
N100 G1Y279.400 F5000.0
The first is the slower plunge (254mm/min) fully into the material to Z height 0 (the surface of the spoilboard) and the second for the Y travel for the first leg of the square (5000mm/min). Every other leg of the square should inherit that 5000.00mm/min.

If your post processor is not producing that same (or similar) output that can be remedied by a simple edit to the post processor.

If your post processor is producing code as above or (similar) then your machine is ignoring that speed change until the second leg of the square. That's a bit more serious. Hence a desire to see the g-code of a run that didn't run as expected.

Post Reply