Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto bed levelling returning early to the Z-offset screen after factory reset and subsequent leveling #87

Closed
NickDevoctomy opened this issue Dec 24, 2020 · 33 comments
Labels
hard to reproduce t:bug Something isn't working

Comments

@NickDevoctomy
Copy link

NickDevoctomy commented Dec 24, 2020

  • Be sure you have fully read the release notes and flashing instructions before posting an issue here
  • Check if there is an existing open issue that describes your problem and add your comments there
  • Check if your issue has been resolved on the latest source code - or if there is a closed issue pointing to the next release
  • Check that you have flashed the correct firmware for your device

Description

Auto bed levelling would previously auto home, heat bed and nozzle, and then level the bed. During which the UI would show which point is being levelled on the bed.

Steps to Reproduce

If this is a Bug Report, please describe the steps needed to reproduce the issue

  1. Power on
  2. Auto bed level

Expected behavior:

  1. Autohome
  2. Heat nozzle and bed to 120 / 50 respectively
  3. Test bed matrix and display on the UI as it progresses (at previously set temps)

Actual behavior:

  1. Autohome
  2. Heat nozzle and bed to 120 / 50 respectively
  3. Screen flashes up levelling matrix
  4. Levelling matrix disappears
  5. Nozzle and bed temps set to 0
  6. Printer runs though bed levelling

Additional Information

  • Include a ZIP file containing your Configuration.h and Configuration_adv.h files if you don't run a precompiled build
  • Which hardware configuration do you use? CR-6 SE or MAX? Which motherboard? Stock TFT, BTT TFT?
  • Provide pictures or links to videos that clearly demonstrate the issue.
  • Which exact firmware version did you flash? Provide a link to the download you have used.

I've attached a sample gcode of a calibration cube that worked as expected with my previous version. Unfortunately I cannot revert to my previous version as I didn't keep a copy and can't locate it in the revision history, so I can't do any checks against the previous version I had.

CCR6SE_xyzCalibration_cube.zip

Issues that do not follow this issue template will be closed

@NickDevoctomy
Copy link
Author

NickDevoctomy commented Dec 24, 2020

I can confirm that printing still seems to be working as expected after the levelling hicup, although it completed very slowly. Much slower than the previous version and without feedback on the UI.

@Sebazzz Sebazzz added the t:bug Something isn't working label Dec 24, 2020
@Sebazzz
Copy link
Collaborator

Sebazzz commented Dec 24, 2020

Are you able to reproduce and collect some logging? I think @grobux was able to do it once but not reproduce it after.

I've attached a sample gcode of a calibration cube that worked as expected with my previous version. Unfortunately I cannot revert to my previous version as I didn't keep a copy and can't locate it in the revision history, so I can't do any checks against the previous version I had.

How is the calibration cube relevant to this issue? 😉

@NickDevoctomy
Copy link
Author

NickDevoctomy commented Dec 24, 2020

The calibration cube is relevant to the issue as it shows how I'm also running auto bed levelling within a print.

Including any preheat logic that I have going on. Take it or leave it, it's additional information that I can use to reproduce the issue.

@NickDevoctomy
Copy link
Author

I will have a go at generating some logs and provide them here as requested, will try and do that today.

@Thinkersbluff
Copy link

I can confirm that the first Autobed Levelling after flashing the firmware also behaves this way on the stock CR-6. Not just a BTT issue. Subsequent leveling seems to work correctly, if it is not meant to stay on the 16-point display screen at the end of the cycle.

@Sebazzz
Copy link
Collaborator

Sebazzz commented Dec 24, 2020 via email

@NickDevoctomy
Copy link
Author

I'll try running it a few times in a row to see what happens...

@NickDevoctomy
Copy link
Author

Just ran it twice in a row, first time showed the behaviour described above, and second time worked. I must admit, I never recall this on the creality board firmware (community version) tbh. Once it's done its second run, I'll reboot the machine and see if it works first time then.

@Thinkersbluff
Copy link

So it only happens after a factory reset? Met vriendelijke groet, Sebastiaan Dammann

On my stock CR-6, I flashed the v5 pre-release, then ran Autobed Level and it worked correctly.
I then did a factory reset from the menu and the system behaved as described in this bug.

Seems to be a function of whether or not there is an existing mesh when the routine starts?

@NickDevoctomy
Copy link
Author

Worked perfect after the reboot too, thanks. That just leaves the speed, but then I guess that's probably personal preference so I'll play about with it a bit to suit my requirements.

@Sebazzz Sebazzz changed the title Auto bed levelling no longer working with stock touch screen UI, branch extui-btt-skr-stock-tft Auto bed levelling returning early to the Z-offset screen after factory reset and subsequent leveling Dec 24, 2020
@Sebazzz
Copy link
Collaborator

Sebazzz commented Dec 24, 2020

Got the log. It appears that after factory reset we quickly get the all the meshes through from Marlins bed leveling code, which confuses the touch screen.

@Sebazzz
Copy link
Collaborator

Sebazzz commented Dec 24, 2020

image

@Sebazzz
Copy link
Collaborator

Sebazzz commented Dec 24, 2020

I think I got it now - please try the latest sources and retry.

@InsanityAutomation That call for ExtUI::onMeshBedLeveling start needs to be moved down. There is no other way for the touch screen to distinguish between Marlin resetting the bed leveling mesh before probing and the actual probing itself, agree? I've changed this in 5e2edd0 but I'm not sure how the guys upstream think about that change.

@Thinkersbluff
Copy link

Thinkersbluff commented Dec 26, 2020

Looks like my system (stock CR6 TFT + 4.5.2 MB) is not yet performing as intended, testing the latest extui branch with most recent files timestamped approx 4pm, 25 Dec..

G29 from terminal ends on wrong screen (see log) though does run ABL in synch with display,

  1. On first run of G29 after M502, M500, heaters are off and ends on PRINTING screen.
  2. On 2nd run of G29 after mesh 1, heaters are on. Launched while on PRINTING screen and Ends on PRINTING screen.
  3. RUN ABL from LEVELING screen after capture of mesh 2 ends on LEVELING screen, heaters are on.
  4. RUN ABL from LEVELING screen after capture of mesh 3 ends on LEVELING screen, but heaters are off on first ABL after Factory Reset.

Issue87_25Decextui Test-log.txt

Circumstantial evidence from small sample suggests heaters on or off changes the mesh values:
MESHES_1-4.txt

@NickDevoctomy
Copy link
Author

Just got to try the latest fix and it didn't work as expected, this time it heated the hot end, but not the bed. Then when it started it turned off the hot end heater. Although it did continue to show the progress of the levelling process, so that bit is working now. For now I'll just run it twice after a factory reset.

@Sebazzz
Copy link
Collaborator

Sebazzz commented Dec 26, 2020

@NickDevoctomy Can you detail the exact steps to reproduce?

@NickDevoctomy
Copy link
Author

NickDevoctomy commented Dec 26, 2020

  1. Flash firmware
  2. Power on
  3. Auto bed level (from screen)

Same steps, nothing has changed, just being explicit here about this being the first time ABL is run from the screen.

@Thinkersbluff
Copy link

Thinkersbluff commented Dec 26, 2020

“ ...the first time ABL is run from the screen.”

No factory reset required to trigger this bug on your system? Worked first time on my system but behaves as reported in this bug if I then do a factory reset.

@NickDevoctomy
Copy link
Author

@Thinkersbluff sounds like you can reproduce the issue?

@Thinkersbluff
Copy link

@Thinkersbluff sounds like you can reproduce the issue?

Looks that way. Factory reset seems to reliably trigger this bug on my system.

@NickDevoctomy
Copy link
Author

Cool, my printer's in the process of printing unfortunately, so I can't mess about with it right now. I can try a simple factory reset and ABL once that's complete.

@Thinkersbluff
Copy link

Thinkersbluff commented Dec 27, 2020

@Thinkersbluff sounds like you can reproduce the issue?

Factory reset seems to reliably trigger this bug on my system.

UPDATE Happy to report that when I flashed my display with the latest* pinned DWIN_SET files, I lost the ability to reproduce the bug. (*The previous files I had flashed were timestamped 22 Dec. The new files I flashed are timestamped 23 Dec.)

First "Run ABL" after Factory Reset ran perfectly.
G29 from terminal ran perfectly.

I think this problem may be fixed.

@Sebazzz
Copy link
Collaborator

Sebazzz commented Dec 27, 2020

@NickDevoctomy Can you please confirm this as well?
CR-6-touchscreen-2020-12-27.zip

@Thinkersbluff
Copy link

RATS - Using the display firmware CR-6-touchscreen-2020-12-27.zip + the latest motherboard F/W source as of 10pm Montreal time 27 Dec, the first ABL after Factory reset is again without heaters. :(

@Sebazzz
Copy link
Collaborator

Sebazzz commented Dec 28, 2020

Got it! I was now able to reproduce that the heaters are turned off after probing.

Exact reproduction steps:

  1. Reset printer to factory settings
  2. Reboot printer (M997)
  3. Start print with G28,G29 in start gcode
  4. After G29 completes, the heaters are turned off.

@Sebazzz
Copy link
Collaborator

Sebazzz commented Dec 28, 2020

I thought it was the hot-end idle timeout but it isn't.

Didn't capture anything useful either:

echo:busy: processing
echo:busy: processing
<<< do_blocking_move_to  X225.00 Y10.00 Z6.77
<<< Probe::probe_at_point  X225.00 Y10.00 Z6.77
Mesh level index: 16
Saving DWIN LCD setting from EEPROM
echo:Settings Stored (747 bytes; crc 65530)
//action:notification Settings Stored
SetNewScreen: 37
echo:busy: processing
//action:notification issue87-cube.gcode
  current_position= X225.00 Y10.00 Z6.77 : Probe::set_deployed
deploy: 0
>>> do_blocking_move_to  X225.00 Y10.00 Z6.77
>  X225.00 Y10.00 Z6.77
<<< do_blocking_move_to  X225.00 Y10.00 Z6.77
  current_position= X225.00 Y10.00 Z6.77 : > probing complete
Bilinear Leveling Grid:
      0      1      2      3
 0 +0.217 +0.134 +0.054 -0.026
 1 +0.161 +0.072 -0.042 -0.103
 2 +0.086 -0.010 -0.085 -0.153
 3 +0.006 -0.104 -0.150 -0.162
G29 uncorrected Z:6.77
 corrected Z:6.78
  current_position= X225.00 Y10.00 Z6.78 : sync_plan_position
<<< G29  X225.00 Y10.00 Z6.78
echo:G1 X0 Y0 Z15 F5000.0
echo:G1 Z2.0 F3000
echo:G1 X0.1 Y20 Z0.3 F5000.0
echo:G1 X0.1 Y200.0 Z0.3 F1500.0 E15
Writing to file: /PLR

@Sebazzz
Copy link
Collaborator

Sebazzz commented Dec 28, 2020

This should now be fixed. I need to submit this bug upstream because this affect anyone with these settings.

@Thinkersbluff
Copy link

Not sure if related, but I started RUN ABL with system heated to PETG pre heat values on the latest CF5 builds and the target temps changed to 120/50 at point 2. Point 1 still displayed the PETG target temps.

I know - don’t do that, then... Just sayin’ in case ;)

@Sebazzz
Copy link
Collaborator

Sebazzz commented Dec 29, 2020

Not sure if related, but I started RUN ABL with system heated to PETG pre heat values on the latest CF5 builds and the target temps changed to 120/50 at point 2. Point 1 still displayed the PETG target temps.

I can't reproduce it. If you have a good scenario, please open a separate issue.

@Thinkersbluff
Copy link

I can't reproduce it. If you have a good scenario, please open a separate issue

Will do, if it persists. Thanks.

@Sebazzz
Copy link
Collaborator

Sebazzz commented Dec 29, 2020

@Thinkersbluff It appears to be an upstream bug:

When the heaters are paused for probing, they aren't actually paused, the HOTEND_IDLE_TIMEOUT function is used for expiring the timers. But now the idle temperatures have been set to 120C/50C it resets to that.

@Thinkersbluff
Copy link

Gotcha. That explains it. Thanks.

Sebazzz added a commit that referenced this issue Dec 29, 2020
…EATERS_OFF

Previously the HOTEND_IDLE_TIMEOUT was (ab)used for disabling the heaters, but HOTEND_IDLE_TIMEOUT doesn't necessarily turn off the heaters. It just may set them to a lower temperature. In addition, some people like to level at a high temperature and we do not want to reset their temperature.

Fixes #87 also
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hard to reproduce t:bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants