The problem of crashing at the top of Z axis upon retract (and then having the cut run too deep as a consequence) when zeroing on the surface of thick stock and using a too large retract height value, is a common pitfall.
There have been many discussions about why limit switches are only active during jogging, and not during the cut, due to the risk of them false-triggering and ruining a job for no good reason. That makes sense.
But couldn’t CM take the Z-limit switch into account during the initial retract move too, and interrupt the job with an error message pop-up ?
I have not looked at the technical implications (e.g. how CM would figure out where the retract move is in the G-code, when running G-code that has not been generated by CC), but I think it could be a way to foolproof things a bit.
If there were no limits on Z height, then this wouldn’t be necessary. However, we’ve bought a machine knowing that there are limitations in the design so it makes a lot of sense for the design to include protections for the operational limits of the design.
An engineer that says its too hard write software to protect the hardware is too limited in their thinking in my opinion. (Pun intended.)
CM knows (if you have limit switches) the absolute space of where things are. It can easily detect you’re going to hit the top (it knows the Z range of the gcode. it knows where the zero is in absolute sense. it knows how high things are)
so in concept it can detect this and warn for it
I have 6 Hall effect sensors on my machine. 3 serve as homing and limit switches and 3 just limit switches. GRBL supports this configuration. Carbide Motion I would think would work within the confines of GRBL but I am not sure since I use different senders and never verified it will work within CM
In fact, there is no need to hit the limit switch to trigger a warning as the software could calculate that there is no more Z available and send a message before retracting above the available height. It could even be done before you press start.
LinuxCNC does exactly that, on every axis. I’ve only got 3 homing switches and it just calculates if you’re going to exceed the soft limits, then pops up with a warning that machine limits will be exceeded with this gcode. I’m surprised CM doesn’t have it, it has saved me a few times.
That being said if my machine hits soft limits it just halts at that limit, it won’t keep driving against the stop.
I can’t grasp the reasoning on that.
The “false trigger” is the main culprit here.
If the switches did stop the machine at least there is a chance of salvaging the project. But the way it is now allowed to function, if a motor does not complete its move the remainder of the job will be off by those lost moves, ruining the project beyond salvage.
Not for the average user? It’s not easy to figure out at which line of the G-code the job is interrupted, and then it takes a little G-code know-how to edit the file to run the rest of the toolpath. Not very difficult, but not everyone speaks G-code.
Yes, if there is an actual collision, the job is lost anyway due to lost steps. But the point is (I think) to address the more likely case where there would be no collision in sight, but a limit switch would false-trigger randomly due to EMI or whatever, and then people would get just as angry as they get when they have a random EMI disconnect in the middle of a long job.
If you ask me, there should be an option in CM to let the user decide what to do with limit-switches at runtime (nothing, or pause). Or work on robust limit switch detection (be it using HW and/or SW filtering).
But in the meantime, taking the Z limit-switch detection into account during that initial retract move would address a large number of user issues.
Interesting question, I have them enabled but did not try to crash upon retract to check
However, soft limits in GRBL params are only about the MAX travel, so I would think that GRBL does not care if you try and send the axis to some positive Z absolute value (i.e. go “above” the Z switch level). Maybe someone better informed can tell us whether GRBL would do anything about it with soft limits enabled, I doubt it.
Soft limits won’t false trigger.
The feature is part of grbl, the gcode senders (Carbide Motion, CNCjs, UGS, etc) have nothing to do with it. I don’t really understand why CM tries to handle that itself.
I’m also not sure why it’s recommended that we disable soft limits. Maybe leftover from the pre homing switch days (but you can’t enable soft limits without having homing enabled) or just Carbide 3D trying to save their well designed machines from being jacked up by all of us.
Yes but if CM checked the code before running it, probably after zeroing, it could determine if the movements (including retract) are within the “safe” operating envelope.
