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

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

Closed NickDevoctomy closed 3 years ago

NickDevoctomy commented 3 years ago

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

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

Thinkersbluff commented 3 years ago

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 commented 3 years ago

So it only happens after a factory reset?

Met vriendelijke groet, Sebastiaan Dammann

Van: Thinkersbluff notifications@github.com Verzonden: Thursday, December 24, 2020 3:27:51 PM Aan: CR6Community/Marlin Marlin@noreply.github.com CC: Sebastiaan Dammann sebastiaandammann@outlook.com; Comment comment@noreply.github.com Onderwerp: Re: [CR6Community/Marlin] Auto bed levelling no longer working with stock touch screen UI, branch extui-btt-skr-stock-tft (#87)

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.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCR6Community%2FMarlin%2Fissues%2F87%23issuecomment-750897562&data=04%7C01%7C%7C07ddea8150a84c10c9c408d8a81818ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637444168730270353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QKpjHF00LLmBclAalrkHBxKzQlE03z%2FhaRxwcyNJYRE%3D&reserved=0, or unsubscribehttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAK4FMKWDVOFXN3M5XHLDPTSWNFWPANCNFSM4VICSLBA&data=04%7C01%7C%7C07ddea8150a84c10c9c408d8a81818ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637444168730270353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TPWKqBBJWdH6urM%2B5hI%2FbDho8u8TPCl%2Fewp6cUj6m3U%3D&reserved=0.

NickDevoctomy commented 3 years ago

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

NickDevoctomy commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

image

Sebazzz commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@NickDevoctomy Can you detail the exact steps to reproduce?

NickDevoctomy commented 3 years ago
  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 commented 3 years ago

“ ...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 commented 3 years ago

@Thinkersbluff sounds like you can reproduce the issue?

Thinkersbluff commented 3 years ago

@Thinkersbluff sounds like you can reproduce the issue?

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

NickDevoctomy commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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

Thinkersbluff commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

Thinkersbluff commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

Will do, if it persists. Thanks.

Sebazzz commented 3 years ago

@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 commented 3 years ago

Gotcha. That explains it. Thanks.

Sebazzz commented 3 years ago

Reported upstream:

Requested option to keep heaters of the bed on:

Implemented already in this code base.