Layer not correct while printing from onboard sd

[sadbass]

Description

When printing from onboard SD of skr1.4 and tft35 V2
For All the print I see layer 0.00

Steps to reproduce

Turn on
Select print
Select onboard SD
Select any gcode
Start print
Expected behavior
While is printing is Shown the current z position,
Actual behavior
For the duration of the print I see 0.00

Hardware Variant

Skr1.4
Tft35 V2

Additional Information

[oldman4U]

Sorry. But you are maybe the 100s user to report this. Please see PR #1272 which solves the issue. Unfortunately @bigtreetech or @Msq001 are not able to make it available for all users for an unknown reason.

[radek8]

The fix already exists but Bigtreetech is unable to merge the changes into the master.
Maybe it would be good to merge all PR and compile bin files for users who can't do it themselves.

[blueeagle69]

It looks like @bigtreetech heard you guys.
It's now been merged.
I was running the repo that had the fix in place. But good to see it in Master now.

[oldman4U]

Yes, but this is like trying to get a lame donkey making one step, and there are still two PRs waiting to get merged.

radek8, maybe you can make new firmware with the merges from today and then we can sit down and pray that but will merge them;-( This is really a nightmare.

[bigtreetech]

@oldman4U I'm compiling the test, and when I'm done, I'll update #1265 and merge it

[oldman4U]

Thank you bigtreetech!!!!

[oldman4U]

Hello sadbass.

Could you please download master firmware, compile it (do NOT use the precompiled firmware!) and check if the reported issue is solved.

Please do not forget to close this ticket in case you do not need it anymore.

Thank you

[sadbass]

Ok I try today

[oldman4U]

It has been working but a following PR destroyed it again. I will let you know

[kisslorand]

PR #1319 is updated and now everyone should be happy. Layer updates now regardless what are you printing from.

[oldman4U]

Current master firmware should work. Please check and let us know.

Thank you

[oldman4U]

Please try this firmware and let us know if you get the layer hight and also the print finished dialog.

https://github.com/mehmetsutas/BIGTREETECH-TouchScreenFirmware

Thank you

[blueeagle69]

Please try this firmware and let us know if you get the layer hight and also the print finished dialog.

https://github.com/mehmetsutas/BIGTREETECH-TouchScreenFirmware

Thank you

Hi!
@mehmetsutas

I just tried this firmware.
Layer works fine, end of print pop up works, but after that I get a constant Loading screen.
*Onboard SD

[oldman4U]

Repeat and send the exact steps to reproduce. blueeagle69 <[email protected]> schrieb am Sa. 5. Dez. 2020 um 14:28:

…

Please try this firmware and let us know if you get the layer hight and also the print finished dialog. https://github.com/mehmetsutas/BIGTREETECH-TouchScreenFirmware Thank you Hi!. I just tried this firmware. Layer works fine, end of print pop up works, but after that I get a constant Loading screen. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1288 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AM6XKZHO6LNQ4Y4IRQCNHA3STIYRVANCNFSM4UEFJSSA> .

[blueeagle69]

Right, I have to correct myself on two points.
The constant loading screen was a one-off after I cancelled a print.
Repeating three or four times it hasn't happened since.
Also the second correction.
The layer height, works up to layer 2 and stops.
Layer 1 was .3, layer two etc was .2 hence the 0.5mm

However when printing in vase mode it updates correctly!
Printed four times to confirm.

Also at the end of the print I think there is a few too-many popups.
This is end of a print 😑

Close that, get this;

Press Stop, get this;

And then finally!

[oldman4U]

You get a Loading... which disappears after a minute or two when you CANCEL a print from on board sd card. Everything else you should get a single Info window with the elapsed time and probably the filament used. Which firmware are you using. Send the download link. I believe you are still using an older version because the two extra windows I saw only using an older version. blueeagle69 <[email protected]> schrieb am Sa. 5. Dez. 2020 um 16:09:

…

Right, I have to correct myself on two points. The constant loading screen was a one-off after I cancelled a print. Repeating three or four times it hasn't happened since. Also the second correction. The layer height, works up to layer 2 and stops. Layer 1 was .3, layer two etc was .2 hence the 0.5mm [image: 20201205_141534] <https://user-images.githubusercontent.com/9963876/101246440-4105d000-370b-11eb-905c-1b12115f83fa.jpg> However when printing in vase mode it updates correctly! Printed four times to confirm. Also at the end of the print I think there is a few too-many popups. This is is end of a print. [image: 20201205_145200] <https://user-images.githubusercontent.com/9963876/101246488-95a94b00-370b-11eb-8c2e-38c2efad2473.jpg> Close that, get this; [image: 20201205_145220] <https://user-images.githubusercontent.com/9963876/101246494-a78aee00-370b-11eb-94f8-c69e6f3a4ad1.jpg> Press Stop, get this; [image: 20201205_145242] <https://user-images.githubusercontent.com/9963876/101246500-b376b000-370b-11eb-9b11-29cb2e82bec7.jpg> And then finally! [image: 20201205_145252] <https://user-images.githubusercontent.com/9963876/101246509-bffb0880-370b-11eb-8da4-6d8193a80c3a.jpg> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1288 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AM6XKZELUB4RFKUWAZO4AILSTJELZANCNFSM4UEFJSSA> .

[blueeagle69]

I downloaded and compiled this.
https://github.com/mehmetsutas/BIGTREETECH-TouchScreenFirmware

[oldman4U]

Ok. Then please send me the gCode and which storage you print from. blueeagle69 <[email protected]> schrieb am Sa. 5. Dez. 2020 um 16:18:

…

I downloaded and compiled this. https://github.com/mehmetsutas/BIGTREETECH-TouchScreenFirmware — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1288 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AM6XKZBTN6STCTC3FCOYTYTSTJFNBANCNFSM4UEFJSSA> .

[blueeagle69]

Onboard 😀
Shape-Box_0.2mm_PLA_9m.zip
I wish it would show filament used. Alas no!
Which is why I'm still a Marlin mode person 99% of the time 😉

[blueeagle69]

Very strange how the layer info stops at layer 2, but not when printing in vase mode.
Then it works fine.

[blueeagle69]

It turned out I hadn't updated my config file.
So I did that. but it didn't make any difference.
I still get copious amounts of popups at the end of the print.
Also, layer info still stops at layer two, except in vase mode.
Although I didn't expect a config file file to sort that out.
Getting rid of having to hit the Stop button would also be great!

[mehmetsutas]

Did you compile the source or just used one of the precompiled binaries?

[mehmetsutas]

@blueeagle69 For board sd, TFT queries the Z position from MARLIN during the print. If there is a problem with the serial communication, you may encounter a problem as you described. Check your MARLIN serial setup on MARLIN configuration_adv.h mine is as below and I don't encounter a problem like yours. I am using BTT SKR V1.3 with MARLIN 2.0.7.2

`// @section serial

// The ASCII buffer for serial input
#define MAX_CMD_SIZE 96
#define BUFSIZE 16

// Transmission to Host Buffer Size
// To save 386 bytes of PROGMEM (and TX_BUFFER_SIZE+3 bytes of RAM) set to 0.
// To buffer a simple "ok" you need 4 bytes.
// For ADVANCED_OK (M105) you need 32 bytes.
// For debug-echo: 128 bytes for the optimal speed.
// Other output doesn't need to be that speedy.
// :[0, 2, 4, 8, 16, 32, 64, 128, 256]
#define TX_BUFFER_SIZE 128

// Host Receive Buffer Size
// Without XON/XOFF flow control (see SERIAL_XON_XOFF below) 32 bytes should be enough.
// To use flow control, set this buffer size to at least 1024 bytes.
// :[0, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048]
#define RX_BUFFER_SIZE 256

#if RX_BUFFER_SIZE >= 1024
// Enable to have the controller send XON/XOFF control characters to
// the host to signal the RX buffer is becoming full.
//#define SERIAL_XON_XOFF
#endif

// Add M575 G-code to change the baud rate
//#define BAUD_RATE_GCODE

#if ENABLED(SDSUPPORT)
// Enable this option to collect and display the maximum
// RX queue usage after transferring a file to SD.
//#define SERIAL_STATS_MAX_RX_QUEUED

// Enable this option to collect and display the number
// of dropped bytes after a file transfer to SD.
//#define SERIAL_STATS_DROPPED_RX
#endif`

https://youtu.be/fJm17Gh29v0

[mehmetsutas]

Onboard 😀
Shape-Box_0.2mm_PLA_9m.zip
I wish it would show filament used. Alas no!
Which is why I'm still a Marlin mode person 99% of the time 😉

@blueeagle69 If the filament used is more than 1 meter and if the end gcode does not reset the extruder position at the end of the print, the summary popup screen shows the filament used in meters.

https://youtu.be/qQRmiG7PYDc

[oldman4U]

I am confused because I could verify the print finished behavior. The layer updates correctly. Will do some more test tomorrow. blueeagle69 <[email protected]> schrieb am Sa. 5. Dez. 2020 um 17:09:

…

It turned out I hadn't updated my config file. So I did that. but it didn't make any difference. I still get copious amounts of popups at th end of the print. Also, layer info still stops at layer two, except in vase mode. Although I didn't expect a config file file to sort that out. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1288 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AM6XKZEC32ZZNX27ANCPI5LSTJLJ3ANCNFSM4UEFJSSA> .

[blueeagle69]

No probs. Weird. I do not get that that third line.

[blueeagle69]

@blueeagle69 For board sd, TFT queries the Z position from MARLIN during the print. If there is a problem with the serial communication, you may encounter a problem as you described. Check your MARLIN serial setup on MARLIN configuration_adv.h mine is as below and I don't encounter a problem like yours. I am using BTT SKR V1.3 with MARLIN 2.0.7.2

`// @section serial

// The ASCII buffer for serial input
#define MAX_CMD_SIZE 96
#define BUFSIZE 16

// Transmission to Host Buffer Size
// To save 386 bytes of PROGMEM (and TX_BUFFER_SIZE+3 bytes of RAM) set to 0.
// To buffer a simple "ok" you need 4 bytes.
// For ADVANCED_OK (M105) you need 32 bytes.
// For debug-echo: 128 bytes for the optimal speed.
// Other output doesn't need to be that speedy.
// :[0, 2, 4, 8, 16, 32, 64, 128, 256]
#define TX_BUFFER_SIZE 128

// Host Receive Buffer Size
// Without XON/XOFF flow control (see SERIAL_XON_XOFF below) 32 bytes should be enough.
// To use flow control, set this buffer size to at least 1024 bytes.
// :[0, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048]
#define RX_BUFFER_SIZE 256

#if RX_BUFFER_SIZE >= 1024
// Enable to have the controller send XON/XOFF control characters to
// the host to signal the RX buffer is becoming full.
//#define SERIAL_XON_XOFF
#endif

// Add M575 G-code to change the baud rate
//#define BAUD_RATE_GCODE

#if ENABLED(SDSUPPORT)
// Enable this option to collect and display the maximum
// RX queue usage after transferring a file to SD.
//#define SERIAL_STATS_MAX_RX_QUEUED

// Enable this option to collect and display the number
// of dropped bytes after a file transfer to SD.
//#define SERIAL_STATS_DROPPED_RX
#endif`

https://youtu.be/fJm17Gh29v0

If anything I would expect the layer issue with vase prints, not the other way around. Either way I will check my settings tomorrow, Kinda sick of the site of firmware today!

[blueeagle69]

Did you compile the source or just used one of the precompiled binaries?

Sorry missed this one.
I always compile :)

[oldman4U]

I am on it. Which slicer are you using? blueeagle69 <[email protected]> schrieb am So. 6. Dez. 2020 um 13:18:

…

Did you compile the source or just used one of the precompiled binaries? Sorry missed this one. I always compile :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1288 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AM6XKZBH2KQLTVEMXVBKXEDSTNZARANCNFSM4UEFJSSA> .

[blueeagle69]

I am on it.

Which slicer are you using?

blueeagle69 [email protected] schrieb am So. 6. Dez. 2020 um 13:18:

Did you compile the source or just used one of the precompiled binaries?

Sorry missed this one.
I always compile :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1288 (comment),
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM6XKZBH2KQLTVEMXVBKXEDSTNZARANCNFSM4UEFJSSA
.

Prusaslicer :)

[blueeagle69]

@blueeagle69 For board sd, TFT queries the Z position from MARLIN during the print. If there is a problem with the serial communication, you may encounter a problem as you described. Check your MARLIN serial setup on MARLIN configuration_adv.h mine is as below and I don't encounter a problem like yours. I am using BTT SKR V1.3 with MARLIN 2.0.7.2

`// @section serial

// The ASCII buffer for serial input
#define MAX_CMD_SIZE 96
#define BUFSIZE 16

// Transmission to Host Buffer Size
// To save 386 bytes of PROGMEM (and TX_BUFFER_SIZE+3 bytes of RAM) set to 0.
// To buffer a simple "ok" you need 4 bytes.
// For ADVANCED_OK (M105) you need 32 bytes.
// For debug-echo: 128 bytes for the optimal speed.
// Other output doesn't need to be that speedy.
// :[0, 2, 4, 8, 16, 32, 64, 128, 256]
#define TX_BUFFER_SIZE 128

// Host Receive Buffer Size
// Without XON/XOFF flow control (see SERIAL_XON_XOFF below) 32 bytes should be enough.
// To use flow control, set this buffer size to at least 1024 bytes.
// :[0, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048]
#define RX_BUFFER_SIZE 256

#if RX_BUFFER_SIZE >= 1024
// Enable to have the controller send XON/XOFF control characters to
// the host to signal the RX buffer is becoming full.
//#define SERIAL_XON_XOFF
#endif

// Add M575 G-code to change the baud rate
//#define BAUD_RATE_GCODE

#if ENABLED(SDSUPPORT)
// Enable this option to collect and display the maximum
// RX queue usage after transferring a file to SD.
//#define SERIAL_STATS_MAX_RX_QUEUED

// Enable this option to collect and display the number
// of dropped bytes after a file transfer to SD.
//#define SERIAL_STATS_DROPPED_RX
#endif`

https://youtu.be/fJm17Gh29v0

Hi.

I made the relevant changes to the buffer sizes in Marlin and that has appeared to have fixed the layer info issue.
But did a second test print this time the layer info was stuck on 20.00mm!
only had one box pop saying Print Complete and that was it this time.
I rebooted the printer and repeated the print, this time the layer info worked as expected.
Oddly though this weird layer issue readout appears to be random as I have tried to replicate by repeating prints without rebooting and this time it has worked as expected 🙄

@oldman4U I cancelled a print mid-way and was greeted with the "Loading" again. I left it like you said for a minute or two, although that is way-too long, but it never recovered and had to reboot. But also this appears to be random. On the next cancelled print it worked fine.
Again though as I said above, since changing the buffer sizes in Marlin I now only get one popup box! at at the end showing "Print Complete" and nothing else. No print time or filament used etc. But thankfully I didn't have to hit the Stop button at the end of the print.
If I do cancel a print I get the Print time box then! Still no filament used etc.

Okay I think that's it!

[oldman4U]

When you self compile the firmware, what kind of changes do you add to configuration.h and config.ini?

Do you have Cancel and Stop gcode activated and if so, have you changed something related to those two functions?

Please let me know

[oldman4U]

I did SOME more tests today and can confirm the issue with the many clicks needed to finally finish an already finished print from on board SD. All other Cancel and print finished methods are working fine.

The layer info worked fine for me. Sometimes it has been falling behind, but this was beyond 300mm/sec, a value I never use for printing. So for me this all works very well, the many clicks needed is something which has to be fixed.

Btw, I tested self and precompiled and they work the same, no difference. Seems the auto build works properly finally;-)

[kisslorand]

Sometimes it has been falling behind, but this was beyond 300mm/sec, a value I never use for printing.

I guess this is because printing process is more privileged than data queries.

[blueeagle69]

When you self compile the firmware, what kind of changes do you add to configuration.h and config.ini?

Do you have Cancel and Stop gcode activated and if so, have you changed something related to those two functions?

Please let me know

Apologies I was having a blast in Elite Dangerous!
Start and End gcode are not activated.
In the source firmware I change Selectmode.c to replace 12864 Mode to Marlin Mode (it triggers me) and I have included my
config file 😀 I don't touch configuration.h
config.ini.zip

[mehmetsutas]

@blueeagle69 in your config would you please set serial_always_on to 1 and try once again.

During board_sd prints the Z position is queried from the printer and shown as the layer height on th LCD. When serial communication is interrupted, the Z position query replies may be missed.

[blueeagle69]

Will do.
Got to perform an operation on my Biqu B1. New fan and possibly nozzle, but will report as soon as possible before I re-attempt my big print.

[oldman4U]

@sadbass

The fix is now available since 7 days as part of the master firmware. Could you please take over responsibility for the ticket you opened and check if the problem is solved.

Please close the ticket afterwards, thank you

[blueeagle69]

Apologies for not reporting back. My printer took longer than expected.
It will be back working tomorrow. But I don't think I will have anymore layer info issues 😀

Thanks!

[oldman4U]

;-)

But you know, sadbass has to confirm and close this ticket...

[sadbass]

This evening I try, I can load the firmware already compiled or I must compile myself?

[oldman4U]

You should be able to use the precompiled, but I would recommend to compile your own - like always.

[sadbass]

Yes is working and thanks to named also the label of the onboard SD thanks a lot

[github-actions]

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.