search

CR6Community / Marlin

This Marlin fork has the goal of cleaning-up the source code changes for the CR-6 so it can be merged upstream. We also want to extend the functionality to make it fully functional
GNU General Public License v3.0
474 stars 82 forks source link

[BUG] Auto leveling error #39

Closed Schallabajzr closed 4 years ago

Schallabajzr commented 4 years ago

Bug Description

When I try to level the second time (within the same power cycle) it crashes with M112 Shutdown on the screen.

Recv: Opto switch says: 1 Recv: FIX_MOUNTED_PROBE: Preparing for next probe tare Recv: echo:busy: processing Recv: Error:Probing Failed Changing monitoring state from "Operational" to "Error: Probing Failed" Send: M112 Send: N3 M112*34 Send: N4 M104 T0 S0*37 Send: N5 M140 S0*96 Changing monitoring state from "Error: Probing Failed" to "Offline (Error: Probing Failed)" Connection closed, closing down monitor

My Configurations

Alpha 5 and newest screen firmware

Steps to Reproduce

My leveling code: M155 S30 ; set temperature reporting delay, use a value longer than the time it takes for your leveling command to complete. @BEDLEVELVISUALIZER ; instruct plugin to start recording responses from printer. G28 ; home G29 T ; report the bed leveling mesh points. M155 S3 ; set the temperature reporting delay back to a shorter time span.

Expected behavior: Ability to ABL during same power cycle.

Actual behavior: Crashes on 2nd run.

Schallabajzr commented 4 years ago

Also happens when triggering ABL from printer menu.

Ranney1 commented 4 years ago

Knows issue. @Sebazzz it is the same issue as I opend earlyer. If you home between, it is working. A simple work around is setting this up in the firmware. (Probe failed = 1 retry with home between). This was for me the solution.

Note: the printer is only showing an error with probing. I see that (a plugin with octoprint?) is sending the M112 code.

Sebazzz commented 4 years ago

Please collect logging via M111 S247 to better see what is going on. Also that a video of the issue please.

Homing and retrying does not make sense, the probe is tared every time a Z-direction move is made. It would not make sense to home it, that would make even more variables go into play. I suggest to modify the sensitivity of your strain gauge and remove any non-stock bowden clips.

Schallabajzr commented 4 years ago

@Sebazzz https://marlinfw.org/docs/gcode/G029-abl.html

The printer must be homed with G28 before G29.

Will provide a log as soon as I finish reassembling my hot end.

Schallabajzr commented 4 years ago

@Ranney1 Yes that is BedVisualiser plugin. And the gcode I posted is the code that it executes to generate the mesh.

Sebazzz commented 4 years ago

@Sebazzz https://marlinfw.org/docs/gcode/G029-abl.html

The printer must be homed with G28 before G29.

Will provide a log as soon as I finish reassembling my hot end.

I understand, but we're doing the same as Creality: Check if the position of all axis are known, if they are, we home the Z only, otherwise we do a regular home of all axes.

Schallabajzr commented 4 years ago

@Sebazzz is that really safe? What is I move the bed?

I don't have expertise in 3d printers but I imagine X Y Z are calculated via odometry? I can imagine a situation when the saved coordinates are just wrong in the printer settings, bed leveling thinks X and Y are homed and fails.

... just trying to say there is so much potential to fail and hard to debug if anything messes with the internal X Y. I mean that is the whole point why Roombas use SLAM, and I have learned to never just trust coordinates.

Schallabajzr commented 4 years ago

Video of the error. The jumps are pauses in video to reduce file size.

https://1drv.ms/v/s!Ai7k4vIftfUfhYQFZXu-RbJnNXJ98Q?e=54n9Rw

And the log from OctoPrint terminal: Recv: echo:busy: processing Recv: T:116.14 /120.00 B:49.72 /50.00 @:57 B@:21 Recv: T:116.01 /120.00 B:49.74 /50.00 @:59 B@:18 W:1 Recv: T:115.95 /120.00 B:49.74 /50.00 @:59 B@:18 W:0 Recv: echo:busy: processing Recv: T:115.88 /120.00 B:49.74 /50.00 @:60 B@:18 Recv: Opto switch says: 1 Recv: FIX_MOUNTED_PROBE: Preparing for next probe tare Recv: echo:busy: processing Recv: T:115.98 /120.00 B:49.74 /50.00 @:58 B@:19 Recv: Error:Probing Failed Changing monitoring state from "Operational" to "Error: Probing Failed" Send: M112 Send: N3 M112*34 Send: N4 M104 T0 S0*37 Send: N5 M140 S0*96 Changing monitoring state from "Error: Probing Failed" to "Offline (Error: Probing Failed)" Connection closed, closing down monitor

Schallabajzr commented 4 years ago

@Ranney1

Note: the printer is only showing an error with probing. I see that (a plugin with octoprint?) is sending the M112 code.

I looked through my plugins and can't find what sends the M112. Is there a way to see that?

image

Sebazzz commented 4 years ago

Connect to your computer to make sure Octoprint is not the problem (for the record: I don't think it is).

Schallabajzr commented 4 years ago

@Sebazzz full log you requested M111 S247 LOG.txt

Schallabajzr commented 4 years ago

Connect to your computer to make sure Octoprint is not the problem (for the record: I don't think it is).

Without OctoPrint it doesn't crash with M112. It gets stuck on 2nd bed leveling and never moves to point 1.

Sebazzz commented 4 years ago

So you only have this issue when leveling from Octoprint or another host?

Schallabajzr commented 4 years ago

@Sebazzz I mean it doesn't work with no hosts connected. It just gets stuck on 1st point of 2nd leveling, instead of Octoprint catching the error and sending an M112.

Schallabajzr commented 4 years ago

I have waited for 15 minutes to see if it will move if I press ABL back to back (the printer screen) and it didn't.

Schallabajzr commented 4 years ago

The only difference is that Octoprint recognizes the error and shuts down the printer instead of leaving it hanging. Don't know if that is stock or a plugin, but either way it is a bug.

Sebazzz commented 4 years ago

In the log you provided I don't see a G29 failing. I see a homing and successful leveling procedure.

Schallabajzr commented 4 years ago

In the log you provided I don't see a G29 failing. I see a homing and successful leveling procedure.

I didn't look at the log it is possible I exported it wrong. Will try again after my current print finishes.

All I can tell you currently is that if you press ABL for the 2nd time in a row it never goes through the 16 points and is stuck at the "waiting for temperature to reach screen". If I use my Octoprint instead of waiting it crashes with a M112 command.

Ranney1 commented 4 years ago

I've got the same experience but have a workaround. Later today I will undo the workaround and compile some debugging firmware. Maybe that I can reproduce it and provide logging.

Ranney1 commented 4 years ago

@ZanSchaffer i will check te plugin list later (when I am at home). Normally, M112 is a manual emergency stop. An app can trigger this also.

For me, I have made a loop:

Maybe that an app you have Installed what is triggering this. (You can retry when disabling all plugins, but this wil not fix the problem.

Schallabajzr commented 4 years ago

@ZanSchaffer i will check te plugin list later (when I am at home). Normally, M112 is a manual emergency stop. An app can trigger this also.

For me, I have made a loop:

  • serial connection closed => power printer off
  • temp out of range => M112 ==> power printer off
  • printer report fault => M112 ==> printer power off

Maybe that an app you have Installed what is triggering this. (You can retry when disabling all plugins, but this wil not fix the problem.

I am fine and prefer it working like this to be honest (printer report fault => M112 ==> printer power off) . It is fine if I only level it once so the printer is usable. But it is still an issue and I think others will have the same problem. Especially because it can be reproduced on the machine without any hosts.

Sebazzz commented 4 years ago

firmware-20201108-112356-hotfix1.zip firmware-20201108-125953-hotfix2.zip

Either of these might fix the issue for you.

Schallabajzr commented 4 years ago

@Sebazzz hotfix 2 same problem Recv: T:114.72 /120.00 B:49.85 /50.00 @:63 B@:14 W:0 Recv: echo:busy: processing Recv: FIX_MOUNTED_PROBE: Disabling probe Recv: FIX_MOUNTED_PROBE: Taring the probe Recv: echo:busy: processing Recv: echo:busy: processing Recv: Opto switch says: 0 Recv: echo:busy: processing Recv: echo:busy: processing Recv: Error:Probing Failed Changing monitoring state from "Operational" to "Error: Probing Failed" Send: M112 Send: N2 M112*35 Send: N3 M104 T0 S0*34 Send: N4 M140 S0*97 Changing monitoring state from "Error: Probing Failed" to "Offline (Error: Probing Failed)" Connection closed, closing down monitor

Sebazzz commented 4 years ago

Please check the section on reporting issues for collecting a full log: https://github.com/CR6Community/Marlin/releases/tag/v2.0.7.1-cr6-community-release-4-alpha

Please save and log files and attach it.

Please also try these steps: https://github.com/CR6Community/Marlin/issues/41#issuecomment-723511715

Schallabajzr commented 4 years ago

Please check the section on reporting issues for collecting a full log: https://github.com/CR6Community/Marlin/releases/tag/v2.0.7.1-cr6-community-release-4-alpha

Please save and log files and attach it.

Please also try these steps: #41 (comment)

I tried it again and it worked for some reason (multiple tests). Consider issue closed with hotfix 2. Thank you.

Sebazzz commented 4 years ago

Glad to hear it. Thank you.