grblHAL
Maybe a bug around door and parking
Hello,
I've noticed a couple of odd things around using the Door switch (and parking) as a "pause" to intervene when things sometimes does not go to my liking... And that happens more than it should...
So here is first thing that happens:
I have a simple program that runs with two tools.
- I home the machine
- I do a M61Q70 (first tool) and probe using the probing tap on my tool probe.
- I run the program, and it starts and runs beautifully...
- I press my door switch, and trigger a pause and park maneuver - Z goes up and spindle stops.
- I stop my program
- I move my X-coordinate to get better material usage (first tool was just facing)
- I rewind the program and his start.
- It starts over and runs the first tool all good.
- I goes to the toolprobe and ask for the second tool
- I change tool
- $tpw and tool is probed
- It now proceeds to dig a 7mm deep hole in my spoilboard before i catch it with the emergency stop.
I've had this same scenario happen on a couple of cases. If i use the door and move things around, things usually go pearshaped later in the process. Unless i do a full reset and re-home. (i've no idea if that actually is necessary.)
The second situation is same scenario - a program with tool changes.
- I home the machine
- I do a M61Q70 (first tool) and probe using the probing tap on my tool probe.
- I run the program, and it starts and runs beautifully...
- I press my door switch, and trigger a pause and park maneuver - Z goes up and spindle stops.
- I stop my program
- I make some changes to workholding...
- To get out of the "door" mode, i hit start - spindle goes down to where it was. (as I guess it shold) and door mode disappear.
- Now to move the spindle to a safe position i hit the jog button up 10mm once - spindle goes up 10mm.
- I hit jog button up again, and nothing happens.
- I have to reset and start everything over - it seems like it's all locked up....
Please let me know what you think?`
Best Kristoffer
This will have to wait until I am back home in a couple of weeks since I do not have access to a machine.
No problem. Im intrigued to see if there is an actual issue or its just me
tor. 24. okt. 2024 kl. 07.53 skrev Terje Io @.***>:
This will have to wait until I am back home in a couple of weeks since I do not have access to a machine.
— Reply to this email directly, view it on GitHub https://github.com/grblHAL/core/issues/610#issuecomment-2434360961, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM3JUEEVHQ2BYHWH6OLMMZLZ5CDMNAVCNFSM6AAAAABQBIC6JSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZUGM3DAOJWGE . You are receiving this because you authored the thread.Message ID: @.***>
The first issue is likely due to the tool offset beeing reset when the Stop command is sent. I have changed this in the last commit. Both the tool offset and the last selected offset (G54...) is now preserved over a stop. I may have to add a setting to enable this... I am not able to reproduce the second issue (jog lock up), can you provide a minimal gcode file that fails that I can use for testing?
Hello terje,
thanks for looking into the issue and thanks for the fix.
Now it’s me that is away - but I’ll be back after Christmas, then I’ll find an example where the lockup occurs. I think all my g code files would reproduce the error - but let me test again
best
The first issue is likely due to the tool offset beeing reset when the Stop command is sent. I have changed this in the last commit. Both the tool offset and the last selected offset (G54...) is now preserved over a stop. I may have to add a setting to enable this......
Terje, thank you for implementing this, but it seems that it doesn't quite work, atleast not in my setup.
I'm currently running FlexiHAL 1.0.1.2 firmware and had the same problem with 1.0.1.0 and 1.0.1.1, if I run a Gcode program, press Feed Hold and then Stop (with the buttons in the Sender), it clears out TLOref/TLR and resets the WCS to G54, basically the opposite of what your fix from late last year should do. Maybe there is some sort of regression going on in the latest Core builds?
It is, new fix commited.
Thank you very much for the quick turnaround! The update sounds very promising!
We discussed this a bit yesterday evening over on the PrintNC Discord, and Andrew from Expatria found what may be a bug in IOsender, see the pic.
Also, in the same thread we discussed Reset and Stop behaviour in general, and it seems many of us are in agreement that it would be very nice if Reset didn't clear or TLR/TLO, and that Reset, Stop and a program running out didn't reset the active WCS back to G54. I assume that is a much bigger change, and not a bug as such, but I think it would be a great Quality of life improvement if it would be possible to make such a change :)
I am not too keen to change the behaviour of reset and is the reason I added the stop command. And according to NIST RS274NGC v3 3.6.1 G54 should be restored on program end:
"To end a program, program M2. To exchange pallet shuttles and then end a program, program M30. Both of these commands have the following effects.
- Axis offsets are set to zero (like G92.2) and origin offsets are set to the default (like G54).
- Selected plane is set to CANON_PLANE_XY (like G17).
- Distance mode is set to MODE_ABSOLUTE (like G90).
- Feed rate mode is set to UNITS_PER_MINUTE (like G94).
- Feed and speed overrides are set to ON (like M48).
- Cutter compensation is turned off (like G40).
- The spindle is stopped (like M5).
- The current motion mode is set to G_1 (like G1).
- Coolant is turned off (like M9)."
What could be done is to change the soft reset command to a stop command in the controller, either as a compile time option or perhaps as a small plugin. The wired reset/estop behaviour should not be changed.
The regression (from a bug fix) caused stop to behave like reset so I wonder if it is the reason for suspecting that ioSender sends reset instead. If not I would like to get the $I output from the controller that triggers the behaviour.
I am not too keen to change the behaviour of reset and is the reason I added the stop command. And according to NIST RS274NGC v3 3.6.1 G54 should be restored on program end:
"To end a program, program M2. To exchange pallet shuttles and then end a program, program M30. Both of these commands have the following effects.
- Axis offsets are set to zero (like G92.2) and origin offsets are set to the default (like G54).
- Selected plane is set to CANON_PLANE_XY (like G17).
- Distance mode is set to MODE_ABSOLUTE (like G90).
- Feed rate mode is set to UNITS_PER_MINUTE (like G94).
- Feed and speed overrides are set to ON (like M48).
- Cutter compensation is turned off (like G40).
- The spindle is stopped (like M5).
- The current motion mode is set to G_1 (like G1).
- Coolant is turned off (like M9)."
What could be done is to change the soft reset command to a stop command in the controller, either as a compile time option or perhaps as a small plugin. The wired reset/estop behaviour should not be changed.
The regression (from a bug fix) caused stop to behave like reset so I wonder if it is the reason for suspecting that ioSender sends reset instead. If not I would like to get the
$Ioutput from the controller that triggers the behaviour.
Yes, I think that what I was seeing was the above regression.
Thank you for the reply Terje! I understand, it definitely makes sense to make sure the behaviour is in line with NIST!
The problem as I see it isn't really that Reset clears out TLR as such, but rather that we need to clear out alarms that aren't (in my opinion) critical.
For example, if Soft Limits are triggered by a probe routine and we get an alarm, we lose TLR and need to re-establish TLR. It seems wrong to me that a pre-emptive soft limit triggering causes an alarm, but jogging into a soft limit at full speed does not.
Also, if the TLR could be stored and recalled in a fashion similar to any other work offset, that would be extremely helpful. That would solve the problem that the Z value of the WCS in practise gets lost when TLR is cleared.
Maybe this can be done by using Tool tables or something like that?
I'm definitely open to other workflows, if there is something I can do differently to work around the above.
I currently set my TLR by loading a 3D probe with the M6 Semi automatic tool change (Drews Fast toolchange at the moment, really nice), and then probe my stock and let the program load the first tool.
It works well, as long as I don't have any alarms 😅
For example, if Soft Limits are triggered by a probe routine and we get an alarm
FYI yesterday I added a setting flag for limiting probe moves:
The problem as I see it isn't really that Reset clears out TLR as such, but rather that we need to clear out alarms that aren't (in my opinion) critical.
I'll move the variables that holds the TLR to the area not cleared on a reset unless position is likely lost. Soft limits triggered executes a feed hold before the alarm is raised so position is not lost.
@Robin-SeaThrough, @andrewmarles I have now committed changes that hopefully will improve behaviour. Please open a new issue with link back to this if further discussion is required.