M226 (pause) ignored
-
My Duet Wifi just ran past an M226 (https://duet3d.com/wiki/G-code#M226:_Gcode_Initiated_Pause) in my gcode without pausing. Is there something else I need to do to make it pause?
Firmware Name: RepRapFirmware for Duet WiFi
Firmware Electronics: Duet WiFi 1.0
Firmware Version: 1.18.1 (2017-04-09)
WiFi Server Version: 1.03 (ch fork)
Web Interface Version: 1.15a -
No, you shouldn't need to do anything else. Can you reproduce this?
-
To make what happened even stranger, I restarted that print (with the same M226 near the end of layer 4), and it didn't pause. I manually paused it, swapped filament, and let it print. When I came back an hour or two later, it looked like it was done so I pulled it off the bed. Which was still warm. Then I realized it had paused by itself around layer 50! Could have restarted it if I hadn't pulled the print off. Very strange.
That said, I wasn't able to reproduce either glitch. When I tried again, M226 worked as expected.
Probably some form of pilot error (but I distinctly remember putting the M226 right before the end of layer 4)…
-
I have ran into similar glitches here and there….. at random times even with homing completed my printer will crash the nozzle into the bed.... it happens after some random number of prints during the homing routine emergency stop doesnt resolve it when this happens and I have to power cycle the system to get a successful homing sequence.
When this happens it isnt lack of IR trigger..... its like the system looses its mind and sends the X and Y in slow motion and the head never reaches the center of bed before Z. Luckily its easy to see coming because this happens at a slow speed compared to what my homing sequence speed is.
It is completely random so hard to reproduce.
-
I have ran into similar glitches here and there….. at random times even with homing completed my printer will crash the nozzle into the bed.... it happens after some random number of prints during the homing routine emergency stop doesnt resolve it when this happens and I have to power cycle the system to get a successful homing sequence.
When this happens it isnt lack of IR trigger..... its like the system looses its mind and sends the X and Y in slow motion and the head never reaches the center of bed before Z. Luckily its easy to see coming because this happens at a slow speed compared to what my homing sequence speed is.
It is completely random so hard to reproduce.
Which firmware version?
-
First post shows:
Firmware Version: 1.18.1 (2017-04-09) -
I have ran into similar glitches here and there….. at random times even with homing completed my printer will crash the nozzle into the bed.... it happens after some random number of prints during the homing routine emergency stop doesnt resolve it when this happens and I have to power cycle the system to get a successful homing sequence.
When this happens it isnt lack of IR trigger..... its like the system looses its mind and sends the X and Y in slow motion and the head never reaches the center of bed before Z. Luckily its easy to see coming because this happens at a slow speed compared to what my homing sequence speed is.
It is completely random so hard to reproduce.
Which firmware version?
Both 1.18 and 1.19beta8 just today had a couple more occurances. The first one was pretty bad finished printing a bearing and started printing another right after…. the z height was out of whack so i stopped the print because it was out of babystepping range and hit the homeall button.
This time the behavior was quite different instead of everything being in slow motion it was fast really fast with the Z coming up before the head made it to the middle of the bed but it faulted with an error this time stating something about triggering too soon (maybe a difference between 1.18 and 1.19 probe detection?). I tried a couple more times after jogging the z down and the same result so i power cycled and everything went back to normal.
The second time today i cancelled a print and the Z ran all the way down to the bottom (odd behavior but its done this before) so i rehomed and again with the slow motion and failed home.
It always works as expected after power cycling but every now and then it gets a mind of its own.
-
-
Seems like the bug revolves around the pause routine in both 1.18 and 1.19
-
Thanks, that gives me something to go on. Are you sure that it only happens when you have previously paused? Which is the latest 1.19 beta version you have seen it in?
-
I believe thats it. I didnt really put it together until seeing this guys thread
-
I do not home after every pause cancel just because I am itterating so many so quickly…. but it seems that eventually Z becomes out of whack and then i rehome and then it shows its ugly face.
The main tell tail is my homing sequence is set to send xy to center of bed at 300mm/s then Z catches up at a slow 6.7mm/s when working normally
when the bug shows up X and Y do not keep up with Z causing a crash
even when the bed came from the bottom the head didnt make it to center in time
but other random symptoms occur as well
-
i ran into a similar issue when starting mesh level, I get the same error "Z probe already triggered" on 1st probe but clear alarm and runs 2nd time fine. I am also noticing a weird x-y movement. after home z finishes( with PH in middle of bed), it moves the print head all the way to the back left corner then deploys probe and moves to front right corner while raising bed to start probing. pin is deployed and not touching bed until 1st probe point reached so i am at a loss to explain the error state. (I am still on version 1.18) on 1st probe ph crashes into deck but eventually it appears z end stop fires and it goes into alarm. then i can clear alarm and redo mesh level fine. Here is the kicker, i tried to micro step through commands and get same error. i know probe is deployed with no alarm when it 1st probes so dont understand why i am getting that error at all. Is that what Whitewolf is describing above? to be clear, this appears to happen with and without a pause.
-
I dont always get the alarm, in fact this is the first occurrence of it…. usually i just get a crash.
But your erratic behavior sounds like it might be similar. It might not be because of a pause and rather something to do with probing it just happens that i probe after noticing z offset is out of whack.
i cant simply clear the alarm.... as seen above in the log the problem is persistent once it happens until power cycle
-
Also have you paused and just gone a while without probing after the pause…. because it could be possible that we just dont see the condition until attempting to probe after