Auto bed levelling failed when called from Octoprint Mesh Vizualiser [BUG]

[JonBradbury]

Bug Description

When capturing a mesh using Octoprint Bed Level Visualiser I get a printer error popping up, the topuchscreen is yellow with "M112 Shutdown" error message (also, "Auto Homing failed" or similar).

Configuration Files

Configuration.zip

If you've made any other modifications describe them in detail here.

The Configuration.h file has PID autotune K* values set for hot end and bed, but this is not yet compiled into the FW running on the printer.

Steps to Reproduce

1. Log into Octoprint and select Bed Visualizer
2. Click "Update Mesh Now" (button, below visualizer graph)

Expected behavior:

Auto level completes normally and a new mesh is displayed in the Bed Visualiser.

Actual behavior:

Printer starts auto level warm up, homes, moves to the centre of the bed then crashes with error message on yellow touch screen.

Octoprint reports printer firmware error and disconnects.

Additional Information

Note: Printer is running a self compiled download of extui/latest (as of 09/12/20 13:00) , so it's several commits ahead of Alpha Rel 4. with Creality firmware 1.0.2 the feature is working.

[Unostot]

Hello,

I'm using the provided Release in conjunction with the mentioned Touchscreen Part: firmware-20201109-211912-hotfix3.bin CR-6-touchscreen-2020-11-06.zip

And have the same Problem. This means the first run with G29 runs through. After that a second try fails with the mentioned yellow-screen.

It moves down and a moment before it would touch the bed it stops and the screen turns yellow.

I have not tried it by manually calling twice, yet. (can do that tomorrow, if it helps) But when called via BedVisualizer (nothing fancy, just basic settings and G28, after that G29) it crashes every second call.

Greetings, Uno

[Thinkersbluff]

I had similar problems with the yellow warning screen coming up if I did Z-Offset homing from the screen, but only if I did not do AutoBed Leveling first... I was able to stop that from happening on my system by adjusting the RP1 potentiometer in the probe activation circuit. (I had already adjusted it in the opposite direction when I saw that the head was torquing counterclockwise each time it probed the bed) i.e. the problem was in my hardware configuration, not in the firmware, but it was a little inconsistent. Not saying that is your issue, but if you see the blue LED flickering when the carriage is slewing around for homing, you may find that the Bowden tube is pulling at the strain gauge and fooling the system into thinking there is a problem with the Homing process...

[JonBradbury]

Nope, my blue LED only comes on when the nozzle touches the bed. Moreover, Creality v1.0.2 doesn't exhibit this bug.

[Sebazzz]

@JonBradbury Please disable M112 on error in octoprint, and disconnect on error. Try again and provide the full Octoprint.log. Also carefully observe the nozzle as it homes and levels.

[JonBradbury]

@Sebazzz I can't right now - had to flash back to Creality latest to get the printer going again.

[Unostot]

Hello again,

I'm right now perfecting the level of my bed, using the screws in the heatbed. It still happens quite often that I can not G28 after a leveling.

But when I hold the bowden to ensure that it is not triggering the probe, it seems not to happen. But Right now I'm not 100% sure about this pattern. Octoprint sends then a M112 when the homing fails. (not disabled this, yet)

So from my observations over the last hour I would say its at least partly related to the bowden tube triggering the strain gauge before reaching the bed. This leads to an error and ultimatly to octoprint disconnecting.

But apart from hardware modifications (still searching for a good "bowdenholder" which stops this triggering...tried some ;) ): Is there some way for the firmware to deal with the strain gauge triggering without the bed near the nozzle? At least from the safety I think there is no good way, other than reminding the user that homing failed...and perhaps a notice "please check blue strain gauge LED when homing"...

Greetings, Uno

[Sebazzz]

@Unostot Can you take a picture of your printer set-up?

[Unostot]

@Unostot Can you take a picture of your printer set-up?

Sure I can, but what part exactly are you interested? (helps to give the right images and nothing useless ;) ) Its a quite "basic CR-6 SE" right now. I just don't use the useless clips to attach the bowden to the cable, so its "floating free".

[Sebazzz]

Its a quite "basic CR-6 SE" right now. I just don't use the useless clips to attach the bowden to the cable, so its "floating free".

That's what I was interested in 😀 Which exact firmware bin file are you running?

[Unostot]

Its a quite "basic CR-6 SE" right now. I just don't use the useless clips to attach the bowden to the cable, so its "floating free".

That's what I was interested in 😀 Which exact firmware bin file are you running?

The tests before my post were made without the blue cable strip. After my post I attached it, so I did not need to hold the bowden while leveling by hand ;)

So pretty "factory setting"

Firmware is: firmware-20201109-211912-hotfix3.bin and CR-6-touchscreen-2020-11-06.zip for the display.

I'm not sure right now, but I think the printer did also have a problem with homing, when he had the creality firmware, when the strain gauge was triggered by the bowden. But the yellow screen I'm not sure when I saw this thing the first time.

[Sebazzz]

Can you collect a log with M111 S247 before you reproduce the issue?

[Unostot]

So basically octoprint terminal output with m111 S247 set, no M112, and do: G28 some stuff G28 with triggered strain gauge"error or yellow screen of doom" ?

edited the horrible formatting and contend from email reply ;)

[Sebazzz]

Yes, exactly. You may need to download Octoprint.log to get a nice clean output.

[Unostot]

Well lets see.... I tried to trigger it by hand, but when I disabled M112 and the disconnect, I was not able to, for several tries. After that I enabled the disconnect and M112, and it got triggered (can try it if necessary without M112 later)

The octoprint.log has only some lines regarding this, seems right not now everything is bein written there:

2020-12-19 20:33:15,915 - octoprint.util.comm - INFO - Telling the printer to set the busy interval to our "communicationBusy" timeout - 1s = 2s
2020-12-19 20:42:59,788 - octoprint.util.comm - WARNING - Received an error from the printer's firmware: Printer halted. kill() called!
| Last lines in terminal:
| Recv: deploy: 1
| Recv: Is in probing zone: 1
| Recv: Opto switch says: 1
| Recv: FIX_MOUNTED_PROBE: Preparing for next probe tare
| Recv: echo:busy: processing
| Recv: <<< do_homing_move  X117.00 Y117.00 Z15.00
| Recv: Home 2 Slow:
| Recv: >>> do_homing_move  X117.00 Y117.00 Z15.00
| Recv: ...(Z, -6.00, 1.00)
| Recv:   current_position= X117.00 Y117.00 Z15.00 : Probe::set_deployed
| Recv: deploy: 0
| Recv: Is in probing zone: 0
| Recv:  T:101.43 /0.00 B:58.75 /0.00 @:0 B@:0
| Recv: echo:busy: processing
| Recv: Opto switch says: 0
| Recv: FIX_MOUNTED_PROBE: Taring probe
| Recv: echo:busy: processing
| Recv:  T:99.46 /0.00 B:58.52 /0.00 @:0 B@:0
| Recv: echo:busy: processing
| Recv: Error:Printer halted. kill() called!
2020-12-19 20:43:17,827 - octoprint.util.comm - INFO - No response from printer after 6 consecutive communication timeouts, considering it dead.
2020-12-19 20:43:17,833 - octoprint.plugins.stats - INFO - Printer Stats - on_event
2020-12-19 20:43:17,847 - octoprint.util.comm - INFO - Changing monitoring state from "Operational" to "Offline (Error: Too many consecutive timeouts, printer still connected and alive?)"
2020-12-19 20:43:18,054 - octoprint.plugins.action_command_notification - INFO - Notifications cleared

but I've copied the terminal output, too:

G29 uncorrected Z:2.95
Recv:  corrected Z:2.92
Recv:   current_position= X205.00 Y30.00 Z2.92 : sync_plan_position
Recv: X:205.00 Y:30.00 Z:2.92 E:0.00 Count X:16400 Y:2400 Z:1182
Recv: >>> do_blocking_move_to  X205.00 Y30.00 Z2.92
Recv: >  X117.00 Y117.00 Z2.92
Recv: <<< do_blocking_move_to  X117.00 Y117.00 Z2.92
Recv: <<< G29  X117.00 Y117.00 Z2.92
Recv: ok
Send: M155 S3
Recv: echo:M155 S3
Recv: ok
Recv:  T:119.43 /0.00 B:60.39 /0.00 @:0 B@:0
Recv:  T:118.00 /0.00 B:60.34 /0.00 @:0 B@:0
Recv:  T:116.14 /0.00 B:60.19 /0.00 @:0 B@:0
Recv:  T:114.17 /0.00 B:59.99 /0.00 @:0 B@:0
Recv:  T:111.97 /0.00 B:59.79 /0.00 @:0 B@:0
Recv:  T:109.76 /0.00 B:59.58 /0.00 @:0 B@:0
Send: G91
Recv: echo:G91
Recv: ok
Send: G28 Z0
Recv: echo:G28 Z0
Recv: >>> G28  X117.00 Y117.00 Z2.92
Recv: Machine Type: Cartesian
Recv: Probe: FIX_MOUNTED_PROBE
Recv: Probe Offset X0.00 Y0.00 Z0.10 (Aligned With & Above Nozzle)
Recv: Auto Bed Leveling: BILINEAR (enabled)
Recv: ABL Adjustment Z+0.023
Recv:   current_position= X117.00 Y117.00 Z2.92 : Leveling ON
Recv:   current_position= X117.00 Y117.00 Z2.94 : ...Now OFF
Recv:   current_position= X117.00 Y117.00 Z2.94 : sync_plan_position
Recv: Raise Z (before homing) by 15.00
Recv: >>> do_blocking_move_to  X117.00 Y117.00 Z2.94
Recv: >  X117.00 Y117.00 Z15.00
Recv: Opto switch says: 1
Recv: echo:busy: processing
Recv:  T:107.73 /0.00 B:59.38 /0.00 @:0 B@:0
Recv: echo:busy: processing
Recv:  T:105.59 /0.00 B:59.17 /0.00 @:0 B@:0
Recv: echo:busy: processing
Recv: <<< do_blocking_move_to  X117.00 Y117.00 Z15.00
Recv: >>> home_z_safely  X117.00 Y117.00 Z15.00
Recv:   current_position= X117.00 Y117.00 Z15.00 : sync_plan_position
Recv:   destination= X117.00 Y117.00 Z14.90 : home_z_safely
Recv: >>> do_blocking_move_to  X117.00 Y117.00 Z15.00
Recv: >  X117.00 Y117.00 Z15.00
Recv: <<< do_blocking_move_to  X117.00 Y117.00 Z15.00
Recv: >>> homeaxis(Z)
Recv:   current_position= X117.00 Y117.00 Z15.00 : Probe::set_deployed
Recv: deploy: 1
Recv: Probe::do_z_raise(10.00)
Recv: >>> do_blocking_move_to  X117.00 Y117.00 Z15.00
Recv: >  X117.00 Y117.00 Z15.00
Recv: <<< do_blocking_move_to  X117.00 Y117.00 Z15.00
Recv: >>> do_blocking_move_to  X117.00 Y117.00 Z15.00
Recv: >  X117.00 Y117.00 Z15.00
Recv: <<< do_blocking_move_to  X117.00 Y117.00 Z15.00
Recv: >>> is_homing_z (1)
Recv: Home 1 Fast:
Recv: >>> do_homing_move  X117.00 Y117.00 Z15.00
Recv: ...(Z, -375.00, [4.00])
Recv:   current_position= X117.00 Y117.00 Z15.00 : Probe::set_deployed
Recv: deploy: 0
Recv: >>> do_blocking_move_to  X117.00 Y117.00 Z15.00
Recv: >  X117.00 Y117.00 Z15.00
Recv: <<< do_blocking_move_to  X117.00 Y117.00 Z15.00
Recv: Is in probing zone: 0
Recv: echo:busy: processing
Recv: Opto switch says: 0
Recv: FIX_MOUNTED_PROBE: Taring probe
Recv:  T:103.42 /0.00 B:58.96 /0.00 @:0 B@:0
Recv: <<< do_homing_move  X117.00 Y117.00 Z15.00
Recv: Move Away:
Recv: >>> do_homing_move  X117.00 Y117.00 Z15.00
Recv: ...(Z, 3.00, 2.00)
Recv:   current_position= X117.00 Y117.00 Z15.00 : Probe::set_deployed
Recv: deploy: 1
Recv: Is in probing zone: 1
Recv: Opto switch says: 1
Recv: FIX_MOUNTED_PROBE: Preparing for next probe tare
Recv: echo:busy: processing
Recv: <<< do_homing_move  X117.00 Y117.00 Z15.00
Recv: Home 2 Slow:
Recv: >>> do_homing_move  X117.00 Y117.00 Z15.00
Recv: ...(Z, -6.00, 1.00)
Recv:   current_position= X117.00 Y117.00 Z15.00 : Probe::set_deployed
Recv: deploy: 0
Recv: Is in probing zone: 0
Recv:  T:101.43 /0.00 B:58.75 /0.00 @:0 B@:0
Recv: echo:busy: processing
Recv: Opto switch says: 0
Recv: FIX_MOUNTED_PROBE: Taring probe
Recv: echo:busy: processing
Recv:  T:99.46 /0.00 B:58.52 /0.00 @:0 B@:0
Recv: echo:busy: processing
Recv: Error:Printer halted. kill() called!
WARNING! Received an error from the printer's firmware, ignoring that as configured but you might want to investigate what happened here! Error: Printer halted. kill() called!
Send: G90
Recv: //action:poweroff

The behaviour is: It starts going down to home Z. But the strain gauge is already blue. It never touches the build plate. Instead it rises up again. Goes down again, and then seems to be confused that the strain gauge gets not triggered again, and after some distance it thinks something is wrong, and panics.

So the issue is more precise not the bed leveling but rather the homing in Z failing when straing gauge is triggered somehow other than touching the plate.

More logs are possible, if this is not enough or something is missing.

Greetings, Uno

[Sebazzz]

@Unostot Can you check if this build works better for you, if not, provide the logs? Try G28 and G29. firmware-20201219-210607.zip

[Unostot]

Can I flash this without changing the Touchscreen? Than I can try it right now I think.

[Sebazzz]

Can I flash this without changing the Touchscreen? Than I can try it right now I think.

Yes, you can if you run 4 alpha or newer.

[Unostot]

Can I flash this without changing the Touchscreen? Than I can try it right now I think.

Yes, you can if you run 4 alpha or newer.

flashed it, reports 2.0.7.2.

Basic leveling worked. I'm trying now to reproduce it like before.

Stil lthe same problem: When Z homing starts while the strain gauge is already triggered, it fails (but it seems this only applies if it was homed at least once before...not 100% sure about that part) octoprint.log (can I get more infos in there? Loggin Level seems set to DEBUG for me, but not sure right now)

2020-12-19 21:18:15,517 - octoprint.util.comm - INFO - Telling the printer to set the busy interval to our "communicationBusy" timeout - 1s = 2s
2020-12-19 21:24:17,138 - octoprint.util.comm - WARNING - Received an error from the printer's firmware: Printer halted. kill() called!
| Last lines in terminal:
| Recv: ok
| Send: G28 Z0
| Recv: >>> is_homing_z (1)
| Recv: Is in probing zone: 0
| Recv: echo:busy: processing
| Recv: Opto switch says: 0
| Recv: FIX_MOUNTED_PROBE: Taring probe
| Recv: FIX_MOUNTED_PROBE: Resetting endstop state
| Recv: Is in probing zone: 1
| Recv: echo:busy: processing
| Recv: Opto switch says: 1
| Recv: FIX_MOUNTED_PROBE: Preparing for next probe tare
| Recv: Is in probing zone: 0
| Recv: echo:busy: processing
| Recv: Opto switch says: 0
| Recv: FIX_MOUNTED_PROBE: Taring probe
| Recv: FIX_MOUNTED_PROBE: Resetting endstop state
| Recv: echo:busy: processing
| Recv: echo:busy: processing
| Recv: Error:Printer halted. kill() called!
2020-12-19 21:24:17,139 - octoprint.util.comm - INFO - Changing monitoring state from "Operational" to "Error: Printer halted. kill() called!"
2020-12-19 21:24:17,140 - octoprint.util.comm - INFO - Force-sending M112 to the printer
2020-12-19 21:24:17,161 - octoprint.plugins.stats - INFO - Printer Stats - on_event
2020-12-19 21:24:17,172 - octoprint.util.comm - INFO - Changing monitoring state from "Error: Printer halted. kill() called!" to "Offline (Error: Printer halted. kill() called!)"
2020-12-19 21:24:17,261 - octoprint.plugins.action_command_notification - INFO - Notifications cleared

Terminal:

Send: G28 X0 Y0
Recv: Opto switch says: 1
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: === is_homing_z = false (G28)
Recv: X:-5.00 Y:-2.00 Z:15.14 E:0.00 Count X:-400 Y:-160 Z:6000
Recv: ok
Send: G28 Z0
Recv: >>> is_homing_z (1)
Recv: Is in probing zone: 0
Recv: echo:busy: processing
Recv: Opto switch says: 0
Recv: FIX_MOUNTED_PROBE: Taring probe
Recv: FIX_MOUNTED_PROBE: Resetting endstop state
Recv: Is in probing zone: 1
Recv: echo:busy: processing
Recv: Opto switch says: 1
Recv: FIX_MOUNTED_PROBE: Preparing for next probe tare
Recv: Is in probing zone: 0
Recv: echo:busy: processing
Recv: Opto switch says: 0
Recv: FIX_MOUNTED_PROBE: Taring probe
Recv: FIX_MOUNTED_PROBE: Resetting endstop state
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: Error:Printer halted. kill() called!
Changing monitoring state from "Operational" to "Error: Printer halted. kill() called!"
Send: M112
Send: N2 M112*35
Send: N3 M104 T0 S0*34
Send: N4 M140 S0*97
Changing monitoring state from "Error: Printer halted. kill() called!" to "Offline (Error: Printer halted. kill() called!)"
Connection closed, closing down monitor

P.S. any other things to be careful with this firmware? Before going to bed later I want to start a print over night ;)

[Unostot]

Ok, I've tested a bit more... I'm rather sure now, that the yellow screen comes, when the straing gauge is being triggered too early by the bowden while homing. I've fixed the bowden, so that it does not get triggered, and while this is fixed, I can level again and again. As soon as I remove the fixation and the bowden sometimes triggers the strain gauge, the problem is back.

Now I don't can propose a software solution for this, since I don't think there is a reliable way. I think one needs to ensure that the strain gauge does not get triggered by the bowden tube. From the firmwares point of view, there is no difference If its correctly triggered or not. If we would ignore it at certain points, because we are sure it is a false alarm...at what point would we reenable? This is not possible by software.

So while the "crash" with yellow screen and reboot seems a bit overkill (but I'm not sure if this comes from octoprint or when using only the printer, too), the main problem seems to be a pushing bowden tube...

[Sebazzz]

Creality v4.5.2 motherboard firmware-crealityv452-20201223-002158.zip Creality v4.5.3 motherboard firmware-crealityv453-20201223-002246.zip Touch screen firmware CR-6-touchscreen-2020-12-23.zip

Can you please retry this with one of these firmware files, depending on the motherboard version you have. If you don't know or got a printer from November 2020 or earlier, you'Il most likely have the Creality v4.5.2 motherboard.

Assuming we got it fixed I will close this issue now and consider it fixed. If it isn't fixed please provide:

• Logs captured via Pronterface/Octoprint/PuTTY with M111 S247 entered for debug logging
• Pictures or a video as appropriate

Also, if it is fixed, I still would like to have a confirmation though😀