[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%

[sebsx]

I'm not going to make it permanent if the initial problem persists. I just want to see if it helps or not and get it out of the way. Personally I do not believe it will help but I'm also not too worried about temperature since the jump from 48 to 56 isn't huge.

Anyway, this flow bug has been very consistent for me so I guess I'll find out in less than 5 prints if CPU speed has anything to do with it.

[sebsx]

Ok so the bug manifested itself on the first print I tried, not even 10 minutes in, so it's definitely not the CPU speed (if the overclock worked, I have no way of confirming). Back to the 48MHz default for now.

[oldman4U]

Which baud rate have you used?

sebs notifications@github.com schrieb am Fr. 6. Nov. 2020 um 09:32:

Ok so the bug manifested itself on the first print I tried, not even 10 minutes in, so it's definitely not the CPU speed (if the overclock worked, I have no way of confirming). Back to the 48MHz default for now.

— 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-722949509, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM6XKZCB6XIIJLPA5R2JSFDSOOYADANCNFSM4TIPLFQQ .

[digant73]

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

it could be usefull that you try to set fan_ctrl_count to 0 and verify if you will get the same problem.

[digant73]

Ok so the bug manifested itself on the first print I tried, not even 10 minutes in, so it's definitely not the CPU speed (if the overclock worked, I have no way of confirming). Back to the 48MHz default for now.

it could be usefull you verify the version with 115200 baudrate.

[J2J2]

For me 115200 seems to be better. I made only 3 prints 30min-1h duration yesterday, then maybe no enough to be significant.

[digant73]

good. let us know. I cannot test it (I'm at work now)

[sebsx]

@oldman4U @digant73 Also trying 115200 next. I'll try a few prints then report back.

[sebsx]

Just noticed the comments in config.ini about gcode length appear to be incorrect. It states "maximum 50 characters" but it's actually defined to be 75 + null.

TFT/src/User/API/Settings.h 51:#define MAX_GCODE_LENGTH 75 191: char start_gcode[MAX_GCODE_LENGTH + 1]; 192: char end_gcode[MAX_GCODE_LENGTH + 1]; 193: char cancel_gcode[MAX_GCODE_LENGTH + 1];

[oldman4U]

Here are the Marlin buffer settings of another user which solved several issues for him.

[J2J2]

I have:

  #define BLOCK_BUFFER_SIZE 16

  #define BUFSIZE 4
  #define TX_BUFFER_SIZE 4
  #define RX_BUFFER_SIZE 128

RX buffer is not defined then take value from Conditionals_adv.h . But digant73 config has define TX_BUFFER_SIZE 0 ! Maybe it could be have an impact?

For the first one we don"t have SDSUPPORT then 16 is it enough? (it is the marlin default value)

Also our firmware has a lot of debug feature enabled, what impact might this have?

[digant73]

@J2J2 I didn't change that value in Marlin. It's the default value provided by Marlin

[digant73]

Just noticed the comments in config.ini about gcode length appear to be incorrect. It states "maximum 50 characters" but it's actually defined to be 75 + null.

TFT/src/User/API/Settings.h 51:#define MAX_GCODE_LENGTH 75 191: char start_gcode[MAX_GCODE_LENGTH + 1]; 192: char end_gcode[MAX_GCODE_LENGTH + 1]; 193: char cancel_gcode[MAX_GCODE_LENGTH + 1];

yes, but this is not the problem. It requires simply a change in the comment in config.ini

[J2J2]

@J2J2 I didn't change that value in Marlin. It's the default value provided by Marlin

I agree :). My sentence was not clear. You keep marlin default setting but mine is changed. That need to be taken into account into my trials.

[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 <#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

@Stellarspace What is the status of your printer. Do you need help with the config from @digant73?

[J2J2]

Lot of print today, one 4h long and some 1-2h long. No flow or speed error.

[digant73]

@J2J2 with which changes? only baudrate 115200?

[oldman4U]

Looks good.

Those users with 250k reported similar issues with changing values or parameters and also intermitted stops and unfinished prints.

A bit more than a year ago, 3D printer changed from 8bit to 32bit processing, minimum doubling the clock speed, more likely with CPU 10x more efficient than before. The remaining print relevant hardware did not really change. This means that this part can not be the bottleneck, even in case 256 micro steps are used (which doe snot give a much better print but much more noise..).

It is more and more my feeling, that a well balanced system is more important than a single element with more or better functions. I hope, changing the baud rate further solves the problem for you and maybe some others. Eventually it does not work for all, but we found a possible way to fix it, even we do not know why.;-(

Happy printing

[J2J2]

@J2J2 with which changes? only baudrate 115200?

For me yes :). But my config is a little bit different from 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

@Stellarspace What is the status of your printer. Do you need help with the config from @digant73?

I don't even remember which config.ini I'm using. @digant73 Is the firmware you uploaded the latest from master or the latest from your Thingiverse post with a baud rate change?

[oldman4U]

👍🏻

J2J2 notifications@github.com schrieb am Fr. 6. Nov. 2020 um 17:20:

Lot of print today, one 4h long and some 1-2h long. No flow or speed error.

— 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-723168033, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM6XKZGVQGTIBRHO3FKYAL3SOQO3ZANCNFSM4TIPLFQQ .

[digant73]

@Stellarspace I uploaded Marlin FW only compiled with 115200 baudrate. The current TFT FW in BTT main branch added the new Terminal menu (by me) and other minor features not affecting the problem for sure

[sebsx]

@digant73

yes, but this is not the problem. It requires simply a change in the comment in config.ini

yeah sorry about that, I was just thinking out loud.

@oldman4U first print at 115200 done but since it was short 15 minutes one I will hold judgment for now. I'll continue to print over the weekend and report back.

[sebsx]

No luck, happened again at 115200 so I guess it's safe to assume it's not the baud rate causing this bug.

[oldman4U]

🥺

Like I wrote before. It is possible that it does not work for all. The printers will be slightly different which probably means that additional actions are required. I would stay with 115200 and change the buffers in addition. Maybe also try slower print speed to see if it makes a difference.

Which mainboard you all are using? Original GenL?

sebs notifications@github.com schrieb am Sa. 7. Nov. 2020 um 08:01:

No luck, happened again at 114200 so I guess it's safe to assume it's not the baud rate causing this bug.

[image: IMG_1026] https://user-images.githubusercontent.com/735033/98434391-30b9ff80-2123-11eb-9bf2-ff7df32550c3.jpeg [image: IMG_1027] https://user-images.githubusercontent.com/735033/98434393-331c5980-2123-11eb-87cc-090c62d3838d.jpeg

— 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-723402173, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM6XKZA5ZVDQ3XYRT6OM2BTSOTWFXANCNFSM4TIPLFQQ .

[J2J2]

:( Probably you should also try with same buffer settings as me.

[digant73]

@J2J2 can you provide the settings you changed so I will provide Marlin FW with those values? Also let us know if you will have the problem again in the future. Thanks

[sebsx]

@oldman4U yeah it's a GEN L board with the stock Marlin buffer configuration. I normally build from the bugfix-2.0.x branch but I might give the 2.0.x branch a try if changing buffer settings won't work.

I have an SGEN L v2.0 board sitting on my desk, I just need some time to work on the upgrade, I'm actually curious if only people with 8bit boards have this problem or not, might indicate something.

@J2J2 I'd appreciate if you could post your exact buffer settings mate :) Nevermind, found them above

#define BLOCK_BUFFER_SIZE 16 #define BUFSIZE 4 #define TX_BUFFER_SIZE 4 #define RX_BUFFER_SIZE 128

Edit: I just checked mine and the only difference is TX_BUFFER_SIZE which is set to zero.

[J2J2]

Agree with your edit :) TX_BUFFER_SIZE seems to be the only difference. I have also enclosed previously all my marlin configuration if you want to do a diff :). I also use stock board on artillery genius :).

[oldman4U]

The settings I sent are from an SKR board. So tuning is needed there also. But feeding an 8bit board with high baud rate from a 32bit TFT is for sure not a good idea.

sebs notifications@github.com schrieb am Sa. 7. Nov. 2020 um 11:23:

@oldman4U https://github.com/oldman4U yeah it's a GEN L board with the stock Marlin buffer configuration. I normally build from the bugfix-2.0.x branch but I might give the 2.0.x branch a try if changing buffer settings won't work.

I have an SGEN L v2.0 board sitting on my desk, I just need some time to work on the upgrade, I'm actually curious if only people with 8bit boards have this problem or not, might indicate something.

@J2J2 https://github.com/J2J2 I'd appreciate if you could post your exact buffer settings mate :)

— 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-723427806, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM6XKZHBKC64524R3UO6EVDSOUNYRANCNFSM4TIPLFQQ .

[oldman4U]

One thing you can also try is to change the serial ports. Most users have -1 (emulated USB) as the first and the TFT as the second serial port defined. I always use the TFT as the first serial port and -1 as the second (if needed at all).

[sebsx]

So now I set TX_BUFFER_SIZE to 4. Next I will enable NO_TIMEOUTS 1000 and then finally set TX_BUFFER_SIZE to 32 and enable ADVANCED_OK. Let's see if it makes a difference.

[oldman4U]

And what are the serial connections you defined?

[sebsx]

I only have this defined, so no second serial port at all. I always had this so it's not a change I made now. #define SERIAL_PORT 0

[sebsx]

Ok so 2 prints so far, about 2h total, all good. I ended up setting TX_BUFFER_SIZE to 32 in preparation for ADVANCED_OK. I'll keep printing and report back.

[Macguiwer]

I just tried and well now what goes down to 10% is the speed instead of the flow. I see it as progress. my configuration

define BLOCK_BUFFER_SIZE 16

define BUFSIZE 4

define TX_BUFFER_SIZE 32

define RX_BUFFER_SIZE 32

define NO_TIMEOUTS 1000 // Milliseconds

//#define ADVANCED_OK

[J2J2]

I just tried and well now what goes down to 10% is the speed instead of the flow. I see it as progress. my configuration

define BLOCK_BUFFER_SIZE 16

define BUFSIZE 4

define TX_BUFFER_SIZE 32

define RX_BUFFER_SIZE 32

define NO_TIMEOUTS 1000 // Milliseconds

//#define ADVANCED_OK

Slow down serial to 115200 :). With serial at 250000 and buffer similar to you i also have issue on speed instead of flow :)

[radek8]

I have not encountered this problem yet. If it helps someone, my parameters:

define BLOCK_BUFFER_SIZE 16

define BUFSIZE 16

define TX_BUFFER_SIZE 16

//#define RX_BUFFER_SIZE 1024 //#define NO_TIMEOUTS 1000 // Milliseconds //#define ADVANCED_OK

define BAUDRATE 250000

[oldman4U]

Radek. Seems this problem is related to Sidewinder installations with 8bit motherboards. I guess the original firmware had some tweaks to make this combination work.

[radek8]

It's hard to tell where the problem is. Communication runs via RS232. I don't see why the 8bit CPU should have a communication problem. Interference on the line also cannot be. This would generate meaningless commands or different values. But in this case the two values (M220 and M221) always change to 10%

[digant73]

@oldman4U @radek8 This problem was not present before the PR introducing the new FAN Control. In the Printing.c, at the end of the function toggleinfo(void) it is now called the function "speedQuery()". That seems the route cause of the problem. Also, the problem is not present moving to other menus during printing.

[oldman4U]

digant73

you are a very good developer. So why not trying to fix it by yourself or at least to contact the one who developed the suspicious code?

[digant73]

@oldman4U now my PR is finished so I will have a look. First attempt is to comment out the speedQuery() and see if the problem is not present. If not present, it's difficult that the problem could be related to baudrate/buffer on Marlin. Also Marlin FW was not changed. Only TFT FW was updated and we started to see the problem. I could suspect the problem is related to baudrate/buffer in case the parseAck is not able now (due to the long list of checks) to quickly match the ack provided by Marlin

[oldman4U]

And the content of your PR is great!!!;-)

Would you also be so kind to check, why the Layer hight is not shown on TFT screen while printing from mainboard SD card?

This would be GREAT if possible, thank you.

[radek8]

@oldman4U now my PR is finished so I will have a look. First attempt is to comment out the speedQuery() and see if the problem is not present. If not present, it's difficult that the problem could be related to baudrate/buffer on Marlin. Also Marlin FW was not changed. Only TFT FW was updated and we started to see the problem. I could suspect the problem is related to baudrate/buffer in case the parseAck is not able now (due to the long list of checks) to quickly match the ack provided by Marlin

There could be a problem here. speedQurey () asks Marlin for print speed and Flow, the printer answers 100 But for some reason (memory full?) the last character will not be saved. Subsequently, the changed value to 10% is returned to Marlin

[radek8]

If set to 99%, the problem would not occur?

[oldman4U]

Radek....... this is so cool;-)!!!

[radek8]

The code "speedQurey ()" was added based on an error I reported. #1048, PR #1060 Without this, the print speed and Flow value on the status screen are not regularly updated.

[oldman4U]

At least one user got improved results by changing the baud rate and also buffer size might make a difference. So this all makes even more sense since your last explanation.

[digant73]

The code "speedQurey ()" was added based on an error I reported. #1048, PR #1060 Without this, the print speed and Flow value on the status screen are not regularly updated.

I know that speedQuery was provided to update the screen info, but even if the info provided by Marlin is truncated (e.g. 10 instead of 100) the TFT simply should display a wrong value. But it seems that 10% reflects the value used by Marlin (the print is ruined). The speedQuery does not set the flow/speed. You have to manually do that from the proper menu. For that reason I have some doubts on the route cause. I will try to make some tests