[BUG] Can't print the model

[userosos]

Did you test the latest bugfix-2.0.x code?

No, but I will test it now!

Bug Description

I can't print the model. I has the errors in console repetier-server (i use repetier-server with raspberrypi print from sdcard not work too). Motherboard - skr 1.3, marlin 2.0.8.
I tested:

1. Commented the LCD display (//#define REPRAP_DISCOUNT_SMART_CONTROLLER and //#define SDSUPPORT)
2. Unplug the LCD display
3. Update marlin from 2.0.5.3 to 2.0.8
4. Comment //#define SERIAL_PORT_2 0
5. I tested simple test box (~35x35x35 mm) it PRINTED OK!
6. I recconect usb cable from motherboard to raspberrypi.
   logs gcode model.zip
   You can see some info about it in the forum: https://forum.repetier.com/discussion/8854/stop-the-printing?

Bug Timeline

It start when i print the model - Body2.stl i used Marlin 2.0.5.3 and 2.0.8

Expected behavior

Printing without the error and stop an printing.

Actual behavior

Print stop working on 1 layers

Steps to Reproduce

1. Upload the gcode into repetier-server or sdcard.
2. Start print

Version of Marlin Firmware

2.0.8

Printer model

Zav big +

Electronics

skr 1.3

Add-ons

No response

Your Slicer

Cura

Host Software

Repetier Server on raspberrypi

Additional information & file uploads

Marlin.zip
logs gcode model.zip

[userosos]

Now i printed 4 boxes on the edges of the working area and it stopped after 30 secs from starting printed.

Mesg:13:37:06.724: Warning: Communication timeout - resetting communication buffer.
Mesg:13:37:06.724: Connection status: Buffered:96, Manual Commands: 0, Job Commands: 5000
Mesg:13:37:06.724: Buffer used:96 Enforced free byte:41 lines stored:3
Send:13:37:06.724: N36133 G1 X298.948 Y27.219 E11.62024
Send:13:37:06.725: N36134 G1 X298.904 Y27.538 E11.64323
Mesg:13:37:10.728: Warning: Communication timeout - resetting communication buffer.
Mesg:13:37:10.729: Connection status: Buffered:82, Manual Commands: 0, Job Commands: 5000
Mesg:13:37:10.729: Buffer used:82 Enforced free byte:41 lines stored:2
Send:13:37:10.729: N36135 G1 X298.783 Y27.836 E11.66619
Send:13:37:10.729: N36136 G1 X298.593 Y28.096 E11.68918
Mesg:13:37:14.732: Warning: Communication timeout - resetting communication buffer.
Mesg:13:37:14.732: Connection status: Buffered:82, Manual Commands: 1, Job Commands: 5000
Mesg:13:37:14.732: Buffer used:82 Enforced free byte:24 lines stored:2
Mesg:13:37:14.732: Warning: Too many timeouts without response - disabling timeout message!
Mesg:13:37:14.732: Advice: If communication does not recover try adding usb reconnect on timeout in printer settings!
Mesg:13:37:14.732: This helps in case it is the serial driver that hangs.

Z_02mm_30%_test_box_PLA.zip

[ellensp]

get new copy of marlin 2.0.8 (or bugfix) a serious issue was found 2 hours ago that stopped some clients recovering from transmission errors.
both 2.0.x and bugfix were updated
https://github.com/MarlinFirmware/Marlin/archive/refs/heads/2.0.x.zip

[userosos]

get new copy of marlin 2.0.8 (or bugfix) a serious issue was found 2 hours ago that stopped some clients recovering from transmission errors.
both 2.0.x and bugfix were updated
https://github.com/MarlinFirmware/Marlin/archive/refs/heads/2.0.x.zip

Thx! Test it right now!

[userosos]

get new copy of marlin 2.0.8 (or bugfix) a serious issue was found 2 hours ago that stopped some clients recovering from transmission errors.
both 2.0.x and bugfix were updated
https://github.com/MarlinFirmware/Marlin/archive/refs/heads/2.0.x.zip

Didn't help.

Recv:14:21:16.850: echo:busy: processing
Recv:14:21:17.834: T:208.21 /210.00 B:64.92 /65.00 @:57 B@:13
Mesg:14:21:20.851: Warning: Communication timeout - resetting communication buffer.
Mesg:14:21:20.851: Connection status: Buffered:76, Manual Commands: 0, Job Commands: 5000
Mesg:14:21:20.851: Buffer used:76 Enforced free byte:39 lines stored:2
Send:14:21:20.851: N103 G1 X298.948 Y27.219 E11.62024
Send:14:21:20.852: N104 G1 X298.904 Y27.538 E11.64323
Send:14:21:23.423: M117 ETE 01:39:49
Mesg:14:21:27.433: Warning: Communication timeout - resetting communication buffer.
Mesg:14:21:27.433: Connection status: Buffered:95, Manual Commands: 0, Job Commands: 5000
Mesg:14:21:27.433: Buffer used:95 Enforced free byte:39 lines stored:3
Send:14:21:27.433: N105 G1 X298.783 Y27.836 E11.66619
Send:14:21:27.434: N106 G1 X298.593 Y28.096 E11.68918
Mesg:14:21:31.437: Warning: Communication timeout - resetting communication buffer.
Mesg:14:21:31.437: Connection status: Buffered:77, Manual Commands: 0, Job Commands: 5000
Mesg:14:21:31.437: Buffer used:77 Enforced free byte:39 lines stored:2
Mesg:14:21:31.437: Warning: Too many timeouts without response - disabling timeout message!
Mesg:14:21:31.437: Advice: If communication does not recover try adding usb reconnect on timeout in printer settings!
Mesg:14:21:31.437: This helps in case it is the serial driver that hangs.
Send:14:21:31.438: N107 G1 X298.345 Y28.301 E11.71216
Send:14:21:31.438: N108 G1 X298.054 Y28.438 E11.73512
Send:14:21:33.422: M117 Layer 1/49
Send:14:21:37.428: N109 G1 X297.363 Y28.511 E11.78473
Send:14:21:37.429: N110 G1 X273.347 Y28.512 E13.49935
Send:14:21:41.436: N111 G1 X272.649 Y28.503 E13.54919
Send:14:21:41.437: N112 G1 X272.33 Y28.459 E13.57218
Send:14:21:43.418: M117 ETA 16:01:31 day 4
Send:14:21:47.423: N113 G1 X272.032 Y28.338 E13.59514
Send:14:21:47.424: N114 G1 X271.773 Y28.147 E13.61812
Mesg:14:21:49.640: Connection closed by os during print ... trying reconnect for 10 seconds to continue ...

[rhapsodyv]

Looking at the log, it seems the host is sending two commands at time to marlin.
This is not supported.

[repetier]

Repetier-Server always had send multiple commands and that is no problem when the input buffer is not exceeded. Plus marlin 2 has 4 buffers for commands in addition. If this get exceeded the commands make no sense and some errors like missing line number/checksum error/unknown command will appear as response.

The problem here is that suddenly no data gets written to serial where server is connected to. Never had this on my marlin printers, but know users that got this. Some reported removing serial2 worked so one thing might be that internal mapping write to correct serial might get wrong under some conditions. When the other serial suddenly gets the ack messages communication will of course fail.

@userosos You should enable ack as well so it becomes visible that this is what is missing (the "ok") causing the timeout.

[rhapsodyv]

Current marlin doesn't support hosts sending multiples commands at time, even if there's buffer space available.

I tested it myself.

I don't know if old marlin versions that was supported, but now it doesn't work.

And the, by reprap protocol, hosts should wait for "ok" to send next command. Isn't?

[userosos]

@userosos You should enable ack as well so it becomes visible that this is what is missing (the "ok") causing the timeout.

Z_02mm_30%_test_box_PLA.log
It is full log the print.

[repetier]

We are sending multiple commands for over 10 years with great success, so it really works. The command gets buffered in the serial rx buffer until marlin parses them. The simple protocol says to wait for "ok", yes. But that can be too slow with many short moves. With the possebility to send multiple commands the transmission speed is greatly increased. But of course we have to throttle and count the "ok" so we do not flood the buffers. But as I already said, this is not the problem here.

Actually the skr 1.3 with the usb native serial port has hardware flow control, so I can even try to send 100 commands in parallel and get no problems.

Send:15:27:03.497: N2314 M104 S300
Recv:15:27:03.498: ok
Send:15:27:04.466: N2315 M104 S285 T0
Send:15:27:04.466: N2316 M104 S285 T0
Mesg:15:27:08.477: Warning: Communication timeout - resetting communication buffer.
Mesg:15:27:08.477: Connection status: Buffered:44, Manual Commands: 0, Job Commands: 0
Mesg:15:27:08.477: Buffer used:44 Enforced free byte:0 lines stored:2

But look what I just could do - I have send a command that can not be executed error free. I have no heater connected at the skr1.3 board here. Could send 1000s of commands but when I set temperature causing an error communication stops without a hint. Have no display connected so can not say if I would see anything there. It would be great if marlin would send a message before going into an error state to all serials so server or user can see why it happens. Actually reprap protocol has !!message for serious errors, but an "error:" would also be sufficient to inform user.

@userosos Do you see a error message on display when communication stops? What happens if you e.g. send M104 S300 ? Does that stop communication as well?

[userosos]

@userosos Do you see a error message on display when communication stops? What happens if you e.g. send M104 S300 ? Does that stop communication as well?

In display i saw the error (when display was connected).

After communication stops an printer stop about 10-30 secs and buzzer worked. After it extruder gohome (i think that it system rescue of repetier-server work after recconect)

[rhapsodyv]

We are sending multiple commands for over 10 years with great success, so it really works. The command gets buffered in the serial rx buffer until marlin parses them. The simple protocol says to wait for "ok", yes.

It's what I said. I don't know if it worked before, but not it doesn't work. Even LPC.
We guarantee only what protocol says.

I have a task to take a look in this buffer management. But the all serial code was refactored and probably this is the reason that double commands are a problem now.

Actually the skr 1.3 with the usb native serial port has hardware flow control, so I can even try to send 100 commands in parallel and get no problems.

Actually reprap protocol has !!message for serious errors, but an "error:" would also be sufficient to inform user.

I will take a look, but some errors are just marlin dying.

[repetier]

I will take a look, but some errors are just marlin dying.

Even that would be an information. The problem is that server creates timeouts because it gets no responses. If we get some information before like "marlin stops due to severe error" or whatever users and serve can see it in console and know there is problem instead of thinking there is a communication issue. I even remember when marlin e.g. always responded to send M999 to continue. Might depend on configuration and error that happens - for some a full stop until reset would be safest in deed, but a message before stopping any communication would be really nice. Maybe it is even planned but no delay before endless loop so data did not get send. I'm really not familiar with the marlin sources as you see.

[rhapsodyv]

I will take a look, but some errors are just marlin dying.

Even that would be an information. The problem is that server creates timeouts because it gets no responses. If we get some information before like "marlin stops due to severe error" or whatever users and serve can see it in console and know there is problem instead of thinking there is a communication issue. I even remember when marlin e.g. always responded to send M999 to continue. Might depend on configuration and error that happens - for some a full stop until reset would be safest in deed, but a message before stopping any communication would be really nice. Maybe it is even planned but no delay before endless loop so data did not get send. I'm really not familiar with the marlin sources as you see.

Sure. Your are right. Better communication flow helps the two sides.

Right now we are putting a lot of effort to find and fix all serial related issues.

I will take a look in the double commands issue and in the error reporting too.

[userosos]

Sure. Your are right. Better communication flow helps the two sides.

Right now we are putting a lot of effort to find and fix all serial related issues.

I will take a look in the double commands issue and in the error reporting too.

What i can do for resolve the problem? Only wait?