As the title suggests, how do I increase the movement speed when the bit is raised and it is not cutting? Is there a term for this?
1 Like
I don’t know what it is called, but I believe the gcode command you want is G0.
http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g0
It says move to that point as quickly as possible. This is the code that Fusion360 will use when moving above the retract height.
1 Like
correct, g0 is supposed to move at the max possible speed, I think bar may still
have this limited, and it would be worth looking at the code to see what an
uncoordinated g0 would look like (we may need to have a slight delay between a
g0 and a g1 movement to let the sled settle from high speed motion)
It looks like it is hard coded in line 604 of CNC_Functions.h
603 //if this is a rapid move
604 cordinatedMove(xgoto, ygoto, 1000); //move the same as a regular move, but go fast
I believe the 1000 is in mm per minute.
1 Like
Yup that is correct, not sure if the motors are even capable if moving faster than that.
Per this video from Bar, the top speed is ~48ipm (1219.2mm/min)
48 ipm is pretty close to the fastest speed the motors can do everywhere, but in
some areas they can move the sled faster than that. If you are tightening both
chains, the router can really whip around.
and if you are using non-standaard motors or sprockets, the sled can move faster
everywhere.
This limit should be based on a calculation, not a hard number.
1 Like
Is there a reason to not move at 1200mm/min versus 1000mm/min? It is a 20% increase in movement speed.
Has anyone tried upping it?
I have spent very little time with the code. But as an example, when the feedrate of the zaxis was set faster than what the motors could actually accomplish bad things happened. In that case, the machine would start performing the next line of gcode before the movement completed.
I’m pretty sure that all speeds > approx 60% of max are not recommended until a number of refinements have been sorted into the equations. Obviously, the plan is to make it run as fast as possible with accuracy, but if you watch the video i found the max rate on, its just not there yet. I was only pointing out the max, as listed by @Bar, for reference, not as a recommended feed rate.
I think this is due to the fact that the Z axis wasn’t part of the coordinated
move, it was run separately, so if it took longer than planned, the coordinated
move would finish and it would go on to the next step.
We can change that line of code to increase the limit to see what happens at 1200. I was seeing issues very similar to the issues we were seeing with the z-axis at 1200 where on some parts of the sheet the machine would not get to the end of it’s G0 move before starting to run the next line which had undesired effects. We might be able to push it up a little more. 1000 is just a nice round number, not the tested maximum. I’d rather be a little safe and slow than push it. Once we’ve got all the other issues locked down, we can start to push the limits more.
5 Likes
5 years on now. Is it time to revisit this?