[BUG] Flow randomly changed from 100% to 10% during a print

[digant73]

Since different PRs now, a lot of people are complaining of random change of the flow from 100% to 10% during a print. Below a description of the typical error observed:

I get all these echo: F0, echo: (blank), etc. POPUP notifications within like 30 minutes (10%) of printing, then the Flow changes from 100% to 10%, which ruins every print. The same thing happens with the latest FW from master.

As you can understand it is a major bug that should be verified and fixed. I will also try to have a look. However, I ask people that worked on printing feature to have to review the code. The problem seems present since the end of September, beginning of October

Steps to reproduce

1. start a print
2. after some random time the flow is changed from 100% to 10%

Expected behavior The flow is not changed

Actual behavior The flow is randomly changed from 100% to 10%

[oldman4U]

It is the first time I hear about this issue and haven't seen this behavior so far. Which reports do you mean?

[baselsw]

I am having this issue at the moment as well. It is definitely random but is mostly apparent when I cold start the printer (turn on the printer from the power switch). After running a print, which eventually fails (because of the changing flow from 100% to 10%), all I do is press the reset button on the TFT and re-print the same g-code file (which this time succeeds). I don't get any notifications when this happens or rather I have not seen any when I have noticed the problem. In summary: pressing the reset button after power-cycling the printer has made it possible to print without problems.

[digant73]

@oldman4U it was verified by me and confirmed by other people using the current BTT FW. It seems the problem is present since majors changes were made on FanController.c and all over the project due to the introduction on config.ini of the parameter:

Fan Controller Count

Options: 0 to 2

fan_ctrl_count:0 ... ...

Fan Maximum PWM speed (0 to 255)

format [fan_max: F0: F1: F2: F3: F4: F5: CtL: CtI:]

fan_max:F0:255 F1:255 F2:255 F3:255 F4:255 F5:255 CtL:255 CtI:255

On my printer fan_ctrl_count is set to 0.

@baselsw. So is the reset always a permanent solution for you? I mean, you start the printer, reset the printer and then the problem is not present for sure?

[baselsw]

@digant73 It has worked for me three or four times so far. Now, if this actually solves the problem I can not say with 100% certainty because the actual problem appears randomly. However, as an addition to this. Once I have had a successful print, the problem will not appear again until I power-cycle the printer. So to me, it only happens ONCE for every power-cycle. As long as the printer is kept on after a successful print, I can run as many prints as I like without seeing the problem.

[oldman4U]

It is great that you have a feeling where the problem could come from, and I add this to the known bug list.

The question is, why it happens on some machines, but not on others. Wouldn't it be good to share the configurations used?

I assume you are printing from Touchscreen Mode, but does it happen also using Marlin mode? How many times it happens out of 10 prints approximately?

SKR E3 DIP 2208UART Marlin 2.0.7.2 Serial Port 2 No second serial port defined 115200 TFT35 E3 v3 Firmware 20.10.2020 Cura 4.6.1

[digant73]

@oldman4U Attached my config.ini on TFT FW and the config file on Marlin 2.0.6.1. config.zip Marlin.zip

Yes, touch screen is used for the print (no Marlin mode is available on the printer). Marlin 2.0.6.1 is used. Basically, in a long print it is sure you will have the problem. There was no problem at all before the mentioned PR introducing the Fan Controller Count

In the recent time I spent more time developing than printing. However many people using the FW on the same printer as mine reported me the same bug

[oldman4U]

Maybe you can try 2.0.7.2.

My son had 2 successful prints last weekend almost 12h and 8h long.

[Guilouz]

I compiled the firmware for a friend's TFT70 and it reports the same issue.

[digant73]

@guilouz same bug on flow from 100 to 10?

[Guilouz]

@Guilouz same bug on flow from 100 to 10?

Yes he found his printer with a flow at 10% (1st printing with his new screen) and obviously failed print...

Me, I have not noticed it because I go through octoprint.

[Mactastic1-5]

I compiled Marlin 2.0.7.2 based on @digant73 Marlin 2.0.6.1 firmware and it's the same result. The problem isn't with the Marlin firmware, but with the TFT firmware. #1209 has a CtL fan control bug - maybe the bug comes from the same origin?

[baselsw]

I have seen the same problem using Marlin 2.0.7.2 compiled by @digant73, stock Sidewinder X1 firmware and the waggster mod firmware. The problem is in the TFT and not the main board.

[sebsx]

I have the same bug and I cannot see a pattern unfortunately, sometimes works for 2-3 prints then fails. Also, sometimes I get the "echo" on the display and a short beep and the flow stays at 100% instead of dropping to 10% like it usually does.

My Marlin is built and updated about once a week from the bugfix-2.0.x branch if that's of any help.

Another thing I've noticed is that after the bug occurs, the steppers (TMC2100 drivers) start to make this grinding sound and I need to powercycle the printer.

[oldman4U]

Hmmm. I never use a Fan during printing and I print very slow. 20-40mm/sec. Maybe this somehow makes a difference.

sebs notifications@github.com schrieb am Mi. 4. Nov. 2020 um 02:05:

I have the same bug and I cannot see a pattern unfortunately, sometimes works for 2-3 prints then fails. Also, sometimes I get the "echo" on the display and a short beep and the flow stays at 100% instead of dropping to 10% like it usually does.

My Marlin is built and updated about once a week from the bugfix-2.0.x branch if that's of any help.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/issues/1228#issuecomment-721455248, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM6XKZHLXTDQD4XBMY23H6TSOCSE3ANCNFSM4TIPLFQQ .

[digant73]

another PR that was merged in the firmware since when the bug is present is TMC Hybrid Threshold Speed.

[oldman4U]

Ok. Using Stealth Mode and no TMC HTS.

digant73 notifications@github.com schrieb am Mi. 4. Nov. 2020 um 10:01:

another PR that was merged in the firmware since when the bug is present is TMC Hybrid Threshold Speed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/issues/1228#issuecomment-721603371, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM6XKZEIDDEMZ7LGAL6IWQ3SOEJ63ANCNFSM4TIPLFQQ .

[sebsx]

Not using hybrid mode either with my TMC2100. Plan to though once I upgrade to TMC2209.

[digant73]

A test that can be done is during a print move to a different menu than the Printing menu (the menu reporting all the stats such as fan, speed, layer, pause, babystep buttons etc...). Just to verify if the bug is due to some query executed by that menu.

[sebsx]

In my case the bug happens without using any other menu, i.e. I power on the printer, select the file then print. Later on the bug happens and the print is ruined (early in the process if I'm lucky).

Next what I usually do is power cycle and try again. If the bug shows its ugly head again I generally try to re-slice the file and attempt the print again. Sometimes it works, sometimes it doesn't.

It's a really weird bug.

[digant73]

@sebsx if you can, next time try to move and stay to the "More" menu when you start a print and verify if the bug happens again. It's just to see if the bug is related to some queries made by the "Printing" menu (this menu queries Marlin to update all the stats displayed in the menu)

[sebsx]

Will do and report back.

[J2J2]

Hi, maybe my bug is linked or not :/. On my printer (similar config has digant73 but enclosed if necessary) bug is on speed (not on flow). Do some test on short print (<1h) does not bug during print but often at begining. When it bug, most of time it get stuck on 10% speed. Just catch a video of goes to 10% en then automatically goes back to 100% https://youtu.be/dx6haolZQ4I O_o first time I seen it. It seems to occurs just after "M420 S1" command from my start G-code command configured in config.ini. See at 0:18 just after the echo fade off in the video.

tft_config.zip Marlin.zip

[digant73]

@J2J2 Although it should not be a problem, remove the space before M420 in start_gcode:G28 XY R20\n M420 S1\n

so you have will have start_gcode:G28 XY R20\nM420 S1\n

[J2J2]

Thanks for the advice.

Bug on flow occurs for the first time for me too :D ... (sad and happy in same time, I have also the flow bug) In the middle of a 2h print.

I'm going back to previous firmware (mesh bed level editing will miss me :( ).

[Mactastic1-5]

@sebsx if you can, next time try to move and stay to the "More" menu when you start a print and verify if the bug happens again. It's just to see if the bug is related to some queries made by the "Printing" menu (this menu queries Marlin to update all the stats displayed in the menu)

@digant73 I can confirm that no POPUP notifications appear that suggest an error and the Flow doesn’t change from 100% to 10% on it’s own while the More menu is present on screen for the duration of the print. I’ve printed using the same model that I’ve printed previously, which failed every time at around 10%, which is equivalent to 30 minutes.

[oldman4U]

Could you please attach the gCode file here. Can try a dry print tomorrow to see if I can join the group 😔

Stellarspace notifications@github.com schrieb am Mi. 4. Nov. 2020 um 22:25:

@sebsx https://github.com/sebsx if you can, next time try to move and stay to the "More" menu when you start a print and verify if the bug happens again. It's just to see if the bug is related to some queries made by the "Printing" menu (this menu queries Marlin to update all the stats displayed in the menu)

I can confirm that no POPUP notifications appear that suggest an error and the Flow doesn’t change from 100% to 10% on it’s own while the More menu is present on screen for the duration of the print. I’ve printed using the same model that I’ve printed previously, which failed every time at around 10%, which is equivalent to 30 minutes.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/issues/1228#issuecomment-721983293, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM6XKZHLJCIFZ6VYJ76Z6YLSOHBDNANCNFSM4TIPLFQQ .

[sebsx]

Hey @oldman4U one of the issues is sometimes the same gcode file works on the second try.

I suspect there's a buffer misbehaving somewhere in the gcode feed and response parsing that sometimes corrupts gcode and sends the wrong flow rate.

I'm not familiar with this codebase at all but I intend to make some time this weekend to poke around.

[oldman4U]

The problem is that we print a lot and have never seen this issue. So I would take every chance to help and see if I can get this problem also on my machine.

sebs notifications@github.com schrieb am Mi. 4. Nov. 2020 um 22:33:

Hey @oldman4U https://github.com/oldman4U one of the issues is sometimes the same gcode file works on the second try.

I suspect there's a buffer misbehaving somewhere in the gcode feed and response parsing that sometimes corrupts gcode and sends the wrong flow rate.

I'm not familiar with this codebase at all but I intend to make some time this weekend to poke around.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/issues/1228#issuecomment-721986745, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM6XKZFQNQSL6YDPHDAESQDSOHCBVANCNFSM4TIPLFQQ .

[sebsx]

Got it @oldman4U. I'll attach a gcode file that failed 3 times in a row for me yesterday. I still have the failed parts in my recycling bin if you want a picture as well, let me know.

[Mactastic1-5]

Could you please attach the gCode file here. Can try a dry print tomorrow to see if I can join the group 😔 Stellarspace notifications@github.com schrieb am Mi. 4. Nov. 2020 um 22:25: …

I’ve continued printing it even though I successfully printed the same 3D model on a different TFT firmware, so you’ll have to wait for the GCODE file.

Hey @oldman4U one of the issues is sometimes the same gcode file works on the second try.

I suspect there's a buffer misbehaving somewhere in the gcode feed and response parsing that sometimes corrupts gcode and sends the wrong flow rate.

I'm not familiar with this codebase at all but I intend to make some time this weekend to poke around.

This isn’t the case for me, I’ve tried printing the same GCODE file several times and each time, I’ve gotten 3 POPUP notifications within 30 minutes, then the Flow rate changes from 100% to 10%. While leaving the TFT on the More menu, I don’t get ANY POPUP notifications and the Flow rate DOES NOT change at all. I don’t think enough users have BTT hardware or BTT hardware that is up-to-date for users to report it. @Guilouz Which 3D Printer? Custom Build with BTT TFT70 or Sidewinder X1 or similar?

[sebsx]

Ok so this is the file I just couldn't print yesterday. I'm going to kick off another print and stay on the More menu just to see if it gets any better.

s-handle.gcode.zip

[sebsx]

The file above printed successfully with me leaving the screen in the More menu. Of course a sample of 1 is not large enough to make any assumptions so I'll repeat the same process for all of the prints I'll do in the next days, just to see what happens.

It would be good to narrow it down somewhat.

[baselsw]

I have just finished my second print. I can confirm that printing with the More menu open solves the problem.

[Mactastic1-5]

I have just finished my second print. I can confirm that printing with the More menu open solves the problem.

It's more of a workaround for the moment.

[baselsw]

I have just finished my second print. I can confirm that printing with the More menu open solves the problem.

It's more of a workaround for the moment.

Ohh, no! I thought going into the more menu actually re-flashed the firmware and fixed the issue. I was also expecting my 3D printer to make me breakfast after this fix. Are you serious? Of course it is s workaround. I was just confirming that this workaround works 🤦.

[oldman4U]

@digant73 @J2J2

You both defined Baudrate 6 (250k) and I am not sure if I am the only one, but there have been soo many issues reported using higher baud rates than 115200 that I never changed it. Maybe because of this I also never saw those random stops or other issues reported by this users and maybe because of this it is also the default baud rate.

Before changing anything else, I would recommend to change the baud rate to 115200 (5) to see, if this already solves the problem. Faster does not automatically mean better, but finding the RIGHT setting is key to success.

[oldman4U]

@sebsx could you please also check your baud rate and change it back to 115200

[Mactastic1-5]

@digant73 @J2J2

You both defined Baudrate 6 (250k) and I am not sure if I am the only one, but there have been soo many issues reported using higher baud rates than 115200 that I never changed it. Maybe because of this I also never saw those random stops or other issues reported by this users and maybe because of this it is also the default baud rate.

Before changing anything else, I would recommend to change the baud rate to 115200 (5) to see, if this already solves the problem. Faster does not automatically mean better, but finding the RIGHT setting is key to success.

“No printer attached” is displayed when you change the baud rate to 115200.

[oldman4U]

Most likely because you have to change this also in Marlin FW of the mainboard....

Sorry, forgot to mention this but expected this to be a know thing;-(

[Mactastic1-5]

Most likely because you have to change this also in Marlin FW of the mainboard....

Sorry, forgot to mention this but expected this to be a know thing;-(

Sidewinder X1’s default baud rate is 250000.

[oldman4U]

So they will also take over the support now and try to help!???

[digant73]

250K is the default (suggested) speed for many printers now. However, I will attach here the Marlin FW with baudrate set to 115K. It could be possible that the TFT is now over loaded but it's strange that always the same problem is present.

[digant73]

Ok, attached four different versions of the Marlin FW for the sidewinder printer. Baudrate is set to 115200. From the TFT FW you must set (from the Connection menu) baudrate to 115200 so the TFT will be able to connect to Marlin

SW_BLTouch_waggster_firmware.zip SW_MBL_firmware.zip SW_standard_firmware.zip SW_BLTouch_standard_firmware.zip

[J2J2]

I'm testing :). But 115200 could be too slow to send gcode to main board? (for fast or lot a detail print maybe?). It seems to be possible to also overclock TFT controller like in this project: https://www.thingiverse.com/thing:4251390 . Or maybe it is a misunderstanding.

[oldman4U]

It is fast enough. MAYBE you have to adjust buffer levels when you print really fast @ 150-200mm/sec and very small parts, but that's not something you usually do.

Finally this is also just to find out if it makes a difference. Maybe it does not change things at all.

[radek8]

I do not use precompiled FW. I compile the current version myself. I have not noticed this problem yet. gigant73 stated that it has "fan_ctrl_count: 0" in its configuration I control the fan on the drivers so I have set "fan_ctrl_count: 1" Could it be related? For comparison, I enclose my configuration.

config.ini.zip

[sebsx]

Nevermind, figured it out I had the wrong target selected.

@digant73 @radek8 can you describe in a few words how you compile yours?

[Mactastic1-5]

Could you please attach the gCode file here. Can try a dry print tomorrow to see if I can join the group 😔 Stellarspace notifications@github.com schrieb am Mi. 4. Nov. 2020 um 22:25: … @sebsx https://github.com/sebsx if you can, next time try to move and stay to the "More" menu when you start a print and verify if the bug happens again. It's just to see if the bug is related to some queries made by the "Printing" menu (this menu queries Marlin to update all the stats displayed in the menu) I can confirm that no POPUP notifications appear that suggest an error and the Flow doesn’t change from 100% to 10% on it’s own while the More menu is present on screen for the duration of the print. I’ve printed using the same model that I’ve printed previously, which failed every time at around 10%, which is equivalent to 30 minutes. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1228 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM6XKZHLJCIFZ6VYJ76Z6YLSOHBDNANCNFSM4TIPLFQQ .

I've attached the GCODE below: ASX1_VaseV265[Bigtree].gcode.zip

Ok, attached four different versions of the Marlin FW for the sidewinder printer. Baudrate is set to 115200. From the TFT FW you must set (from the Connection menu) baudrate to 115200 so the TFT will be able to connect to Marlin

SW_BLTouch_waggster_firmware.zip SW_MBL_firmware.zip SW_standard_firmware.zip SW_BLTouch_standard_firmware.zip

~I'll upload the firmware to the 3D Printer and print the Vase while staying on the Main Menu, but I doubt the problem has anything to do with baud rates.~

I've uploaded the firmware to the 3D Printer, changed the baud rate via the Connection > BraudRate Menu, but while preheating the extruder and the bed, a POPUP notification appears with the following information: Printer halted. kill() called

[sebsx]

I just rebuilt the TFT firmware and overclocked it to 56MHz (from what appears to be 48Mhz). At least this is what it reports in the info screen, not sure if it actually running at that speed. I'll run some tests later today and over the weekend.

I also tried 72MHz but it fails to connect to the printer so it probably needs more setup.

[oldman4U]

I would recommend not to do this. You could easily run into temperature problems because of this.

sebs notifications@github.com schrieb am Fr. 6. Nov. 2020 um 03:39:

I just rebuilt the TFT firmware and overclocked it to 56MHz (from what appears to be 48Mhz). At least this is what it reports in the info screen, not sure if it actually running at that speed. I'll run some tests later today and over the weeked.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/issues/1228#issuecomment-722773838, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM6XKZBQFYH2NFNFMYTYMIDSONOWXANCNFSM4TIPLFQQ .