I cut a 2.5D part that had roughing and 2 contour passes. The first contour feed was set to 1000 mm per minutes and on the second contour I set feed to 2000 mm per min. But they both took exactly the same amount of time to cut. About 3 hours. Why did that happen?
Did you look at the gcode to confirm the feedrate changes? Is it possible your firmware is limiting the feed rate so despite a higher rate in gcode, it’s capped?
With a contour pass it involves either xz, or yz axis. If the feedrate in the contour parameters is set for example to 2000mm/minute, I’ve noticed that that speed will not be reached if the z feed in the right hand tab ‘Limits’ is set much lower than that. This seems to be dependant on the contour - the ratio of movement between the two axis - if the amount of movement in both axis is similar, the y axis can’t reach 2000mm/min, because it has to wait for the z axis which has a feed rate setting much lower. I’ve noticed where the movement on the z axis is minimal compared to the x axis (given a xz contour is being cut ), my machine speeds up. Is the feed rate in the contour parameters just controlling the feed of either the x or y axis? I feel it must be.
I currently have my z axis feed set under the Limits tab to 3000mm/minute, this is the maximum speed of my z axis. I’m not sure what the default setting is? 250mm/minute? at the default rate under the Limits tab, contouring took a long time and was moving at a speed way slower than the feedrate I gave in the contour operation parameters.
One thing I have noticed is that the movement of my machine is smoother with other cam software ( Freecad, but that has a lot of other problems at the moment) and I don’t know why that should be.
In contouring mode, XYZ moves are interpolated to Z. Improving this and corner arc moves are things I have on the todo list.
Thanks Stewart, Could you elaborate on that, I’m not sure I understand. Am I wrong about the maximum z feed under the limits Tab?
To try to understand this better, I checked with a contouring operation. With the feedrate in the contour parameter set to 1800mm/minute and the z feed set to 300mm/minute in the Limits tab. the feedrate in the g-code defaults to 300mm/minute whenever there is a simultaneous movement of both x and z axis. If there’s movement on only the x axis, it sets a feedrate of 1800mm/minute.
As long as the max z feedrate in the limits tab is higher than the feedrate in the contouring operation, the contour feedrate will be respected if both axis are moving simultaneously.
I’m still amazed how good this software is! Thank you so much for making this available.
Sorry for the slow reply. Busy week. To clarify, when the X or Y and Z axes are engaged at the same time, the Z axis becomes the motion rate limiter in proportion to the angle of descent. So a 45 degree angle cut limit would be 50% between Z max and XY max feed rate. This is OK, but not ideal since it is too conservative for all but the steepest descent cuts.
Hi Stewart, and many thanks for your reply. I just tested with a 45 degree cut and that doesn’t seem to be the case, unless I’ve misunderstood what you meant? For movements involving say x or y and z, the feed is set to which ever is the least value, between contour feedrate and z maximum feedrate in the Limits tab. In the g-code for the model I’ve attached, that’s 300mm/minute ( what I set in the limits tab for z feed, contour feed is set to 1800mm/minute). In the g-code only the traverse in the y direction to cut the next line is performed at 1800mm/minute.
45degreeContour.kmz (284.2 KB)
thanks for the test. I just reviewed the code and it’s broken. I don’t recall when I made the changes that broke this, so it’s an opportunity to revisit and fix according to what I intended
I filed a ticket so I won’t forget
I don’t know if you meant that is what the pre-breakage code actually did, or if that was just an off-the-cuff qualitative illustration of the general kind of relationship you had in mind.
In that brief description it sounds like a Z rate limit (below op feed rate) would always reduce the feed rate for diagonal motion segments.
Admittedly I’m not actually coding and testing this, but geometrically it seems like a Z rate limit can potentially reduce the feed rate for a diagonal segment below the rate specified for an operation but not always so. For each segment, if the Z component of the op feed rate exceeds the Z rate limit, then the F value for that segment should be reduced proportionally to bring the Z component of the F rate down to the limit value. The next un-reduced segment would have to restore the op F rate.
For an operation, K:M could determine the ratio dVert/dHoriz where the Z limit begins to affect the op feed rate and use that to filter when to compute a reduction.
this. it wasn’t 100% accurate. there were corner cases where this behavior was not desirable, so I tabled it until I had more time to get it right.