Closed fantasmag0ria closed 4 years ago
thisiskeithb
commented
4 years ago I can confirm this issues as well, but haven't gotten a chance to track down which commit broke things. It should be a fairly recent change since it was working not too long ago on LPC1768.
ellensp
commented
4 years ago Looks like M0 is also broken... so this make test 1 invalid (as it doesn't get into pause) 0ce83dee9560fc30f27fdddc450d3861725d9a22 seem to be when it breaks
Update:
Logic in GcodeSuite::M0_M1() line 105: Does not work as expected. Cannot call M0 hello (or any other string)
Orriginally: while (wait_for_user && (ms > 0 || PENDING(millis(), ms))) idle();
Changing it to while (wait_for_user || (ms > 0 && PENDING(millis(), ms))) idle(); seem to do as expected
ellensp
commented
4 years ago on current bugfix 2.0.x With M0 patched as above. Test 1 works as expected, without issues.
Printer is now online.
>>> m0 hello
SENDING:M0 HELLO
echo:HELLO
echo:busy: paused for user
echo:busy: paused for user
>>> m108
SENDING:M108
>>> m112
SENDING:M112
Error:Printer halted. kill() called!Test 2 also works as expected...
I generated a test gcode file that contains 5000 lines of g0 X, Y moves, from random point a to random point b inside a 200x200 print volume (no z moves). I then sent a M112 and it resulted in the machine instantly being killed.
Print started at: 22:46:13
>>> M112
SENDING:M112
Error:Printer halted. kill() called!I used a SKR v1.3 with and without lcd and no sdcard support. I can't test with TMC5160 drivers... so perhaps that makes a difference?
fantasmag0ria
commented
4 years ago Thanks for the investigation.
I'm using slightly older sources (for sure not released version) and a bit modified for CNC mill/router stuff. Mainly position reporting for G0, proper 'cnc' G10 and other minor things.
I will get the newest bugfix, apply @ellensp changes, compare with my current firmware and let you know if it works.
fantasmag0ria
commented
4 years ago I got the newest bugfix branch, built everything with and without @ellensp changes. I can confirm that the change fixes M112 issue but not M108 one.
I also built latest release branch and both issues are there. My config was the same only thing that changed were the source files.
ellensp
commented
4 years ago Cannot replicate.
Used latest Marlin bugfix 2.0.x Used your config files Updated your config files as serial number and motherboard name are out of date for bugfix. added spindle pin definitions for the following.
Compiled and tests fine with the same test.
Printer is now online.
>>> m0 hello
SENDING:M0 HELLO
echo:HELLO
echo:busy: paused for user
echo:busy: paused for user
>>> g1 z0
SENDING:G1 Z0
echo:busy: paused for user
echo:busy: paused for user
echo:busy: paused for user
>>> m108
SENDING:M108
echo:Home Z FirstIt even queued the g1 z0 and didn't try and execute it till after the M108 as expected.
github-actions[bot]
commented
4 years ago This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Bug Description
Both M108 and M112 don't work after M0 or buffer full.
My Configurations
Using Marlin 2.0. EMERGENCY_PARSER enabled. No LCD and SDCard disabled. SKR v1.3 (LPC1768). 3xTMC5160. 24V system. Controlled by CNCjs (windows and rPI)
Configuration.zip
Steps to Reproduce
1.
execute: "M0 whatever text" exexute: "M108" execute "M112"
Expected behavior: after M108 Marlin should stop sending "busy" messages and continue receiving commands. M112 should kill/restart the controller.
Actual behavior: Nothing, like both M108 and M112 have no effect. Controller restart (manual) is needed.
2.
execute: Plenty of long moves (G1/G0) to fill buffer execute "M112"
Expected behavior: after sending M112 controller should stop any movement and kill/restart the controller.
Actual behavior: Nothing, until buffer is empty (all moves done) and M112 goes through. Only then the controller is reset.
Additional Information