Error message in console

starea1

Hi, i am seeing this error messages in printer console - anything i should worry about?

Mesg:15:55:25.914: Connection status: Buffered:41, Manual Commands: 1, Job Commands: 5000

Mesg:15:55:25.914: Buffer used:41 Enforced free byte:41 lines stored:1

Mesg:15:55:34.453: Warning: Communication timeout - resetting communication buffer.

Mesg:15:55:34.453: Connection status: Buffered:41, Manual Commands: 1, Job Commands: 5000

Mesg:15:55:34.453: Buffer used:41 Enforced free byte:41 lines stored:1

Mesg:15:58:04.236: Warning: Communication timeout - resetting communication buffer.

Mesg:15:58:04.236: Connection status: Buffered:39, Manual Commands: 1, Job Commands: 5000

Mesg:15:58:04.236: Buffer used:39 Enforced free byte:39 lines stored:1

Mesg:15:58:11.926: Warning: Communication timeout - resetting communication buffer.

Mesg:15:58:11.926: Connection status: Buffered:39, Manual Commands: 1, Job Commands: 5000

Mesg:15:58:11.927: Buffer used:39 Enforced free byte:39 lines stored:1

Mesg:15:58:23.750: Warning: Communication timeout - resetting communication buffer.

Mesg:15:58:23.750: Connection status: Buffered:39, Manual Commands: 1, Job Commands: 5000

Mesg:15:58:23.750: Buffer used:39 Enforced free byte:37 lines stored:1

Printer is Ender 3 Pro, RaspberyPi with Raspbian (2020-08-20-raspios-buster-armhf-lite) and latest Repetier-server (deb). 

Prints are OK, i had problem with defining printer port /dev/ttyUSB0 (printer stops extruding randomly)  and changed it to /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AM0098E9-if00-port0 (works ok now, except the messages).

Thanks in advance

Repetier

Communication timeouts happen under 2 conditions. If the printer sends "ok" but server receives something else - so it is a communication error. If you enable ack you should see the "ok". Some firmwares unfortunately do not provide informations to detect such problems early so we see then a timeout which helps server to continue.

The other case is when there is no response from firmware for a longer period > timeout defined in communication settings. Newer firmwares support sending "busy: ...." when they are busy with some slow operations so you can have low timeouts of typical 3 seconds. If your firmware does not send busy: you need a longer timeout in settings to prevent every longer slow move to trigger a timeout.

You need to check full communication to see what exactly is the case for you. Frequency is quite high here but that also be a slow infill for first layer with short timeout. So check based on what I said.

starea1

Hi, i did check ACK and it is returning OK. Now i have lifted timeout to 5 sec and only message i get is ACK counting up..

Recv:14:59:08.116: ok (376)

Thanks for help!