search

grblHAL / core

grblHAL core code and master Wiki
Other
310 stars 76 forks source link

Motion after HALT issued in paused canned cycle #271

Closed Amarpal89 closed 1 year ago

Amarpal89 commented 1 year ago

I encountered an issue today when I enacted a FEED HOLD and a subsequent HALT in the middle of the exectution of a canned cycle. Motion occurs after HALT is enacted.

The below g-code moves to X30.5 Y20 to start a G83 peck drill cycle down to Z-8.45 with 0.25mm pecks @ F100 and retract plane at Z-1.95. Repeating the same at Y0 & Y-20.

I paused it part way through the first cycle (somewhere around Z-7.0) with FEED HOLD and then I hit HALT. As soon as I did that it executed the move from Y20 to Y0 while at depth, gouging the part.

It is reproducable, the linked video has me hitting FEED HOLD then HALT in the middle of a peck drill cycle. https://youtube.com/shorts/EcZefOxvHzg

I will note that if I hit HALT in the middle of a canned cycle without FEED HOLD first then there is no subsequent motion and the controller acts as expected.

N0001 G17 G21 G94
N0002 (8MM HSS 90DEG COUNTERSINK)
N0003 S5000 M03
N0004 G54
N0005 M08
N0006 G90 G00 X30.5 Y20.
N0007 Z25.
N0008 G83 G98 R-1.95 Z-8.45 Q.25 F100.
N0009 Y0
N0010 Y-20.
N0011 G80 Z25. M09
N0012 G91 G28 Z0

Running a Flexi-Hal board with Flexi-HAL Prebuilt Firmware 0.9.2 Build 20230129

terjeio commented 1 year ago

grblHAL has two commands for aborting a cycle, either reset or stop, both works as intended when I check with ioSender, this with the latest version of the firmware. Could it be the pendant that causes this?

Amarpal89 commented 1 year ago

I'll see if it works as intended through iosender or if only a halt executed through the pendant is the culprit.

terjeio commented 1 year ago

Thinking a bit - it could be the sender continuing to send some commands after the halt. Which sender are you using? Again, when I check with ioSender and trigger a soft reset via the reset input it works as intended when Agressive buffering is enabled but not when it is disabled.

Amarpal89 commented 1 year ago

I am using iosender (latest from the github release, not edge) I have aggressive buffering disabled.

Amarpal89 commented 1 year ago

Just tested a few scenarios, can confirm that it only happens when using the pendant with Agressive buffering disabled. Every other permutation results in expected behaviour.

terjeio commented 1 year ago

It is a controller issue - if a reset is issued (via the reset input or a pendant issued reset) during execution of a command 'ok' is returned to the sender before the welcome message that tells the sender a reset occured. This leads to the sender transmitting the next line without knowing about the reset. The issue is present in legacy Grbl (and most ports?) - but not likely to occur often as it does not support canned cycles that takes a relatively long time to execute. I'll provide a fix in the next commit.

Amarpal89 commented 1 year ago

Barely 2hr from issue opened to you having the fix planned out, that's incredible. Thank you!

In the mean time issuing halt from the sender in the event of a feed hold from the pendant seems like a easy way to prevent unhappy accidents.