Printer pausing (connection timeout) mid print

CptAmmogeddon

So I used my printer again after ~1 month. I had my issues with it a few times, and since it is a no-name kit (probably from China), finding solutions is always a hassle. But now I got a new problem:

After starting the print as usual, the printer will pause after a few seconds, and after a few moments (sometimes up to 2 minutes) it will resume, with the error message "Communication timeout - reset send buffer block" popping up. Rinse and repeat every few (normal) print seconds.

The issue seems to appear at roughly the same intervals. Two rather similar (but not identical) small prints had this issue at pretty much the same time: while printing the skirt (3 lines), after the first half of the first circle, and after completing that circle.

I am controlling my printer directly via serial connection. Nothing is overheating, it's connecting fine and can be manually controlled without any problems. I also restarted my PC and my Printer multiple times. I didn't change any settings (e.g. Baudrate [115200 btw] etc.) since the last time.

Any ideas what it could be? If any other information is needed I will add it, this is my first post on here, so I don't really know whats important to know :)

Thanks in advance!

Repetier

Communication timeout means we are connected over os (raspberry I guess?) with the printer, but we did not receive a line starting with "ok" form printer firmware that tells us, that it has received and processed our command, also we expected this. So if "timeout" defined in printer configuration has passed and we got no "ok" and no "busy" telling us that printer needs more time to execute we show that error and assume it was a communication error and send "ok" anyway.

The problem is not deciding what causes it. So in console if ack and command filter are disabled, do you see any responses from firmware when it continues? In that case it is just communication error and you might test solutions to improve communication quality.

If you get no responses new commands get send the linux driver is crashed. Seems to happen on some drivers with communication problems (maybe cross talk or other electric noise). Same combo often works stable for other users. As a intermediate solution we have an option "USB Reconnect after Timeout" that simulates that you unplugged usb cord so driver restarts. Works only on linux systems. You will still get pauses here until this is triggered, but print hopefully continues (if printer does not reset on reconnect which we try to prevent, but not all drivers support it).

In total you should check your system for electric problems.
- use short usb cable, double shielded maybe even with ferrite.
- Make sure cable is not close to other cables that are unshielded.
- If you are up to it check inside printer where the controller is, if cables are laying neatly, no blank contacts to housing or laying on usb output.
- Check also the bolt menu in server gui. Does it show undervoltage - never? If not, undervoltage in pi is also the cause of many problems. Then a better power source is needed. Do not use USB charger - they adjust voltage not fast enough even if amps match. You need a power supply that is made to hold a stable voltage and best one with 5.1 or 5.2V output. Also make sure usb to power supply has thick enough GND/5V cables or resistence of them will already drop voltage at higher load.

CptAmmogeddon

So I just tried to print the same thing with different settings and it still doesn't work.

But trying an older gcode works. So it's officially a gcode/Slicing-problem (im using Cura) I guess...

I know this isn't a Cura-forum, but are there any solutions I could try for THAT?

Repetier

You need to enable logging and check the g-code at the place where it happens. Maybe printer just hangs as some condition is not to it's liking and then causing timeouts as it is waiting for user interaction without telling. Who knows as every vendor has it's own mods. At least you should also check printer display for things.

What often happens is that M109 or M190 never finishes as the target temperature is not reached stable. We have a big timeout for them but then you would also see timeouts as described. So maybe you were just using lower temperatures with the other g-code.

CptAmmogeddon

So I have the same problem again, with the same settings that worked last time.

The error first occurs during the first layer, sometimes right after starting, sometimes after a few seconds.

The last print I tried froze (apparently completely, or at least longer than thev"usual" 2 mins) on Layer 1 of 172, with this g-code-command: N64 G1 X75. 631 Y50. 154 E0. 02522*4, which seemed to have received an "ok".

Repetier

What printer/board are you using? What does
lsusb
show as device for your printer?

You need to enable log and show more then one line to see what happened. Did you get timeout, were new command send, did you get any responses from firmware after that?

It might be same as I heard of with some CH34x chips that driver stops sending received lines. There is an option to reconnect on timeouts in server settings for linux that might help fixing it when it happens.

What is strange in your case is that it sounds like it appears always at print start. Normally I hear this problem happens randomly. But might be due to reason why it happens. I personally think it is electric noise causing usb errors making the driver fail in back channel afterwards. Maybe some counter bing set wrong and waiting forever. That is why resetting usb helps as it restarts the driver.