Slow feed on first side of cut out?
-
- 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?
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.
- Leo
- Vectric Wizard
- Posts: 4091
- 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?
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.
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
- adze_cnc
- Vectric Wizard
- Posts: 4373
- 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?
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:
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.
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
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.