Probing speeds aside, why are alarms disabling the Z stepper driver?
Disable Z on an e-stop for safety, maybe (but doubtful with a spinning tool). On an alarm, I’m having a hard time conjuring a scenario where that makes sense.
Good points. Thanks for clarifying. I originally was mostly interested in making sure I fully understood why my gantry was crashing down when I failed the probe, which is more clear now, and then went down a rabbit hole of evil probery.
Need to get my hose adapter in place and then the chips shall fly (mostly into my dust collector) in celebration!
I assume the misplaced G91
I will test this now.
Your color combination is very good, in the photos I see that you have the LR3 jackspot box, do you plan to use that same box? I ask because I already have it printed since I was going to manufacture my LR3 when the LR4 just came out.
I do not intend to re-use the LR3 jackpot box, it’s just sitting there because I don’t have the heart to throw it away quite yet 
1 Like
I kept reading and found this. I see that I change the box.
I can see why triggering the alarm makes sense.
I can’t see why ALARM 5 (or any alarm) should disable the Z stepper driver (rather than just halt motion). It feels like there may be (or should be) a FluidNC config option to control this behaviour. Dropping a spinning tool into something potentially hard doesn’t improve the safety situation on any alarm.
Are you having this issue?
Two of use said we have not seen the same thing. Coin says a new test is happening.
Beyond that, I do not know why that triggers a power down in the firmware. That is beyond my pay grade. Always air test your Gcode and this will never be an issue.
OK! Interesting and good news.
Code off the web page works great with no surprises, other than Z-80 value seems to be entirely ignored (bug?) and is too short for the LR4? It tries to probe forever, to the center of the earth, so did not see the Alarm. Stops when it hits the touch plate and retracts 10mm as expected.
G21
G90
G94
G92 X0 Y0
M0 (MSG Attach probe)
G38.2 Z-80 F200 P0.5 (probe down set thickness )
G1 Z10 F900
M0 (MSG Remove probe)
Looking at FluidNC Demo code on Supported Gcodes | Wiki.js has a G91 before the G38.2, so made that single change:
G21
G90
G94
G92 X0 Y0
M0 (MSG Attach probe)
G91 G38.2 Z-80 F200 P0.5 (probe down set thickness )
G1 Z10 F900
M0 (MSG Remove probe)
(Note - do we need to set G90 again, or is G91 only in effect for the probe?)
This behaves! I probed down to Z-80, went into Alarm (probe failed) but gantry DID NOT DROP. Repeated this test a few times to verify.
Might be a bug, or worth adding the G91 and updating the Z-80 to Z-110, but as-is it still works (since the Z-80 is ignored without the G91 in 3.9.1, it seems) I think it might be a bug though.
But, the crashing behavior definitely appears to be because of the G91 in the wrong place.
Nope, just my industrial process design background seeing an operator doing something, sane or not, triggering a potentially unsafe condition, and thinking there is likely a way to avoid it.
I’ll add it to my list of things to investigate when I’ve got some free time.
#dos-list-2024
Alarm 5 is a probing alarm.
Are you probing with a spinning tool???
I’m not doing anything. I just observed that someone triggered something (a gantry drop) that doesn’t need to happen (and does not improve the situation) in response to a probing error.
Worse, is that the outcome could lead to injury if someone (even if f’ing up their gcode) triggered it inadvertently – like triggering a probe unintentionally while a tool is spinning. That is, there is no upside to this result but it creates the potential for injury. Where I come from we try to engineer controls around things like that so that people (even acting less than intelligently) don’t get injured, dead, or sued. People tend to get upset about losing limbs in falling presses, falling sewage bar screen rakes and various other moving things.
I was simply trying to illicit thoughts on why the stepper drivers were being disabled (for unknown reasons) in response to an alarm, wondering if there are other alarms that do this, and if there is a way to control this behavour in reponse to alarms (any alarms), in case there were some configs that could be revised to improve product safety. You know, make things as safe as can be for the “yellow brick road folk”; make sure that the gantry never drops unnecessarily… it must be assumed that it could have a spinning tool running at any time.
I now regret that I mentioned anything at all.
1 Like
As you posted this I was reading back, and realized you were not the one having the problem.
It was not meant as a smart-ass response, I thought you were the one issuing the probe, and got the alarm, and were worried about it happening while your tool was spinning.
Alarm 5 is a specific alarm that happens when it has traveled too far, what you have told it is the max, and not hit the probe.
My guess, is that the steppers get disabled because this should really only ever happen if your machine is currently driving into your table, and releasing the steppers relinquishes that downward pressure. But that would be a question for the FluidNC guys to answer.
So far, I haven’t found much that doesn’t follow what seems to be industry standard protocol for the way things like this are handled.
But I can’t say whether that is on purpose, or an oversight.
This is one of the only alarms I have seen disable the steppers.
Everyone here takes that very seriously, which is why @vicious1 mentioned testing these things in a safe way. Air cut, etc.
It’s fun to play with GCode scripting, etc, but these things should be tested ahead of time with the utmost scrutiny and safety in mind.
This is a very dangerous toy we are playing with.
3 Likes
You are not a target here, promise. I completely understand what you are worried about and I am messing around testing.
You just kinda ended up in the middle of us being worried about it as well.
I promise I am not trying to be rude, when I am being short I am just trying to get the orders out and on to the next thing…but something like this gets my full attention in the middle of doing other things. Priority. So short answers to show I am paying attention but still getting orders moving.
4 Likes
To recap my latest bench test finding (with 3.9.1) was:
- somehow, having the G91 after the G38.2 (in the same command) was causing the motor disabling drop behavior, when the Z travel limit was exceeded without triggering the touch probe.
- Removing the errant G91 caused it to ignore the Z value travel limit entirely
- Putting G91 before G38.2 seems to behave (alarm but no drop)
I might try with the 3.7.x last known good version, but for now these workarounds are fine–this is not a blocker.
The logic behind that makes sense. I think an improvement on it might be to reverse motion instead, but maybe you’d run into the scenario where you’ve already broken something. It’s probably best to just halt motion and then only release the steppers on an estop trigger (maybe) or upon the removal of control power.
I wish I had the bandwidth right now to chase this with the FluidNC folks. If it’s a configurable behaviour it’s worth considering changing.
I appreciate that and the situation. I find myself just as short often. I know what an email per minute a dozen hours a day feels like. 6 all-nighters out of the last 14 days myself… just taking a short break. My other brother Daryl isn’t pulling his weight and Larry is just useless!
4 Likes
It’s interesting that the G91 location affects the drop behavior. I took a look at the FluidNC code (most of which is way over my head), but this method in MotionControl.cpp stood out.
// Method to ready the system to reset by setting the realtime reset command and killing any
// active processes in the system. This also checks if a system reset is issued while in
// motion state. If so, kills the steppers and sets the system alarm to flag position
// lost, since there was an abrupt uncontrolled deceleration. Called at an interrupt level by
// realtime abort command and hard limits. So, keep to a minimum.
void mc_critical(ExecAlarm alarm) {
if (inMotionState() || sys.step_control.executeHold || sys.step_control.executeSysMotion) {
Stepper::reset(); // Stop stepping immediately, possibly losing position
// Stepper::stop_stepping(); // Stop stepping immediately, possibly losing position
}
send_alarm(alarm);
}
That’s basically saying if the alarm is raised while in motion (not sure what those others translate to), that it kills the steppers before sending the alarm.
It’s not clear to me if this is even being called in this situation. I don’t think this is being called when the alarm 5 is raised, but it’s possible it’s being called for another alarm prior to this like for soft/hard limits.
Maybe when the G91 is prior to the G38.2, it’s executing the G91 as a separate command.
I could just be completely wrong here too.
2 Likes
Interesting that the Stepper::stop_stepping() line is commented out. Looks like someone might have changed it to ::reset() without thinking of the consequences. The commit comment on that code revison might be interesting.
Looks like it was part of a larger change. Commit comment is “Queue alarms instead of using a global variable”. Both the reset and commented out stop_stepping were included in the same commit so it was at least considered. It was updated by Mitch who is a wizard at this stuff.
1 Like