[Q] Random pauses or hesitation when printing.

[V1EngineeringInc]

While printing once or twice a print, sometimes more, the machine will stop right in the middle of printing for a second, maybe even two. No errors or anything, it leaves an ugly blob, and it just continues on. It does not happen the same place on the file or on the machine. If I had to say anything, it might happen more often during circle moves, or curves. This does not happen while using the same screens for my CNC machines.

I have 6 printers and 2 CNC's running TFT35 V3 E3 screens. I have noticed this issue for probably as long as I have used the screens, more than two years I would guess. Some screens are brand new and some are very old. I update marlin and the TFT several times a year. Some of my gcode is old and ran perfectly fine on older 1286 screens, and some of my files are new.

So I think this is either some sort of configuration issue, slicer setting, or a screen firmware bug. Any ideas?

Config, config.zip

[V1EngineeringInc]

Is there any sort of debugging I can run, check the buffer of the screen, or anything else that might help?

[radek8]

Can you try recompiling marli with these values?

define BLOCK_BUFFER_SIZE 16

define MAX_CMD_SIZE 96

define BUFSIZE 16

define TX_BUFFER_SIZE 32

define RX_BUFFER_SIZE 32

[V1EngineeringInc]

Thanks I will try that.

define BLOCK_BUFFER_SIZE 16

define MAX_CMD_SIZE 96

Those are default values.

I will change the others. Is this in the documentation anywhere, seems like it kind of should be?

[kisslorand]

I would also check the slicer for something like "Maximum Resolution" and/or "Maximum Deviation" and raise them a little. I do not know what slicer you're using, the parameters mentioned are from Cura. I remember the days when I was using Octoprint with an 8 bit mainboard printer and I had a lot of blobs on curved surfaces. Changing the values of these settings mitigated the issue. By now I use ARC Welder so there's no issue whatsoever having tiny minuscule segments for curved lines. In fact the problem also went away on my 8 bit board using ARC Welder plugin in Octoprint.

[V1EngineeringInc]

I am using a SKR Pro, and Simplify3D I can reduce the segments. Thanks for the tips.

Seems a bit off to me that it works fine on a rambo (8bit) with a 1286 screen, but the same Gcode only hesitates on the 32 bit board and TFT.

[V1EngineeringInc]

Waiting for this print to finish before I change the firmware for the memory tweaks. I just watched it happen again. It happened on an outline (90% speed) that was a long 4" straight line and just as it hit the corner it paused before the curves.... So not printing fast, buffer should have easily been full, hmm.

This is really puzzling to me. Neither of you have seen your printers hesitate?

[kisslorand]

I totally forgot about this issue since this TFT FW and 32 bits mainboard (and using ARC Welder). Just for science... try Cura with ARC... :)

On the other hand this TFT FW has a major setback, it sends every command only after receiving "OK" from the mainboard from the previous command. I am contemplating for a while to integrate "Advanced OK" (it allows filling the mainboard's buffer with commands, not send them one by one), but giving the lack of interest from BTT towards this repository I do not feel comfortable wasting my time for nothing. It seems even the free work of the contributors is too expensive for them...

I do not want to spoil the game but I do not think the suggestions of @radek8 will help because of the aforementioned reasons. I can only hope I'm wrong... :)

[V1EngineeringInc]

I hear you. I have sold these screens for a while now but I only sold them to use the Marlin side. You made it so the TFT was even reliable. I really hope they give this some more attention, if not I think I will be switching out to ESP3D control direct from the board and skip the screen all together. It is a bummer though I think these screens have huge potential. They need to be more receptive to some changes, stability and customizations.

I appreciate the help I get here though. I have always received sincere help.

(testing the mem changes now, just need to hang out near the printer to see if I can catch some hesitations)

[ETE-Design]

I totally forgot about this issue since this TFT FW and 32 bits mainboard (and using ARC Welder). Just for science... try Cura with ARC... :)

On the other hand this TFT FW has a major setback, it sends every command only after receiving "OK" from the mainboard from the previous command. I am contemplating for a while to integrate "Advanced OK" (it allows filling the mainboard's buffer with commands, not send them one by one), but giving the lack of interest from BTT towards this repository I do not feel comfortable wasting my time for nothing. It seems even the free work of the contributors is too expensive for them...

I do not want to spoil the game but I do not think the suggestions of @radek8 will help because of the aforementioned reasons. I can only hope I'm wrong... :)

I often tell BTT to merge new PR's but they are really slow at it, I even asked them to hand over the merge process to a person who develop on this but with no luck :-( Would really love if you could find time to integrate Advanced OK to this Firmware... I know that BTT lack interest of firmware cause they don't make money on it, but I think a lot of us users really like all the work you guys put into this.

/ETE-Design

[V1EngineeringInc]

I could try and ask my BTT rep to get something looked at or pushed to the front of the list if we had something specific. I have no idea if it would do anything but I could try. Maybe, just maybe, having the request come from two sides would help.

[ETE-Design]

I could try and ask my BTT rep to get something looked at or pushed to the front of the list if we had something specific. I have no idea if it would do anything but I could try. Maybe, just maybe, having the request come from two sides would help.

There is already a lot of PR who need to be merged, most of then seem to be things who need to be merged

[V1EngineeringInc]

So I think those memory changes worked. I have been kinda busy but floating around one of the printers all day and I have not caught a single hesitation!!!

Should I (or one of us) add this to the firmware changes section of the INI file?

[kisslorand]

Just another thought... Do you have PLR (Power Loss Recovery) enabled on your TFTs? Writing speed is much slower than reading speed, printing high poly surfaces can exhaust the buffer pretty quick and it might be happening right when PLR checkpoints are written to SD or USB so the printer makes a slight pause thus creating blobs. Maybe it worth checking this too.

[V1EngineeringInc]

No, No power loss recovery. Good idea though.

[ETE-Design]

So seems like it helped I written to BTT again over messenger... A lot of PR got merged now 😀 @kisslorand Hope you still will consider making Advanced OK for this TFT 😀

[kisslorand]

@ETE-Design

@kisslorand Hope you still will consider making Advanced OK for this TFT 😀

Sure.

[rondlh]

I also noticed some stuttering. My buffers are setup even larger than suggested. I use a serial baud rate of 1M bit. Arc welder could possibly help, I will give it a try. Support for ADVANCED_OK would be amazing, but seems like a big project.

[slwise]

A friend and I were both running a SKR Mini E3 V3 with the TFT35 V3 E3. We were both experiencing the same issue you described with pausing and blobs in the print. I changed the buffer size in Marlin to 64 but no change. I also increased the baud rate from 115200 to 250000, still no change. I finally fixed the issue on both printers by lowering the baud rate to 57600. We've been running this way for months with no issues. My best guess is apparently 115200 was too fast for the SKR to handle and causing the TFT to have to retransmit the data. Hope this helps.

[V1EngineeringInc]

Interesting, I need to try that. As well, I think I caught another hesitation with the memory tweaks, but I am not sure. It is definitely happening much much less. I am set to 250000....

[digant73]

A friend and I were both running a SKR Mini E3 V3 with the TFT35 V3 E3. We were both experiencing the same issue you described with pausing and blobs in the print. I changed the buffer size in Marlin to 64 but no change. I also increased the baud rate from 115200 to 250000, still no change. I finally fixed the issue on both printers by lowering the baud rate to 57600. We've been running this way for months with no issues. My best guess is apparently 115200 was too fast for the SKR to handle and causing the TFT to have to retransmit the data. Hope this helps.

TFT simply sends a gcode when the printer's FW (Marlin etc...) acknowledges the gcode previously sent by TFT. There is no retransmission from TFT. The issue seems to be in Marlin (probably related to buffers and/or connection speed). Ironically, some speed improvements made on TFT fw triggered this issue on some printer's fw with an unbalanced setup

[V1EngineeringInc]

I still have not gotten to testing the Baud rate change. I can now confirm the memory changes did not fix it. It might be slightly better but my printers still hesitate randomly.

I will test the Baud rate after RMRRF.

[africsnail]

I also have a similar issue after updating my board's (SKR Mini E3 V3) fw to Marlin 2.1 (previously I had 2.0 and I had no problems). I also made sure to update the TFT35. Now it seems to have some kind of mess ups with the gcode being corrupted (like a missing or additional character in a command) or it just pauses randomly as described here. I tried many different buffer sizes and neither of them worked.

I am going to try the lower baudrate as mentioned here. I was running at the default 115200.

Edit: It didn't help. Also the problem may be just caused by me not trying to print as fast before. I was playing around with input shaping so I was trying faster speeds after the update.

[kisslorand]

@kisslorand Hope you still will consider making Advanced OK for this TFT 😀

I just remembered why I haven't got working on "Advanced OK". There's a bug on SKR and SKR Mini motherboards (there might be others affected too), a bug that can be avoided only if commands are sent one by one, so "Advanced OK" would be a disaster on these motherboards. I saw the issue came up a while ago on the Marlin repo but there is no sign of anyone working on a solution.

[ETE-Design]

@kisslorand Hope you still will consider making Advanced OK for this TFT 😀

I just remembered why I haven't got working on "Advanced OK". There's a bug on SKR and SKR Mini motherboards (there might be others affected too), a bug that can be avoided only if commands are sent one by one, so "Advanced OK" would be a disaster on these motherboards. I saw the issue came up a while ago on the Marlin repo but there is no sign of anyone working on a solution.

And how about all other boards that isen't SKR-Series? 😀 Is it not just to make a Note in the first part of Config.ini to tell people not to activate it if they have SKR-Series Boards?

[kisslorand]

Each configuration that has to be taken into account during printing slows down the sending of the gcodes which itself defeats the advantages of the Advanced OK.

[ETE-Design]

Each configuration that has to be taken into account during printing slows down the sending of the gcodes which itself defeats the advantages of the Advanced OK.

@kisslorand Think you misunderstood me, make a note in the top of Config.ini like:

"# Advanced_OK (in Configuration_adv.h) - Issue with SKR-Series"

That shouldn't slow down sending of gcodes?

[rondlh]

A friend and I were both running a SKR Mini E3 V3 with the TFT35 V3 E3. We were both experiencing the same issue you described with pausing and blobs in the print. I changed the buffer size in Marlin to 64 but no change. I also increased the baud rate from 115200 to 250000, still no change. I finally fixed the issue on both printers by lowering the baud rate to 57600. We've been running this way for months with no issues. My best guess is apparently 115200 was too fast for the SKR to handle and causing the TFT to have to retransmit the data. Hope this helps.

Interesting, but serial communication is handled in hardware, not in software. The software will get a signal when a command is received completely ('\n' at the end. Then it's up to the processor to handle the command.). I personally run all serial communication at 1M bit. If a command is 40 characters long then it will take at least 10 * 40 / 57600 seconds (=7ms) to transmit. As long as you don't have data corruption I do not see any disadvantage on running the serial lines faster.

[kisslorand]

@kisslorand Think you misunderstood me, make a note in the top of Config.ini like:

"# Advanced_OK (in Configuration_adv.h) - Issue with SKR-Series"

I might have misunderstood you but the issue remains. If Advanced OK is implemented, it should be configurable (enabled/disabled) because of the problematic motherboards. If it's configurable than it adds latency in preparing the gcodes to be sent during printing which defeats the purpose of Advanced OK. The added latency will surely hurt at least the problematic motherboards, they will not benefit the advantages of Advanced OK but will be burdened by this extra latency. Also for other motherboards I have no way to estimate if the added latency will be less of a problem than the benefits of the Advanced OK. I keep wondering why Gina didn't add Advanced OK to Octoprint, knowing that the Raspberry Pi's MCU is much more powerful than the ones we have in our TFTs.

Only real tests can answer the dilemma, but I do not feel comfortable working huge number of hours for possible negative results, not to mention that a particular user will rip my head off accusing me I made another "useless, stupid, not necessary, full of bugs" modification to this firmware when "everything was working perfectly".

[V1EngineeringInc]

Any interest in your own fork?

Forgive me if I am not really understanding how this all works but it seems the firmware is fairly stable. If you made a custom fork, your way, would it be easier to just get these things fast and stable. Even if you did not bother to keep them in sync. For most of us, in terms of 3D printing the screen has all the features we need right, heck maybe even some we don't? Then we have a solid stable version to run.

As my printer designs increase in speed, the pitfalls of this screen are starting to really hinder print quality. I have been actively researching other board and screen combos. I don't want my users to think it is a printer issue when it is a screen issue.

Beyond that, I would like to make a few buttons CNC specific, but I might be able to get help with that.

[kisslorand]

As my printer designs increase in speed, the pitfalls of this screen are starting to really hinder print quality. I have been actively researching other board and screen combos. I don't want my users to think it is a printer issue when it is a screen issue.

Maybe it would be a good idea to use TFTs with the most powerful MCU and with custom FW that have the not needed, unused features eliminated to free the MCU during printing (ex. checking input from all serial ports used by ESP3D, Octoprint, etc;; comment parsing, eliminating RRF support and so on)

Also you might consider switching to Klipper...

[V1EngineeringInc]

I am not really sure how to take that. I hope my message came off as supportive and encouraging. I think the board and screen combo has so much potential to grow into, but if you think it doesn't than I will make the switch sooner than later for the printers I work with.

I really admire your work, and was hoping if you did your own fork we could have a stand-out setup, and you would have the ability to develop without getting hindered at each pull request.

[digant73]

@V1EngineeringInc Hopefully #2788 recently merged could fix the stuttering on printing you reported

[V1EngineeringInc]

I will load it up today and give it a shot, thanks for the heads-up.

[rondlh]

@kisslorand

Only real tests can answer the dilemma, but I do not feel comfortable working huge number of hours for possible negative results, not to mention that a particular user will rip my head off accusing me I made another "useless, stupid, not necessary, full of bugs" modification to this firmware when "everything was working perfectly".

You have my support if you need a beta tester. I have several test prints, like a vase mode cylinder that shows the effects of stuttering very clearly. I did some test with Marlin using D576 (Buffer Monitoring) which shows that buffer underruns happen frequently, but the wait time is quite low (< 50ms). I believe advanced_ok should completely solve the stuttering. I agree, this the outcome of implementing advanced_ok is not certain, and bugs will happen, but either way I hope the community can be constructive and supportive. Currently advanced_ok is the most important missing feature of the TFT.

[kisslorand]

@V1EngineeringInc @rondlh @ETE-Design @radek8 @All_The_Others

I created a Discord channel where we can discuss about these issues.

[kisslorand]

I found a possible solution for the hesitations during prints. Whoever wants to test it let me know.

BTW, Advanced_OK is already in Alpha phase (virtual prints have positive results).

[makersteve3d]

Count me in for testing too :)

[kisslorand]

Let me know your TFT variant, I will compile it for you

[V1EngineeringInc]

tft35 e3 v3 gd version and regular non GD version

[kisslorand]

I found a possible solution for the hesitations during prints. Whoever wants to test it let me know.

I compiled all TFT variants and uploaded them to Mega. The builds include several other changes too, they include PR #2701, PR #2793, PR #2794 and a rework of #2788 (which is a partial fix only and introduces a new bug).

[V1EngineeringInc]

Testing it now.

[makersteve3d]

I won’t be able to test until tomorrow evening, but watching with interest!

On Mon, 22 May 2023 at 19:20, Ryan V1 @.***> wrote:

Testing it now.

— Reply to this email directly, view it on GitHub https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/issues/2761#issuecomment-1557689042, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAAMTX5UAKWECQUHG4CSHFTXHOU7VANCNFSM6AAAAAAWUZN4ZA . You are receiving this because you commented.Message ID: @.*** .com>

[rondlh]

Great job! Testing the BTT TFT35 V3.0 version. I will run some test prints and report back.

NOTE: Don't forget to enable ADVANCED_OK in Marlin's Configuration_adv.h

UPDATE: I did a speed test of a spiraled cylinder (r=100mm, no G2/G3) and it works fine, ZERO HICCUPS. I thought perhaps I might be able to print faster now, but that is not the case, the limit is exactly at the same point as before (145mm/s, 0.5mm nozzle, 0.25 layer height). Gaps appear at 150mm/s like before.

[kisslorand]

NOTE: Don't forget to enable ADVANCED_OK in Marlin's Configuration_adv.h

Advanced_OK is not implemented in the files posted on Mega. For a test run of Advanced_OK we can discuss on the Discord channel.

[rondlh]

NOTE: Don't forget to enable ADVANCED_OK in Marlin's Configuration_adv.h

Advanced_OK is not implemented in the files posted on Mega. For a test run of Advanced_OK we can discuss on the Discord channel.

The Discord doesn't like my VPN... I cannot get in. The version on Mega seems to solve the hiccups for me. I would need the BTT TFT35 V3.0 version of the ADVANCED_OK.

[V1EngineeringInc]

So far so good, I have not sat and watched them for very long but I am not seeing any blobs on the outer surface yet. More prints today. I have 3 printers running the test BIN's.

[kisslorand]

---

@rondlh

Gaps appear at 150mm/s like before.

The version on Mega seems to solve the hiccups for me.

These two seems contradictory for me, would you care to clarify it?

The Discord doesn't like my VPN... I cannot get in.

I can see you already joined the Discord channel a few days ago,

---

@V1EngineeringInc

I am not seeing any blobs on the outer surface yet

Have you seen blobs for the same print before on master?

---

If the changes present in the files from Mega have positive results, I will include them into the Advanced_OK version, that would - hopefully - increase tremendously the stability during print. I have to rely only on my virtual prints (on a test rig, not an actual printer) and feedbacks from you because my printers do not exhibit this hesitation issue, I cannot recreate it on them.

---

[V1EngineeringInc]

Yes, But I am looking for specific prints that have more than others. Since I have a small print farm running and an inventory of parts sitting here I am looking for some with more issues than others. I am just a little behind right now so I have to print specific parts to keep up with orders.

[rondlh]

Gaps appear at 150mm/s like before.

This is a limit of my hotend, with a 0.5mm nozzle/line width, and 0.25mm layer height, 145mm/s works fine (about 450mm of 1.75mm filament per minute), but 150mm/s fails (gaps), the extrusion skips for a short time and gaps become visible in the printed (test) part, a spiralized cylinder.

The version on Mega seems to solve the hiccups for me.

I call a hiccup when I visibly see that the movement stops for a fraction of a second, normally the movement should be continues.

The Discord doesn't like my VPN... I cannot get in.

I can see you already joined the Discord channel a few days ago,

Right, I tried to join, perhaps successfully, but it doesn't allow me to login because of suspicious network activity. That's probably just the VPN I use, I'm stationed in China.

[V1EngineeringInc]

Okay it seems this doesn't change anything. I am running one of my printers at 80% speed to use up some filament I don't care for. The prints are still clearly getting blobs. The blabs are in completely different places, but they are all on curves, I have seen them on large very subtle curves and very small 5-6mm curves. No blobs on straight lines. (oddly it the one I ran slower has more blobs??))

So that seems to rule out speed, and possibly even buffer issues right?

SKR Box.zip This file gets them on the outer two circular edges. Any info to learn from this?