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

layer height doesn't update at each layer change and extruder icon issue #1314

Closed
Chukozor opened this issue Nov 30, 2020 · 19 comments
Closed
Labels
bug Something isn't working

Comments

@Chukozor
Copy link

I tried the firmware in the folder "copy to SD", unified menu, TFT35 3.0, used in the commit 198f14e (on a BTT SKR 1.3).

I found two issues :

 - the "first icon" extrude in the menu shows preheat menu (the other extrude icon below "move" is working fine).
 - during print, layer height doesn't update at each layer change. Sometimes it updates, sometime it doesn't.
@Chukozor Chukozor added the bug Something isn't working label Nov 30, 2020
@Chukozor Chukozor changed the title [BUG] (short description) layer height doesn't update at each layer change and extruder icon issue Nov 30, 2020
@oldman4U
Copy link
Contributor

Hi.

The first "issue" is a feature which was implemented to make sure that a preheat is made before extrusion. It caused confusion and will be changed with the next release of the firmware.

Regarding Layer hight. Does this happen while printing from on board SD or a storage which is attached to the TFT? When it does not update, do you mean it updates late or does it update to a wrong value or does it skip certain layer hight at all?

Please let us know, thank you

@kisslorand @radek8

@kisslorand
Copy link
Contributor

@Chukozor Do you use ARC in your gcode? (G2, G3)
With G2, G3 commands the TFT doesn't capture the X, Y, Z coordinates.

@Chukozor
Copy link
Author

no, there is only G0 and G1 in the gcode I used

@Chukozor
Copy link
Author

@oldman4U ok thanks.
For the layer issue, I printed with SD card on TFT in TFT mode it skips certain layer height on the screen but not in the print (hopefully).

@oldman4U
Copy link
Contributor

oldman4U commented Nov 30, 2020 via email

@Chukozor
Copy link
Author

@oldman4U I don't know, I only updated the firmware yesterday and made one print.
The layer stopped updating at 0.85mm height.
Here the gcode I used

@oldman4U
Copy link
Contributor

.85 or .75?

@oldman4U
Copy link
Contributor

Forget it.

Initial layer hight is .25 and all following are .2. All good.

Testing it with a dry print at 999% speed;-)

@oldman4U
Copy link
Contributor

Could you please try it again and next time the Layer hight stops - click on More and then Back - to see if the Layer hight updates to the correct value.

Thank you

@Chukozor
Copy link
Author

ok I'll try that, but I won't be able to print for several days. I'll try this for sure next print. Thanks

@oldman4U
Copy link
Contributor

If you want, you can close this ticket.

I am able to reproduce the issue here, so next I will find out which PR caused this and contact the developer.

Thank you

@Chukozor
Copy link
Author

thanks!!!

@kisslorand
Copy link
Contributor

kisslorand commented Dec 1, 2020

I found the bug. It was introduced by PR #1272.
During printing the actual coordinates are not pulled from printer, they are gathered from the sent gCode. The mentioned PR was getting info from printer (mainboard/Marlin), which was not given.
A PR might follow or you can just edit PrintingMenu.c:
instead of:
if(curLayer != coordinateGetAxisActual(Z_AXIS)){ curLayer = coordinateGetAxisTActual(Z_AXIS);
write:
if(curLayer != coordinateGetAxisTarget(Z_AXIS)){ curLayer = coordinateGetAxisTarget(Z_AXIS);

Actual coordinates are obtained by sending M114 to Marlin, which is not done during printing to avoid unnecessary serial traffic while printing.

PR #1319 fixes this.

Later edit:
All of the above is true while printing from the USB or SD attached to the TFT. Printing from onboard SD is different. Latest commit from the above mentioned PR should take care now of both situations.

@Chukozor
Copy link
Author

Chukozor commented Dec 3, 2020

Hi again, @kisslorand I tried what you wrote and I had the issue "nozzle dives in the bed" at each layer on the same point (not even at the layer change). You can see the effect on the photo here.
So I re-opened the issue to report that it's not fixed by this :

I found the bug. It was introduced by PR #1272.
During printing the actual coordinates are not pulled from printer, they are gathered from the sent gCode. The mentioned PR was getting info from printer (mainboard/Marlin), which was not given.
A PR might follow or you can just edit PrintingMenu.c:
instead of:
if(curLayer != coordinateGetAxisActual(Z_AXIS)){ curLayer = coordinateGetAxisTActual(Z_AXIS);
write:
if(curLayer != coordinateGetAxisTarget(Z_AXIS)){ curLayer = coordinateGetAxisTarget(Z_AXIS);

Actual coordinates are obtained by sending M114 to Marlin, which is not done during printing to avoid unnecessary serial traffic while printing.

PR #1319 fixes this.

Later edit:
All of the above is true while printing from the USB or SD attached to the TFT. Printing from onboard SD is different. Latest commit from the above mentioned PR should take care now of both situations.

@Chukozor
Copy link
Author

Chukozor commented Dec 3, 2020

but I didn't try the update #1319 , I just changed the line you told and compiled it. So maybe this update has no more this issue .... ? @kisslorand

@oldman4U
Copy link
Contributor

oldman4U commented Dec 3, 2020

Please try the current master firmware which includes all fixes.

Please help the community and close the ticket once you do not need it anymore. Thank you

@kisslorand
Copy link
Contributor

@Chukozor The "layer height doesn't update at each layer change and extruder icon issue" should have been resolved already. This new thing you have should be treated in a separate ticket. If you open a new ticket about it, please check before if the behaviour is present on any gcode you try to print and please provide a sample gcode also, a smaller one, if possible.

@oldman4U
Copy link
Contributor

oldman4U commented Dec 3, 2020 via email

@Chukozor Chukozor closed this as completed Dec 3, 2020
Copy link

github-actions bot commented Apr 3, 2024

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 3, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants