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.

Sign up for GitHub

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

Jump to bottom

[BUG] TFT35 Mesh Edit throws M14 and unable to adjust Mesh #2786

Closed
FrozenIceman01 opened this issue Apr 30, 2023 · 26 comments · Fixed by #2873
Closed

[BUG] TFT35 Mesh Edit throws M14 and unable to adjust Mesh #2786

FrozenIceman01 opened this issue Apr 30, 2023 · 26 comments · Fixed by #2873
Labels
bug Something isn't working

Comments

@FrozenIceman01
Copy link

FrozenIceman01 commented Apr 30, 2023 •
edited
Loading

Description

The latest GD TFT 35 V3 E3 build on the repository throws an m11 or M14 error after mesh adjustment and results in inability to adjust mesh further requiring a power cycle. In addition after the UBL is complete it locks up the display and requires a reset before it will accept commands again. This is the second half of the previous closed issue posted here:

#2782

Step 1: Flash firmware via SD Card (config, language. En, firmware, and tft35 icon folder)
Step 2: Preheat extruder to 240 c and bed to 70 c
Step 3: UBL mesh start, 9x9
Step 4: Save mesh in slot 0 and 1
Step 5: Open Mesh edit
Step 6: Select Mesh Point to travel to (Fail)
Step 7: Power Cycle Machine
Step 8: Preheat extruder to 240 c and bed to 70 c
Step 9: Home
Step 10: Disable UBL
Step 11: Load Slot 0 or 1
Step 12: Select Mesh points to verify and Adjust
Step 13: Repeat Step 12 Mesh point adjustment until TFT 35 throws an M11 or M14 error
Step 14: Attempt to adjust mesh point (Fail)
Step 15: Power Cycle Printer
Step 16: Repeat Steps 8 through 15 until all mesh points verified.

Expected behavior

  1. Able to adjust Mesh Points after UBL Mesh Start
  2. Able to adjust all Mesh Points without throwing an m11/M14 error resulting in a power cycle.

Actual behavior
TFT35 is unable to adjust the Mesh Point, Menu is NOT frozen. It just won't allow you to change the mesh point numeric value until you power cycle.

Hardware Variant

TFT35 V3 E3 connected to a SKR Mini E3
SKR Mini E3 V3

TFT Firmware Version & Main Board Firmware details

BIGTREE_GD_TFT35_V3.0_E3.27.x.bin
Marlin-2.1.2

Additional Information

  • Include a ZIP file containing your Configuration.h or use Pastebin and paste a link in this issue.
  • Provide pictures or links to videos that clearly demonstrate the issue.

Marlin.zip
20230429 TFT Install.zip
@FrozenIceman01 FrozenIceman01 added the bug Something isn't working label Apr 30, 2023
@FrozenIceman01 FrozenIceman01 changed the title [BUG] (TFT35 Mesh Edit throws M14 and unable to adjust Mesh [BUG] TFT35 Mesh Edit throws M14 and unable to adjust Mesh Apr 30, 2023
@kisslorand
Copy link
Contributor

kisslorand commented Apr 30, 2023 •
edited
Loading

@FrozenIceman01

Please check this file if it fixes your issue with M11 and M14. Also please check the navigation between mesh points (with the controls on the screen itself and the rotary encoder too) in MeshEditor menu as the FW in the link is based on PR #2776 which restores (broken by PR #2781) the circular column navigation in "MeshEditor" menu when using the screen touch controls (left, right), restoring it without affecting the rotary encoder's linear navigation style.

Also please describe what do you mean by "after the UBL is complete". Please describe the steps how the TFT locks up so I can reproduce it and eventually fix that.
Thx

@FrozenIceman01
Copy link
Author

Certainly, here are the specific steps I take when generating a mesh and wait for it to complete.

Generating Mesh

  1. Movement
  2. Bl: off
  3. UBL
  4. Start (wait for finish)
  5. Select Ok on Complete fill in mesh points
  6. Back

Here are the test results from your firmware file.

Homing:

  1. Heat/Fan
  2. TPU (wait for heat up)
  3. Back
  4. Back
  5. Movement
  6. Home
  7. Home

Load Mesh

  1. Movement
  2. Bed Level
  3. Bl Off
  4. UBL
  5. Load
  6. Slot 0
  7. Back
  8. Back
  9. Mesh Edit
  10. Adjust Mesh Points <- This is the step I failed after adjusting between 3 and 10 points in prior firmware
  11. Select Check Box after adjusted
  12. Periodically Save Adjusted Points
  13. Repeat Step 10 through 12

I then adjusted the mesh as normal. Your firmware file appears to have solved the M11 and m14 errors being thrown and I was able to adjust any number of mesh points without the failure, however the adjust point interface is incredibly slow.

What hat happened in the prior software build was that after adjusting between 3 and 10 points on step 11 it would throw a m11 and m14 and no longer allow me to adjust the point. It would let me select additional points but would not let me babystep the position untill I powered cycled it.

@kisslorand
Copy link
Contributor

kisslorand commented May 4, 2023 •
edited
Loading

after the UBL is complete it locks up the display and requires a reset before it will accept commands again

Does this still occur with the file provided?

the adjust point interface is incredibly slow

Can you please explain this? What is slow exactly? How is the interface "slow"? It became "slow" only with the file provided?

@FrozenIceman01
Copy link
Author

FrozenIceman01 commented May 4, 2023 via email

@kisslorand
Copy link
Contributor

kisslorand commented May 5, 2023 •
edited
Loading

Please test this version (v2). It's even more snappier than the original (master). Check if it exhibits the M11, M14 issue.
Also would be nice if you got some answers for earlier questions too.
Thx

@FrozenIceman01
Copy link
Author

FrozenIceman01 commented May 6, 2023 •
edited
Loading

Hello Kisslorand,

That V2 is fantastic! The responsiveness to the step adjustment is great!

For the other questions:
"after the UBL is complete" - This was after completion of Mesh Generation Step 5 (When you populate the final mesh points
"Does this still occur with the file provided?" - I just reran UBL and adjusted all of the bed points, it did not lock up at all. Nice work!
"Can you please explain this? What is slow exactly? How is the interface "slow" - This was the mesh adjustment steps, only adjust the steps, Your V2 solved the issue
" It became "slow" only with the file provided" - It became slow with V1, your V2 fixed it

New Bug:

  1. Mesh Generation Issue: On Generating Mesh Step 4, as it was going through the mesh generation, it would periodically echo bu-1.13, see image 1. It did not halt the mesh generation
    Image 1
  2. When Setting Z Probe distance it would throw a "????" error after I hit back. I troubleshooted this several times and it appears to consistently throw it if I hit "Mesh Edit" before the home move completes after I hit back in the Z Probe menu. Order of Operations: Select Z Probe off (to get into Z Probe Mode), Then adjust Z Probe (First in .1 then in .01 increments), with the menu save mesh, then hit back, after hitting back select mesh edit. Once it throws this issue I need to power cycle printer, preheat, align, and restart Z Probe See image 2.
    Image 2
  3. Z Probe Shim issue. I have found that I needed to use a 1.2mm shim when setting the nozzle position in the Z Probe alignment to not hit the bed when I mesh adjust. I have the default 0.2 shim selected on the TFT35 in the Z probe menu and needed to use 1.2mm of feeler gauge to keep the nozzle from hitting the bed (UBL is off) when I was adjusting the prior mesh I made. The result was .25mm of clearance between the nozzle and bed at the Z home position.
  4. Travel Speed, the new TFT firmware slowed down the travel speed to what appears to be 10%. It travels at normal speed when when homing but it does appear to be an issue when moving the X,Y, or Z positions through the movement display. I also verified this while printing too. It would not let me increase the speed from 10% to 100%. I had to change the setting on the Marlin interface side of the TFT.

Feature Request:
Add Auto Z Align somewhere on one of the movement screens. This is a Marlin Feature that auto indexes the Z axis like the Prussa winters do with dual stepper single drivers. I needed to go to Marlin to use the Auto Z Align feature (or send a G34 command in the text menu).

Overall, very nice work tracking this issue down!

@FrozenIceman01
Copy link
Author

FrozenIceman01 commented May 6, 2023 via email

@kisslorand
Copy link
Contributor

kisslorand commented May 7, 2023 •
edited
Loading

4. Travel Speed, the new TFT firmware slowed down the travel speed to what appears to be 10%. It travels at normal speed when when homing but it does appear to be an issue when moving the X,Y, or Z positions through the movement display. I also verified this while printing too. It would not let me increase the speed from 10% to 100%. I had to change the setting on the Marlin interface side of the TFT.

Please try to be more precise in your descriptions. I have no idea what is "movement display". What settings did you change on the Marlin interface? When you print, the XY travels are slower? What did you verified exactly while printing?

I checked the movement of the axes in Menu -> Movement -> Move menu and I cannot replicate any speed inconsistency. The movement speed there is according to what is set in the "config.ini" for Slow, Normal and Fast speeds and how it is set in Menu->Settings->Feature->MoveSpeed(X Y Z). If I set it to "Slow" the movements are slow, if I set it to "Normal" the movements are at normal speed and if I set it to "Fast" the movements are fast, all three options respecting the values set in "config.ini".

Are you talking by any chance about the "feed rate" that is adjustable by M220? If yes, can you check if this is case by going into "Terminal" menu and issue a M220 command and check the response? Is it any other value than 100%?

Anyhow, I cannot replicate the issue.

  1. Mesh Generation Issue: On Generating Mesh Step 4, as it was going through the mesh generation, it would periodically echo bu-1.13, see image 1. It did not halt the mesh generation

It must be some message from the motherboard, I cannot replicate it.

2. When Setting Z Probe distance it would throw a "????" error after I hit back. I troubleshooted this several times and it appears to consistently throw it if I hit "Mesh Edit" before the home move completes after I hit back in the Z Probe menu. Order of Operations: Select Z Probe off (to get into Z Probe Mode), Then adjust Z Probe (First in .1 then in .01 increments), with the menu save mesh, then hit back, after hitting back select mesh edit. Once it throws this issue I need to power cycle printer, preheat, align, and restart Z Probe See image 2.

Again, the description is very hard for me to understand. I do not know what is "Setting Z Probe distance", I do not know what is/where is the "Z Probe menu". I do not understand how to "with the menu save mesh" when you are adjusting "Z Probe".

What I think the steps are is:

  • go to Menu->Movement->Bed level->P Offset
  • press the button on the lower left corner, the one that was labeled "OFF"
  • adjust the nozzle height by Up/Down buttons on the TFT
  • with the button labeled "Next" select the next to the right button to be labeled as "Save" than press that "Save" button
  • press "Back"
  • whilst the printer is homing press "Mesh edit" button

I did these steps but I had no error whatsoever, after homing finished the mesh editor menu just displayed normally. I repeated these steps at least 10 times, never had any issue, no "????????" on my screen.

3. Z Probe Shim issue. I have found that I needed to use a 1.2mm shim when setting the nozzle position in the Z Probe alignment to not hit the bed when I mesh adjust. I have the default 0.2 shim selected on the TFT35 in the Z probe menu and needed to use 1.2mm of feeler gauge to keep the nozzle from hitting the bed (UBL is off) when I was adjusting the prior mesh I made. The result was .25mm of clearance between the nozzle and bed at the Z home position.

Sorry I do not understand what is the problem. Maybe make a clearer explanation what is the actual behaviour and what should be the expected behaviour.

@FrozenIceman01
Copy link
Author

FrozenIceman01 commented May 7, 2023 via email

@kisslorand
Copy link
Contributor

kisslorand commented May 7, 2023 •
edited
Loading

@FrozenIceman01

Please test this version (v3). Most probably the "?????" issue is solved.

Can you please check with M220 to see if it's the source of the slow speed issue?

@FrozenIceman01
Copy link
Author

FrozenIceman01 commented May 15, 2023 •
edited
Loading

I am still testing firmware, I was running into an issue with the last firmware where I was starting to see a Y Axis shift on long prints greater than 3 hours. I originally thought the issue was hardware or z offset side/fade and recrimped all my connectors, adjusted offset, and set fade to 0 without much change..

It ends up that it is TFT35 firmware side as when I switched to Marlin it didn't have any issues. I swapped back to TFT side and I verified that it wasn't a Z axis collision by pulling the filament out of the hot end half way through the print and saw the Y axis shift about 30 minutes later. I did reload the g code and verified that the error in the Z shift wasn't in the code, see attached.

I also uploaded your latest firmware tonight, I am still checking it out (including Z offset), however it did provide a list of unknown command error M2 and M error messages during a shorter print. See attached zip file. The speed change issue appears to be gone.

AA8_Toolhead Box Lid.zip

Now that I know it isn't my machine that is having issues, I'll continue to test your firmware.

@FrozenIceman01
Copy link
Author

FrozenIceman01 commented May 15, 2023 via email

@FrozenIceman01
Copy link
Author

FrozenIceman01 commented May 15, 2023 via email

@kisslorand
Copy link
Contributor

kisslorand commented May 16, 2023 •
edited
Loading

@FrozenIceman01

Do you have Y axis shift with "master" FW also?
I cannot reproduce Y axis shift, speed decrease, and involuntary "M" and "M2" messages. In fact I cannot reproduce any involuntary messages. I can only rely on your testing. What is the connection speed between the TFT and motherboard? Do you have Y axis shift only when printing in TFT mode and from TFT SD Card or also when printing in TFT mode and onboard SD Card too?

In the meantime please check this file (v4). It has improvements to v3 and also includes a rework based in the idea of PR #2788, a needed rework because that PR is only a partial fix whilst introducing a new bug.

@FrozenIceman01
Copy link
Author

FrozenIceman01 commented May 16, 2023 via email

@kisslorand
Copy link
Contributor

@FrozenIceman01

Master WF? I do not understand.

It was a typo, I meant "Master FW (firmware)".

@FrozenIceman01
Copy link
Author

FrozenIceman01 commented May 16, 2023 via email

@kisslorand
Copy link
Contributor

@FrozenIceman01

When did the speed reduction started? With what FW (firmware)?

BTW, for a quicker/easier conversation you can join a Discord channel I created for BTT TFT FW discussions.

@FrozenIceman01
Copy link
Author

FrozenIceman01 commented May 16, 2023 via email

@kisslorand
Copy link
Contributor

kisslorand commented May 16, 2023 •
edited
Loading

@FrozenIceman01

Can you please check if the speed reduction happens with the "master" FW also? Also please check in the terminal menu what is the response to the "M220" command.

@digant73 digant73 mentioned this issue May 18, 2023
Merged
@stale
Copy link

stale bot commented Jul 19, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the Abandoned label Jul 19, 2023
@kisslorand
Copy link
Contributor

Dear stale bot, let's wait a little bit longer, maybe @FrozenIceman01 will eventually help us to help him.

@FrozenIceman01
Copy link
Author

FrozenIceman01 commented Jul 19, 2023 via email

@kisslorand
Copy link
Contributor

kisslorand commented Jul 19, 2023 •
edited
Loading

You previously mentioned that you have a speed reduction issue (from 100% to 10%). It was never elucidated if it is inherited from the master or it is a new bug introduced by my builds. Because of this I never released a PR with the fixes provided to you, I cannot replicate any of your issues so I can rely only on your feedbacks.
Yes, there were some updates to the master since I provided the last version of the fixes (v4) but nothing major that would concern any of the issues discussed in this topic. If you think it is necessary I can build a new version of the fix to include the latest state of the master.

All I would like to know if the slowing down issue is only present with the builds I provided here or is it also present in the master too.

@stale stale bot removed the Abandoned label Jul 19, 2023
@FrozenIceman01
Copy link
Author

Hello @kisslorand, I managed to take some time this weekend and test the settings. The first is that I believe the speed issue is related to your V4 branch.

V4

I first adjusted the H offset using the Tuning screen below. I did adjust the increment a few steps
from .01 to .1. It is possible that selecting these changes the speed settings.
PXL_20230903_013959121

I then began to print a Plunger test print for PETG. Note this includes Z axis gantry align, 4 point align, and Unified Bed Level
AA8_Plunger.zip

As the print was warming up the speed indicator showed 203% in your firmware
PXL_20230903_013033639

I then started to see some odd commands being thrown.

PXL_20230903_013304820
PXL_20230903_013522457

And the Print failed.

I loaded the most recent Master BIGTREE_GD_TFT35_V3.0_E3.27.x.bin from 8/23 and tried again. Same H offset from the steps above and same print part.

This time it set the Speed to 100%

PXL_20230903_014140477

It also threw this two error codes and failed to print.
PXL_20230903_014330917

PXL_20230903_014352054

Worked fine on the Marlin Side.

@FrozenIceman01 FrozenIceman01 mentioned this issue Oct 3, 2023
Closed
@digant73 digant73 mentioned this issue Dec 21, 2023
Merged
@github-actions GitHub Actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked and limited conversation to collaborators Apr 14, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

cumulative patches + cleanup digant73/BIGTREETECH-TouchScreenFirmware
2 participants
@FrozenIceman01 @kisslorand