[BUG] Constant M114 E sending from TFT? breaking ESP01 SD Upload feature

[DaStivi]

Description

there is some constant M114 E command sending from TFT (?) filling up the tft terminal output and also breaks the ESP01 SD Upload as it interference the M28 command!

Steps to reproduce

1. Open TFT Terminal,
2. hit send without any command to see the send/rcv history
3. constantly seeing M114 E and outputs of this command

using the esp3dwebui terminal the output looks like this: after ah printer reset: echo:E0 Flow: 100% Count E:0 X:-3.0000 Y:-2.0000 Z:0.0000 E:0.0000 Count X:-240 Y:-160 Z:50 FR:100% echo:E0 Flow: 100% T:29.32 /0.0000 B:31.15 /0.0000 @:0 B@:0 Count E:0 X:-3.0000 Y:-2.0000 Z:0.0000 E:0.0000 Count X:-240 Y:-160 Z:50 FR:100% echo:E0 Flow: 100% Count E:0 T:29.32 /0.0000 B:31.04 /0.0000 @:0 B@:0

sending M28 test.gco to create an gco fileon SD: M28 test.gco

TFT starts beeping and display this error:

esp01 webui "freezes" or better said "remote" serial input freezes! sending M29 to stop sd write M29 echo:Now fresh file: test.gco Writing to file: test.gco //action:notification test.gcook Error:No Checksum with line number, Last Line: 0 Resend: 1 Error:No Checksum with line number, Last Line: 0 Resend: 1 Error:No Checksum with line number, Last Line: 0 Resend: 1 Error:No Checksum with line number, Last Line: 0 Resend: 1 T:29.32 /0.0000 B:31.04 /0.0000 @:0 B@:0 Error:No Checksum with line number, Last Line: 0 Resend: 1 Error:No Checksum with line number, Last Line: 0 Resend: 1 T:29.20 /0.0000 B:31.15 /0.0000 @:0 B@:0

after that there is only this constant output left: T:245.31 /245.0000 B:70.04 /70.0000 @:37 B@:3 Count E:0 T:244.69 /245.0000 B:70.00 /70.0000 @:59 B@:15 Count E:0 Count E:0 T:245.00 /245.0000 B:70.00 /70.0000 @:46 B@:18 Count E:0 T:244.69 /245.0000 B:69.96 /70.0000 @:68 B@:36 Count E:0 Count E:0 T:245.00 /245.0000 B:70.00 /70.0000 @:43 B@:2 Count E:0 T:244.69 /245.0000 B:69.96 /70.0000 @:97 B@:20 Count E:0 Count E:0

File on SD has 0byte,

viewing the terminal output there is the additional send: M114 E command in the history viewable

Expected behavior no constant sending of commands, what breaks M28 SD wrting

Hardware Variant

BTT TFT35 (b1 edition)

TFT Firmware Version & Main Board Firmware details

latestbugfix release from 1.2.2021

Additional Information

opened an issue with luc esp3d-webui and he also come to the Conclusio that i'd has to be an issue with btt tft fw... https://github.com/luc-github/ESP3D-WEBUI/issues/158

he also mentioned that there where some PR to this git to support the upload and "stop polling feature", checked the corresponding files manually but can't find his "stop polling feature" code anymore?!

[kisslorand]

M114 is sent every 2 seconds in the status screen. Test if you can upload a file if you are in another menu than the Status menu where no M114 is sent.

[DaStivi]

M114 is sent every 2 seconds in the status screen. Test if you can upload a file if you are in another menu than the Status menu where no M114 is sent.

ok this is a valid point, as in Main/status screen the x,y,z axis are displayed??? but if that would be the case... i shouldn't see the output in tft terminal ....

anyway i tested it... so not on the mainpage, i still see the output in esp3d terminal, and also uploading ah file, or creating ah new one with m28 doesn't work!

basically m114 is query'd even if not on status screen looks like... but basically brings also back the discussion if the PR from luc would fix it again (to stop polling feature) that went missing someday?!

edit: i've also disabled status screen, and persistent status info in features... still m114 is sent!

[DaStivi]

I've tested it in marlin mode now... and there is still the constant m114 query... also ESP3D in marlin mode (had to enable serial_always_on first) the m28 and file upload fails.... marlin mode does display that ah file has been created... and also i can't access the mainboard SD anymore!

[kisslorand]

I also have ESP3D connected to the TFT. I do not see M114 in any terminal, not on the TFT terminal, not on ESP3D terminal, not on Octoprint's termial (Octoprint connected to mainboard by USB).

[DaStivi]

I also have ESP3D connected to the TFT. I do not see M114 in any terminal, not on the TFT terminal, not on ESP3D terminal, not on Octoprint's termial (Octoprint connected to mainboard by USB).

what precise TFT? I've an TFT35 (v3) varriant in the BIQU b1... its ah special B1 "edition" but basically it should be identical with "normal" TFT35, just different PCB...

but I've the definitv confirmation the issue is also present on other B1's with that TFT!

[kisslorand]

I have MKS TFT28, I don't think that matters.

[DaStivi]

https://github.com/luc-github/ESP3D-WEBUI/issues/158#issuecomment-771965307

[kisslorand]

So it's not the M114... Would you like me to introduce the fix into PR #1598?

[DaStivi]

So it's not the M114... Would you like me to introduce the fix into PR #1598?

basically yes, its the m114 E command sent... but only because there was another fix, that has been broken, that "stopped" the M28 command from beeing interrupted from other commands... but still the question is why there is this m144 E command sent every 2 seconds on this variant of btt tft35

[luc-github]

Yes it is a typo introduced by https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/pull/733 That let all polling commands M114 / M105 / etc... ongoing but block Serial2 commands when polling is off, instead of the opposite. an unwished ! got in wrong place

@kisslorand If you do not mind to add it to your PR fix, it would be great, as your PR seems collecting several PR fixes - thank you 😸

[kisslorand]

@luc-github Done! Thank you for your fix.

[DaStivi]

Hey there sorry to not have posted/closed this one, was busy with ah lot Of other tasks and also some prints between all my issues I've 🙄

Can we still figure out what causing this m114 query? I did setup'd ah pi to test with (another story, everybody mentioned how great it is... Still don't get this and be more happy with the fully integrated tft and its features like simple babystepping and save as z offset... Not found an easy way with octoprint/octodash 🤦‍♂️) . And I still see the output there... Not sure if it's really ah issue but it's some kind of query all the time... I noticed this also because while certain processed it does not get an answer instead s Triggers the "busy processing" messages?!

[baikal]

@DaStivi When a Smart Filament Detector is configured to be on the TFT, the TFT sends M114 E repeatedly to figure out by how much the extruder moved to now when to expect the filament detector to toggle.

see eg. #1612, #1505

[digant73]

@baikal with M114 R instead of M114 E do you think the bug with the filament runout not working on TFT could be fixed? I can add the fix in one of my PR. I will ask you having the problem to test my PR. Please let me know

[DaStivi]

@baikal with M114 R instead of M114 E do you think the bug with the filament runout not working on TFT could be fixed? I can add the fix in one of my PR. I will ask you having the problem to test my PR. Please let me know

what do you mean? it's working.. under normal conditions.. the only condition its not working as far as i can see, is when SFS is on TFT and Linear Advanced is enabled (even with K0) as this does not respond correctly tu the M144 E command as it looks like..

edit: i double read the other issue and i guess we're all talking from the same :) and yes, i could also test it too...

and thx @baikal for the hint that explains why i saw it sometimes... just need to double check this now, because right now i can't use the SFS, because LA, but i am pretty sure i've disabled fil sensor in TFt now but still see the message but i gonna check this now..

[digant73]

on #1612 baikal reported that with M114 R the proper values were returned. However I didn't see option R as an available option for M114. With M114, the same outupt as M114 was returned (by the current marlin bugfix)

[baikal]

@digant73 Yes, I would think that using M114 R would get SFS on TFT working even with LA. I do not know which versions of Marlin started to have 'M114 R'. M114 R reports back a lot of things from which the E-values would need to be extracted (and converted between mm and counts maybe), so just a bit of work compared to reading the tiny output from M114 E.

[digant73]

@digant73 Yes, I would think that using M114 R would get SFS on TFT working even with LA. I do not know which versions of Marlin started to have 'M114 R'. M114 R reports back a lot of things from which the E-values would need to be extracted (and converted between mm and counts maybe), so just a bit of work compared to reading the tiny output from M114 E.

I'm using last Marlin bugfix (from yesterday). With M114 R I obtain the same info as M114. I will see if some setting have to be enabled in Marlin to support the "R" option.

EDIT: maybe the setting M114_REALTIME must be enabled in Marlin to support "R" option

[baikal]

If the comments in Marlins M114.cpp L183++ are correct, 'R' is meant to get the 'realtime' positions instead of the 'planned' ones. And the 'E' on L202 takes a shortcut to just read out stepper.position(E_AXIS) - which does not get updated when LA is enabled.

Crudly hacking in count_position.e += LA_steps; just before L2300 of stepper.cpp makes 'M114 E' report even when LA is on. But it does not add up exactly over a full print - maybe because of 'pure extruder' movements like retracts counted double .... SFS seems to work, had some false alarms and just gave up then, though it might have been a problem with my selfmade detector ...

[digant73]

To anyone having the problem with the filament sensor not working when connected to TFT, try to enable M114_REALTIME in Marlin. Please let me know the result

[baikal]

@digant73 Do you mean enable M114_REALTIME in Marlin together with some recent branch of yours of the BTT-TFT code? I do not see how M114_REALTIME could change the output of 'M114 E' from Marlin, so that makes only sense if the BTT-TFT does use 'M114 R', right? Which it does not so far in this repo ...

[digant73]

@baikal yes, enable M114_REALTIME in Marlin (use the last Marlin bugfix version) and the last BTT fw. M114 R produces the same output as M114 Also the output format for M114 E is unchanged. So no need to change the logic in the TFT fw. I don't know when R option was available for M114. It is not present in Marlin (at least in the latest bugfix releases I'm using).

[baikal]

@digant73 There is one single occurrence of M114_REALTIME in all of the Marlin code on Line 208 in M114.cpp, and that will not affect in any way what 'M114 E' reports (5 lines above in code). Which is 0 (zero) if LA is enabled.

Unless there is a variant of TFT fw that does use something else than 'M114 E' or Marlin itself gets "fixed" regarding M114 E and LA active, I do not see how enabling M114_REALTIME would help at this. It will enable the 'M114 R' variant, but if that is not used by the TFT fw, what's the point?

Anyway, I will not touch my Marlin on my printer at the moment just to "prove" that, maybe later - sorry.

I just noticed that this is on the wrong issue, this one is about 'constant M114 E sending' ... sorry for that

[DaStivi]

i close this, because the question why M114 is sent/received has been explained allready by @baikal at https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/issues/1601#issuecomment-798941200

regarding LinearAdvance and M114 we discuss this in #1612 further..

[digant73]

@baikal. DaStivi no problem, I understand your point of view

[github-actions[bot]]

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.