Closed Thinkersbluff closed 3 years ago
Homing Failed.zip Best I can do for a video clip showing the bug in action. Used time compression to speed up the boring bits. The transition from 16-point matrix to Level menu is shown in "real-time".
Additional Info: I also had a Homing Failed incident this way:
This is probably because of the sensor on the left side of the bed being triggered when the homing starts. Check the red lights if it is on and try again.
We will know for sure when @Thinkersbluff collects a log like detailed in the release notes.
We will know for sure when @Thinkersbluff collects a log like detailed in the release notes.
Oops. My bad. Sorry. I assume you mean this line in the release notes: "You can collect logging using M111 S247 and M928 log.txt - please collect logging, without it is practically impossible for us to help you. Use Pronterface or Octoprint to capture serial terminal output." I have not done that before, but should not be too difficult. I have a print running right now, which will end by 14:00 today. I will upload my log soon after that. I imagine you want me to start the logging, then perform the steps to create the bug, then save the log and upload it here.
This is probably because of the sensor on the left side of the bed being triggered when the homing starts. Check the red lights if it is on and try again.
I am not clear on your thinking, here. Once I have the log uploaded, I would appreciate more info if it confirms your suspicions.
I did make one adjustment to my system that may have an impact here - I tweaked RP1, just the slightest bit (half an eyelash's width) counterclockwise.
NOTE: I was amazed that such a slight adjustment of that screw clockwise caused the nozzle to push into the head and still not turn on the blue light, and an equally slight adjustment counterclockwise caused the light to stay on all the time, even when the head was up off the bed by 20mm. As an Electrical Engineer, it looks to me as though that potentiometer is not sized correctly, if the circuit is basically using it as a bridge to set a detection threshold. There should be at least a 1/4 or 1/2 turn of adjustment range in it, surely, not 1/12 or less....
I have tried 5 times, now, to capture a log.txt file - they just keep coming out empty, sorry. Here I attach a report I captured from the Octoprint Terminal screen + my comments. Hope it is enough. Bug#44Test Report.txt
For comparison, I have also uploaded a log of the terminal messages from when I run Z offset before auto level. ZOffset Baseline Log.txt
I did make one adjustment to my system that may have an impact here - I tweaked RP1, just the slightest bit (half an eyelash's width) counterclockwise.
Yes, that might have caused it. Try flashing the latest hotfix from the release page if you didn't already and readjust the potmeter. As you've noted, it only needs a very slight change. If you turn it too far, the function of the strain gauge inverses and you need to pull on the hotend (instead of pushing) to let the LED turn off.
Try flashing the latest hotfix from the release page if you didn't already and readjust the potmeter.
I feel dumb, now, but I can't find any link to a hotfix release. Is it compiled from the extui branch? I found that.
@Sebazzz I thank you for your patience.
I believe we can close this bug report, now.
With RP1 adjusted to require a slightly larger signal from the strain gauge when probing the bed, my printer is no longer experiencing this bug.
In my defence, the adjustment range of RP1 is crazy small. Creality really should consider increasing the range and putting out technical guidance on how to correctly calibrate it. We are going to have all kinds of trouble when these systems get older, eccentric nuts work loose, etc..
I now have it set so that the little blue light does not come on when you touch the bowden tube (which it did) or when you home XY (which it did). I hear a tiny tick noise again as the head first probes the bed (which I had so carefully "tuned" away)
With the Community Version 4 alpha firmware loaded (either baseline or hotfix 3) - If I select Auto-Level Bed and wait for it to complete, it returns to the Level menu upon completion, without waiting for me to push the "Back" button first. If I select the Z Offset button after the Auto-Level function has completed, the printer will Auto Home, slowly lower the Z axis until the optical switch is triggered, raise the Z axis briefly, then start to descend again, but it stops before the nozzle reaches the bed and displays a bright yellow screen that says, "Homing Failed !". I then have to cycle power to regain control of the printer.
If, instead, I select Z Offset on the Leveling menu first, after powering up, the Z Offset function works correctly. I can also select Auto-Level Bed after doing the Z Offset and it works as described above.
This is repeatable.
My Configurations
My Configs.zip
I have flashed firmware-20201109-211912-hotfix3.bin to the motherboard. I have flashed the v4 DWIN_SET to the display
Steps to Reproduce
Expected behavior: [What you expect to happen]
Expected printer to stay on display of 16 points grid at end of Auto-Level Bed routing, until I press "Back" Expected printer to complete the Z Offset function normally.
Actual behavior: [What actually happens]
Printer automatically exits Auto-Level Bed routine after measuring 16th point. Does not wait for "Back" button to return to the "Level" menu. When I select the Z Offset button on "Level" menu after first leveling the bed, the printer stops and displays, "Homing Failed" instead of returning to the "Level" menu.
Additional Information