So I’m thinking about a project that would involve shaping a piece of wood but am unsure if I can do the cutting as I would want it. Basically, will the maslow move from one x,y,z position to another x,y,z position linearly, including the z-axis, without issue? For example, if I want to cut from 0,0 to 5,5 and it slope down from 0 to .5 inches, the gcode command would be (I think)
G0 X0 Y0 Z0
G1 X5 Y5 Z-0.5 F30
Would Maslow actually lower the z-axis linearly (i.e., straight line) through the cut?
My frame rebuild isn’t quite done so I can’t readily try it.
The firmware will do coordinated XYZ straight line (G0, G1) moves, but it cannot do a z movement during a curve (G2, G3). A coordinated XYZ move will feed at the speed set by the gcodes in the program (F xxxx) unless that would cause the z axis to exceed the zMaxFeed value. In that case, the movement follows the desired profile but at the speed limit set by zMaxFeed
In a curve operation, the Z axis moves a given distance over a given period of time, ostensibly the same amount of time it should take for the X and Y moves to complete over that same distance…
For example (assuming a linear, symmetrical slope in the Z axis)
At 10mm/sec, that move would take 10 seconds. So Z moves at 0.5mm/sec
This works because 0.5mm/sec is less than the zMaxFeed, but if that same operation were to have a Z move rate greater than xMaxFeed, the cut wouldn’t be completed correctly? What would happen? (I suspect Z just wouldn’t get to it’s target depth)
Why is this not the case for straight line moves? Does the firmware do Z first (or last) instead? EDIT: Or even simultaneously… since the X, Y and Z moves are all known, the speeds can be synchronized, I suppose. Which begs the question why does it work for straight line but not curves? This is all academic, really, I’m just satisfying my curiosity with these questions.
Most likely, the math to calculate the length of the curve is a bit harder than for straight line segments and can’t be done in the Arduino. That’s where the G-code generator (Fusion, for example) would convert that nice spiral into a lot of short line segments that can be cut accurately.
I think the curve in the XY plane is the same, but the Z axis movement would need to be coordinated with it. Presently, the function Gcode::G2() calculates the end points and the center of the arc in the XY plane and calls Motion::arc() with them. That breaks the arc into straight line steps based on the ‘loop interval frequency’ and the given feed rate - see Motion::calculateStepSize(). I think this is where the Z axis movement would enter the calculations, limiting the step size.
There are two distinct situations. In the case of a line segment G1, “ramps” are supported. If the Z-axis can’t keep up with the specified x-y travel speed, then the x-y travel speed is slowed down to the maximum at which it can keep up.
For an arc, G2, the code does not currently support ramps.
As an aside, blurfl was saying that the implementation of an arc is actually done as a series of line segments. This is no surprise, it is the simplest way for an x-y machine to approximate an arc. He was further adding that he thinks there is a good hook point to do the ramp in the case of G2, if someone steps up and implements it.
So what actually happens in the G2 case right now, if the CAM software tries to send a G2 which includes a Z-Axis change (Or a G2 after a G18/G19, if that’s how it works)? Maslow will just respond with something like “not supported” or “invalid command”, and stop, I suppose?