Axis max travel & G0-G3
-
Hi!
G0 and G1 commands doesn't moves outside of boundaries (set with M208, M564 S1), but moves to up to the set limit. And all following g-code executed as if nothing had happened. Is not this an emergency situation when the team did not execute correctly? The positioning is not in the place where the coordinates were indicated.
With G2 & G3 everything is much sadder, the limits not working at all, as a result, the carriage hits at the end of the axis. It seems that only the final coordinates is checked, and not the whole path of moving. A similar situation is possible if you forget to perform G28.
Is it possible to block all motion commands until it is executed G28 ?It would be nice if before doing a step examine the current position against the axis limits. GRBL, for example, does not even attempt to execute the command, but immediately reports an error and all remaining code is not executed, and machine have to be restarted.
FW: 1.21RC2
Example for my setup
M564 reports:
Movement outside the bed is not permittedM208 reports:
Axis limits - X: 0.0 min, 212.0 max, Y: 0.0 min, 117.0 max, Z: -207.0 min, 0.0 maxM114
X:0.000 Y:117.000 Z:0.000 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 E6:0.0 E7:0.0 E8:0.0 Count 0 46800 0 User 0.0 117.0 0.0G1 X-100 Y-100
M114
X:0.000 Y:0.000 Z:0.000 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 E6:0.0 E7:0.0 E8:0.0 Count 0 0 0 User 0.0 0.0 0.0This movement has no sense to X0, Y0 instead of -100, -100. Isn't ?
-
I can understand that in a CNC environment, any move that would exceed the movement limits is likely to indicate a serious error. However, in a 3D printer a common cause of movement outside the limits is that the slicer has generated a skirt around the print, and the skirt breaches the limits slightly. In this case, limiting the motion so that the skirt is compressed is a reasonable action.
Perhaps the behaviour on an attempted move outside the limits should change if M452 or M453 has been used to switch the printer into laser or CNC mode?
-
I can understand that in a CNC environment, any move that would exceed the movement limits is likely to indicate a serious error. However, in a 3D printer a common cause of movement outside the limits is that the slicer has generated a skirt around the print, and the skirt breaches the limits slightly. In this case, limiting the motion so that the skirt is compressed is a reasonable action.
If specify wrong (just by mistake, a typo) parameters in the slicer, we get damage to the machine because it supposedly should not happen. Why allow the head to move beyond the established limits? Fo what reason ? This does not make sense for any printer mode. In which cases is it necessary?
Perhaps the behaviour on an attempted move outside the limits should change if M452 or M453 has been used to switch the printer into laser or CNC mode?
M450
PrinterMode:CNCThe video shows how it looks and what it leads to https://youtu.be/evGKM8Zwan4
I set a fairly low current of drivers so as not to damage the mechanics during the experiments (0.7A), but in the operating mode there will be 2Amp and this will allow the NEMA23 motors to seriously damage the mechanic.
In the firmware, you limit the driver current to 2A because it can overheat. Following the same logic, you need to remove all limitations in the firmware, because simply there must be a correct configuration and good ventilation of the board. Isn't it ?
-
I wasn't trying to defend the lack of limit checking on G2/G3 moves; I was defending the behaviour of attempts to move outside the limits on G0/G1 moves.
The reasons I didn't implement limits on G2/G3 moves before are:
-
Very few users use G2/G3 support. RepRapFirmware is not yet well-established in CNC circles, and 3D printing does not use G2/G3 moves. So it wasn't a priority.
-
Calculating in advance whether any part of an arc move will exceed axis limits is not straightforward, especially if the bed is circular or shaped irregularly as it is on a SCARA machine
-
Checking limits at each segment is computationally expensive in some cases. On Cartesian and CoreXY machines, it would be straightforward to check the XY position at the end of each computed segment against the axis limits. On delta and polar machines it's a little harder because a square root would need to be calculated - but still feasible. On Scara machines it's a killer because trig calculations need to be done for each segment. In effect these expensive calculations would get done twice - once to check the limits for each segment, and once when executing the segment.
However, now that there are people such as you using RRF to control CNC machines, I will revisit this.
-
-
Why not trying a different "shortcut"!
First of all why not implementing it first of all for machine types that don't require complex computations? It would be something as simple as not issuing pulses for axis where the new coordinate (after estimating the new position based on the pulses to be issued) would be outside the specified boundaries. Or just limit for just one extra pulse issued when the axis just crosses the limit.
As for comparisons involving square roots, most of the times they can be converted to alternatives using only squares.
For the trig calculations there might be simpler alternatives. I'm kind of used to do this for other projects and sometimes things that look really awful end up being pretty simple to implement and executing really fast. I'm doing this quite often for the projects I'm involved and I'm ready to give it a try. You can contact me on PM to keep the forum free of pure math! -
I have already implemented limit checking during G2/G3 moves, for inclusion in 1.21RC3 when I have tested it.
-
Hi, David! I found out that G92 X0 (or any other axis) leads to incorrect processing of the limit. For example: G28, then move head to the XY center of bed, G92 X0 Y0. Now we are in machine position 100, 100 and logical position 0, 0. G0 X-100 Y-100 does't work (configured as M208 X0 Y0 Z0 S1 M208 X212 Y117 Z212 S0), but ! G0 X212 Y117 will lead to a breakdown head/other hw. IMO, any movement/offsets/move to predefined position/etc commands needs to be controlled over movement abstraction. It's seems the good idea to have "machine coordinates" for each axis in primitive ticks/steps/movements from 0 (home) to limit to controlling limits. Of course, it can be resolved by set two limit switches on each axis, but it will be overkill.
-
G92 should not be used, except that in a few instances it is necessary to use it in homing files. For CNC work I suggest you use the "workplace coordinate" system (G53 thru G59.3, and G10 with the L parameter) which is supported in the 1.21RC firmware. I believe that if you use those commands, the M208 limits will be respected - but please let me know if you find otherwise.
-
Z probe (G30) also leads to non-observance of the limits of the Z axis
