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.
I cut helical holes last week, constantly dropping while turning circles. It was a lot of gcode, but the maskow postprocessor in fusion did it perfectly.
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
I’ve tested some v carving which includes x,y,z movement. You definitely want to have as little play in your z direction as possible. You’ll need it to respond to every little in and out command.
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)
Distance: 100mm
Depth: 5mm
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.
Are you saying that fusion is aware that maslow doesn’t support the necessary G-Code and will substitute its own implementation using simpler G-code?
If so, how does it know that? Sounds like there’s a specific maslow driver for fusion? Or is this just part of G-Code? For example, is there a G-Code response that lists supported instructions?
Also, what other CAM software “knows” about maslow similarly well, other than fusion and ground control?
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?
Oh, sorry, I misread your comment. I , too, am not sure what currently happens.
My frame is nearly done and I hope to start testing this kind of thing soon (yeah, I know there are simulators, but I have lots and lots of other time-sucks right now).
I think I have a pretty good idea of how to add support for this feature. If no one else gets it done before me, I will try to add it before the end of the year.
it will do the circle and the depth change, but they are not coordinated. This
means the depth change may finish before the circle, or the circle may finish
before the depth change.