Closed userosos closed 3 years ago
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.
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
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!
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 ...
Looking at the log, it seems the host is sending two commands at time to marlin. This is not supported.
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.
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 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.
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 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)
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.
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.
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.
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?
@userosos You should write gcode not causing serious errors:-) As it looks the stopping communication is a side effect to your max temperature error. Maybe your configuration is just wrong and you need to increase max. allowed temperature to not trigger that error with your temperatures. But your solution is to find the primary source. Even when @rhapsodyv adds a message before going in error state it would still stop for you, just then you would be able to see in console why. But that is the same error you see on display now I guess.
@userosos You should write gcode not causing serious errors:-) As it looks the stopping communication is a side effect to your max temperature error. Maybe your configuration is just wrong and you need to increase max. allowed temperature to not trigger that error with your temperatures. But your solution is to find the primary source. Even when @rhapsodyv adds a message before going in error state it would still stop for you, just then you would be able to see in console why. But that is the same error you see on display now I guess.
Hm. It can error from Cura Ultimaker? In marlin:
#define HEATER_0_MAXTEMP 275 // - it ok. i think. In console i can see that T0 about 210 C.
Or you mean that it triggered protect and i need calibrate PID or set protect windows?
#define TEMP_RESIDENCY_TIME 10 // (seconds) Time to wait for hotend to "settle" in M109
#define TEMP_WINDOW 1 // (°C) Temperature proximity for the "temperature reached" timer
#define TEMP_HYSTERESIS 3 // (°C) Temperature proximity considered "close enough" to the target
That should normally be good. Do you get such an error message every time the print stops? I can not say when marlin creates that message or what |:1 means for max temp error. Would have expected a temperature here. But it can be a hardware failure e.g. if sensor creates a short or break it causes a different temperature being read that can lead to errors. Often the error only appears at special extruder positions where the cable gets bend most in one direction. I remember you mentioned printing at the side.
I can not say when marlin creates that message or what |:1 means for max temp error. Would have expected a temperature here. But it can be a hardware failure e.g. if sensor creates a short or break it causes a different temperature being read that can lead to errors. Often the error only appears at special extruder positions where the cable gets bend most in one direction. I remember you mentioned printing at the side.
Yes, i can't see in console that the temperature incorrect. If i use not test print (But printing uses the entire workspace) it can stops after 10-20 mins after start printing.
Then you should replace cable and sensor if you see incorrect temperatures. Hopefully then the problem is gone.
Then you should replace cable and sensor if you see incorrect temperatures. Hopefully then the problem is gone.
But i can't see the problem with termistor. It work ok.
Now i set E0 to 195 C and moove the hotend from repetier-server on the edge of the workspace, through the 3rd pass I got the error
Send:18:52:41.690: N2313 M104 S195 T0
Recv:18:52:41.692: ok
Send:18:52:46.933: N2314 M140 S0
Recv:18:52:46.935: ok
Recv:18:54:02.623: Slow command added:G28 X0
Send:18:54:02.623: N2315 G28 X0
Recv:18:54:03.272: ok
Send:18:54:03.272: N2316 M114
Recv:18:54:03.274: ok
Recv:18:54:03.275: Slow command added:G28 Y0
Send:18:54:03.275: N2317 G28 Y0
Recv:18:54:03.930: ok
Send:18:54:03.931: N2318 M114
Recv:18:54:03.933: ok
Send:18:54:14.806: N2319 G1 X3.07 Y297.07 F6000
Recv:18:54:14.808: ok
Send:18:54:17.806: N2320 G1 X295.02 Y296.69 F6000
Recv:18:54:17.808: ok
Send:18:54:20.907: N2321 G1 X297.70 Y2.83 F6000
Recv:18:54:20.909: ok
Send:18:54:26.603: N2322 G1 X2.19 Y1.60 F6000
Recv:18:54:26.605: ok
Send:18:54:32.846: N2323 G1 X0.00 Y182.82 F6000
Recv:18:54:32.848: ok
Send:18:54:36.563: N2324 G1 X0.21 Y298.45 F6000
Recv:18:54:36.566: ok
Send:18:54:40.325: N2325 G1 X299.06 Y298.45 F6000
Recv:18:54:40.327: ok
Send:18:54:46.334: N2326 G1 X299.44 Y12.64 F6000
Recv:18:54:46.337: ok
Send:18:54:55.434: N2327 G1 X1.36 Y0.76 F6000
Recv:18:54:55.437: ok
Send:18:55:14.736: N2328 G1 X1.54 Y298.61 F6000
Recv:18:55:14.738: ok
Send:18:55:18.456: N2329 G1 X298.85 Y298.99 F6000
Recv:18:55:18.457: ok
Send:18:55:21.696: N2330 G1 X298.85 Y1.30 F6000
Recv:18:55:21.699: ok
Send:18:55:24.760: N2331 G1 X1.15 Y0.53 F6000
Mesg:18:55:28.762: Warning: Communication timeout - resetting communication buffer.
Mesg:18:55:28.762: Connection status: Buffered:31, Manual Commands: 1, Job Commands: 0
Mesg:18:55:28.762: Buffer used:31 Enforced free byte:0 lines stored:1
Send:18:55:28.762: N2332 G1 X298.46 Y0.53 F6000
Mesg:18:55:32.765: Warning: Communication timeout - resetting communication buffer.
Mesg:18:55:32.765: Connection status: Buffered:33, Manual Commands: 1, Job Commands: 0
Mesg:18:55:32.765: Buffer used:33 Enforced free byte:0 lines stored:1
Send:18:55:32.765: N2333 G1 X1.92 Y2.45 F6000
Mesg:18:55:36.771: Warning: Communication timeout - resetting communication buffer.
Mesg:18:55:36.771: Connection status: Buffered:31, Manual Commands: 1, Job Commands: 0
Mesg:18:55:36.771: Buffer used:31 Enforced free byte:0 lines stored:1
Mesg:18:55:36.771: Warning: Too many timeouts without response - disabling timeout message!
Mesg:18:55:36.771: Advice: If communication does not recover try adding usb reconnect on timeout in printer settings!
Mesg:18:55:36.771: This helps in case it is the serial driver that hangs.
Send:18:55:36.772: N2334 G1 X4.22 Y2.83 F6000
Mesg:18:55:54.858: Connection closed by os.
Mesg:18:58:23.464: Dtr: true Rts: true
Mesg:18:58:23.465: Connection started
Mesg:18:58:23.466: Dtr: false Rts: false
Mesg:18:58:23.486: Dtr: true Rts: true
Recv:18:58:26.496: Send init commands because we had no signal from a reset, assuming reset not available.
Send:18:58:26.496: N1 M110
Recv:18:58:26.500: Connection verified by:ok
Recv:18:58:26.500: ok
Send:18:58:26.508: N3 M115 ; Get firmware capabilities and info
You just wrote
Yes, i can't see in console that the temperature incorrect.
incorrect is a problem. Also jumping temperatures are a problem. And until you do not say the error screen came only once on display I have to assume it is your problem. At the beginning it works most of the time ok and only randomly you get errors.
As a test you could try printing in dry run mode, so heaters/extrusion are not used and should not trigger an error (I hope since we are not heating that it does not matter if reported defect).
incorrect is a problem. Also jumping temperatures are a problem. And until you do not say the error screen came only once on display I have to assume it is your problem. At the beginning it works most of the time ok and only randomly you get errors.
I mean that i NOT see some problem.
incorrect is a problem. Also jumping temperatures are a problem. And until you do not say the error screen came only once on display I have to assume it is your problem. At the beginning it works most of the time ok and only randomly you get errors.
I mean that i NOT see some problem.
Now i just moove hotend and i have the error.
Hm. It is the error, but why?: Recv:19:10:12.307: T:41.13 /0.00 B:38.79 /0.00 @:0 B@:0 Send:19:10:12.471: N22 G1 X0.00 F6000 Recv:19:10:12.472: ok Recv:19:10:13.307: T:47.25 /0.00 B:38.88 /0.00 @:0 B@:0
Recv:19:09:41.267: FIRMWARE_NAME:Marlin 2.0.8 (May 4 2021 14:14:32) SOURCE_CODE_URL:github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:ZAV big + M2.0.x_bugfix EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
Recv:19:09:41.268: Cap:SERIAL_XON_XOFF:0
Recv:19:09:41.268: Cap:BINARY_FILE_TRANSFER:0
Recv:19:09:41.268: Cap:EEPROM:1
Recv:19:09:41.268: Cap:VOLUMETRIC:1
Recv:19:09:41.269: Cap:AUTOREPORT_TEMP:1
Recv:19:09:41.269: Cap:PROGRESS:0
Recv:19:09:41.269: Cap:PRINT_JOB:1
Recv:19:09:41.269: Cap:AUTOLEVEL:0
Recv:19:09:41.270: Cap:RUNOUT:0
Recv:19:09:41.270: Cap:Z_PROBE:0
Recv:19:09:41.270: Cap:LEVELING_DATA:0
Recv:19:09:41.270: Cap:BUILD_PERCENT:0
Recv:19:09:41.270: Cap:SOFTWARE_POWER:0
Recv:19:09:41.271: Cap:TOGGLE_LIGHTS:0
Recv:19:09:41.271: Cap:CASE_LIGHT_BRIGHTNESS:0
Recv:19:09:41.271: Cap:EMERGENCY_PARSER:0
Recv:19:09:41.271: Cap:PROMPT_SUPPORT:0
Recv:19:09:41.272: Cap:SDCARD:1
Recv:19:09:41.272: Cap:REPEAT:0
Recv:19:09:41.272: Cap:SD_WRITE:1
Recv:19:09:41.272: Cap:AUTOREPORT_SD_STATUS:0
Recv:19:09:41.272: Cap:LONG_FILENAME:0
Recv:19:09:41.273: Cap:THERMAL_PROTECTION:1
Recv:19:09:41.273: Cap:MOTION_MODES:0
Recv:19:09:41.273: Cap:ARCS:1
Recv:19:09:41.273: Cap:BABYSTEPPING:0
Recv:19:09:41.274: Cap:CHAMBER_TEMPERATURE:0
Recv:19:09:41.274: Cap:COOLER_TEMPERATURE:0
Recv:19:09:41.274: Cap:MEATPACK:0
Recv:19:09:41.274: ok
Send:19:09:41.275: N4 M220 S100 ; Speed multiplier 100%
Recv:19:09:41.276: ok
Send:19:09:41.277: N5 M221 S100 ; Flow multiplyer 100%
Recv:19:09:41.278: ok
Send:19:09:41.278: N6 G92 E0
Recv:19:09:41.280: X:0.00 Y:0.00 Z:490.00 E:0.00 Count A:0 B:0 Z:784000
Recv:19:09:41.280: ok
Send:19:09:41.280: N7 G90
Recv:19:09:41.282: ok
Send:19:09:41.283: N8 M82
Recv:19:09:41.284: ok
Send:19:09:41.284: N9 G21 ; Use mm as unit
Recv:19:09:41.286: ok
Send:19:09:41.286: N10 M114
Recv:19:09:41.287: X:0.00 Y:0.00 Z:490.00 E:0.00 Count A:0 B:0 Z:784000
Recv:19:09:41.288: ok
Send:19:09:41.288: @getip
Send:19:09:41.292: N11 M105
Recv:19:09:41.298: ok T:42.00 /0.00 B:39.31 /0.00 @:0 B@:0
Send:19:09:41.299: N12 M155 S1
Recv:19:09:41.301: ok
Send:19:09:41.301: M117 192.168.89.4:3344
Recv:19:09:41.302: ok
Recv:19:09:43.306: T:41.94 /0.00 B:39.22 /0.00 @:0 B@:0 (2)
Recv:19:09:44.306: T:41.88 /0.00 B:39.22 /0.00 @:0 B@:0
Recv:19:09:45.306: T:41.75 /0.00 B:39.22 /0.00 @:0 B@:0
Recv:19:09:46.305: T:41.81 /0.00 B:39.22 /0.00 @:0 B@:0
Recv:19:09:48.305: T:41.81 /0.00 B:39.14 /0.00 @:0 B@:0 (2)
Recv:19:09:50.305: T:41.75 /0.00 B:39.14 /0.00 @:0 B@:0 (2)
Recv:19:09:51.305: T:41.69 /0.00 B:39.14 /0.00 @:0 B@:0
Recv:19:09:52.106: Slow command added:G28 Y0
Send:19:09:52.106: N13 G28 Y0
Recv:19:09:52.306: T:41.69 /0.00 B:39.14 /0.00 @:0 B@:0
Recv:19:09:52.766: X:0.00 Y:0.00 Z:490.00 E:0.00 Count A:0 B:0 Z:784000
Recv:19:09:52.766: ok
Send:19:09:52.767: N14 M114
Recv:19:09:52.769: X:0.00 Y:0.00 Z:490.00 E:0.00 Count A:0 B:0 Z:784000
Recv:19:09:52.769: ok
Send:19:09:53.245: @getip
Send:19:09:53.250: M117 192.168.89.4:3344
Recv:19:09:53.252: ok
Recv:19:09:53.306: T:41.63 /0.00 B:39.14 /0.00 @:0 B@:0
Recv:19:09:54.307: T:41.69 /0.00 B:39.05 /0.00 @:0 B@:0
Recv:19:09:54.590: Slow command added:G28 X0
Send:19:09:54.590: N15 G28 X0
Recv:19:09:55.249: X:0.00 Y:0.00 Z:490.00 E:0.00 Count A:0 B:0 Z:784000
Recv:19:09:55.249: ok
Send:19:09:55.250: N16 M114
Recv:19:09:55.251: X:0.00 Y:0.00 Z:490.00 E:0.00 Count A:0 B:0 Z:784000
Recv:19:09:55.251: ok
Recv:19:09:55.306: T:41.63 /0.00 B:39.14 /0.00 @:0 B@:0
Recv:19:09:56.306: T:41.63 /0.00 B:39.05 /0.00 @:0 B@:0
Recv:19:09:57.306: T:41.56 /0.00 B:38.97 /0.00 @:0 B@:0
Recv:19:09:58.306: T:41.50 /0.00 B:38.97 /0.00 @:0 B@:0
Recv:19:09:58.735: Slow command added:G28 X0
Send:19:09:58.735: N17 G28 X0
Recv:19:09:59.306: T:41.50 /0.00 B:38.97 /0.00 @:0 B@:0
Recv:19:09:59.381: X:0.00 Y:0.00 Z:490.00 E:0.00 Count A:0 B:0 Z:784000
Recv:19:09:59.381: ok
Send:19:09:59.382: N18 M114
Recv:19:09:59.383: X:0.00 Y:0.00 Z:490.00 E:0.00 Count A:0 B:0 Z:784000
Recv:19:09:59.383: ok
Recv:19:10:00.306: T:41.50 /0.00 B:38.97 /0.00 @:0 B@:0
Recv:19:10:02.307: T:41.44 /0.00 B:38.97 /0.00 @:0 B@:0 (2)
Recv:19:10:03.307: T:41.38 /0.00 B:39.05 /0.00 @:0 B@:0
Send:19:10:03.803: N19 G1 Y297.00 F6000
Recv:19:10:03.805: ok
Recv:19:10:04.307: T:42.56 /0.00 B:38.97 /0.00 @:0 B@:0
Recv:19:10:06.306: T:41.38 /0.00 B:38.97 /0.00 @:0 B@:0 (2)
Recv:19:10:07.307: T:41.25 /0.00 B:38.88 /0.00 @:0 B@:0
Send:19:10:07.864: N20 G1 X294.00 F6000
Recv:19:10:07.866: ok
Recv:19:10:08.307: T:41.25 /0.00 B:38.97 /0.00 @:0 B@:0
Recv:19:10:09.307: T:41.25 /0.00 B:38.88 /0.00 @:0 B@:0
Send:19:10:10.198: N21 G1 Y0.00 F6000
Recv:19:10:10.201: ok
Recv:19:10:10.306: T:41.19 /0.00 B:38.97 /0.00 @:0 B@:0
Recv:19:10:11.307: T:41.13 /0.00 B:38.88 /0.00 @:0 B@:0
Recv:19:10:12.307: T:41.13 /0.00 B:38.79 /0.00 @:0 B@:0
Send:19:10:12.471: N22 G1 X0.00 F6000
Recv:19:10:12.472: ok
Recv:19:10:13.307: T:47.25 /0.00 B:38.88 /0.00 @:0 B@:0
Send:19:10:13.601: N23 G1 Y300.00 F6000
Mesg:19:10:44.958: Connection closed by os.
Mesg:19:14:25.719: Dtr: true Rts: true
Mesg:19:14:25.720: Connection started
Mesg:19:14:25.721: Dtr: false Rts: false
Mesg:19:14:25.741: Dtr: true Rts: true
Recv:19:14:28.747: Send init commands because we had no signal from a reset, assuming reset not available.
Send:19:14:28.747: N1 M110
Recv:19:14:28.749: Connection verified by:ok
Recv:19:14:28.750: ok
Send:19:14:28.750: N2 M105
Recv:19:14:28.756: ok T:36.81 /0.00 B:37.16 /0.00 @:0 B@:0
Repeat it:
Send:19:23:33.120: N17 G1 Y300.00 F6000
Recv:19:23:33.123: ok
Recv:19:23:34.381: T:30.26 /0.00 B:33.36 /0.00 @:0 B@:0 (2)
Send:19:23:34.555: N18 G1 X300.00 F6000
Recv:19:23:34.556: ok
Recv:19:23:35.381: T:30.26 /0.00 B:33.28 /0.00 @:0 B@:0
Send:19:23:36.110: N19 G1 Y0.00 F6000
Recv:19:23:36.112: ok
Recv:19:23:36.382: T:30.43 /0.00 B:33.36 /0.00 @:0 B@:0
Recv:19:23:37.381: T:30.34 /0.00 B:33.36 /0.00 @:0 B@:0
Recv:19:23:39.381: T:30.26 /0.00 B:33.36 /0.00 @:0 B@:0 (2)
Recv:19:23:40.382: T:30.17 /0.00 B:33.28 /0.00 @:0 B@:0
Send:19:23:40.585: N20 G1 X0.00 F6000
Recv:19:23:40.587: ok
Recv:19:23:41.381: T:30.26 /0.00 B:33.36 /0.00 @:0 B@:0
Send:19:23:41.796: N21 G1 Y300.00 F6000
Mesg:19:24:13.144: Connection closed by os.
Mesg:19:26:41.725: Dtr: true Rts: true
Mesg:19:26:41.726: Connection started
Mesg:19:26:41.727: Dtr: false Rts: false
Mesg:19:26:41.747: Dtr: true Rts: true
Recv:19:26:44.747: Send init commands because we had no signal from a reset, assuming reset not available.
Posting logs only makes sense if you describe what you did and what happened. Otherwise there is no new information.
Posting logs only makes sense if you describe what you did and what happened. Otherwise there is no new information.
I repeat the same action - I go along the edge of the workspace after it i lose the control and disconnected to the printer after ~ 3 circles.
Still looks like errors in low level serial communication. So until the issue is solved you should not upgrade to 2.0.8 at this time.
Current marlin doesn't support hosts sending multiples commands at time, even if there's buffer space available.
It's possible that the refactor by @X-Ryl669 missed some important detail of the existing protocol — similar to the "ok" in flush-and-resend that we missed. We should continue to compare the flow and handshaking between 2.0.7.2 and 2.0.8 to locate the difference. It might be a logical error, or it might be a matter of timing, or something else…. We won't know until we've followed up and put the rest of the required work into the refactor to make sure it's 100% worthy and respectable.
@userosos — This is Marlin from January 28 just before the serial refactor: https://github.com/thinkyhead/Marlin/archive/c929fb52dd5ed9b265f93e3df4b69ac8ea581735.zip
If this version works for you and is able to handle Repetier's command output then we will only need to look at changes after that date.
I don't see any output from HOST_KEEPALIVE_FEATURE
in the logs. But it looks like you do have it enabled. Can you try sending M113 S2
before doing a test with Marlin 2.0.8 to see if the host is able to stay connected during a lengthy circular move, as you did in your earlier test?
Hmm, well I do see it once… echo:busy: processing
. I suppose that Repetier could just be hiding this from you with the default log filter.
ok and busy use the same filter. Autoreport temperature is also handled by ACK filter, but the temperature filter could still hide it if enabled. So the fact is that when his problem happens no data at all is received; also OS keeps connection open.
When I look into this for my forced case and what @userosos mentioned at least once above when he had display connected:
void Temperature::_temp_error(const heater_id_t heater_id, PGM_P const serial_msg, PGM_P const lcd_msg) {
static uint8_t killed = 0;
if (IsRunning() && TERN1(BOGUS_TEMPERATURE_GRACE_PERIOD, killed == 2)) {
SERIAL_ERROR_START();
serialprintPGM(serial_msg);
SERIAL_ECHOPGM(STR_STOPPED_HEATER);
if (heater_id >= 0)
SERIAL_ECHO((int)heater_id);
else if (TERN0(HAS_HEATED_CHAMBER, heater_id == H_CHAMBER))
SERIAL_ECHOPGM(STR_HEATER_CHAMBER);
else
SERIAL_ECHOPGM(STR_HEATER_BED);
SERIAL_EOL();
}
disable_all_heaters(); // always disable (even for bogus temp)
#if BOGUS_TEMPERATURE_GRACE_PERIOD
const millis_t ms = millis();
static millis_t expire_ms;
switch (killed) {
case 0:
expire_ms = ms + BOGUS_TEMPERATURE_GRACE_PERIOD;
++killed;
break;
case 1:
if (ELAPSED(ms, expire_ms)) ++killed;
break;
case 2:
loud_kill(lcd_msg, heater_id);
++killed;
break;
}
#elif defined(BOGUS_TEMPERATURE_GRACE_PERIOD)
UNUSED(killed);
#else
if (!killed) { killed = 1; loud_kill(lcd_msg, heater_id); }
#endif
}
void Temperature::max_temp_error(const heater_id_t heater_id) {
#if ENABLED(DWIN_CREALITY_LCD) && (HAS_HOTEND || HAS_HEATED_BED)
DWIN_Popup_Temperature(1);
#endif
_temp_error(heater_id, PSTR(STR_T_MAXTEMP), GET_TEXT(MSG_ERR_MAXTEMP));
}
Temperature error results in a kill which stops communication, what I think is happening. The question is (at least in the case I tested) why is there no message. There is some condition to write a message but IsRunning might not be true - no idea why it is important. I see minkill has a wait
void minkill(const bool steppers_off/*=false*/) {
// Wait a short time (allows messages to get out before shutting down.
for (int i = 1000; i--;) DELAY_US(600);
cli(); // Stop interrupts
before going into endless loop so if I see nothing I assume it really was no message send.
I don't see any output from
HOST_KEEPALIVE_FEATURE
in the logs. But it looks like you do have it enabled. Can you try sendingM113 S2
before doing a test with Marlin 2.0.8 to see if the host is able to stay connected during a lengthy circular move, as you did in your earlier test?
@userosos — This is Marlin from January 28 just before the serial refactor: https://github.com/thinkyhead/Marlin/archive/c929fb52dd5ed9b265f93e3df4b69ac8ea581735.zip
If this version works for you and is able to handle Repetier's command output then we will only need to look at changes after that date.
Thx! Will tests it version but i saw the error on 2.0.5.3 version (for the first time )
Please also change in in temperature.cpp
void Temperature::_temp_error(const heater_id_t heater_id, PGM_P const serial_msg, PGM_P const lcd_msg) {
static uint8_t killed = 0;
if (IsRunning() && TERN1(BOGUS_TEMPERATURE_GRACE_PERIOD, killed == 2)) {
into
void Temperature::_temp_error(const heater_id_t heater_id, PGM_P const serial_msg, PGM_P const lcd_msg) {
static uint8_t killed = 0;
if (true) {
just to see if we get the messages when it happens. For me it is line 805 but may vary in your commit.
Please also change in in temperature.cpp
void Temperature::_temp_error(const heater_id_t heater_id, PGM_P const serial_msg, PGM_P const lcd_msg) { static uint8_t killed = 0; if (IsRunning() && TERN1(BOGUS_TEMPERATURE_GRACE_PERIOD, killed == 2)) {
into
void Temperature::_temp_error(const heater_id_t heater_id, PGM_P const serial_msg, PGM_P const lcd_msg) { static uint8_t killed = 0; if (true) {
just to see if we get the messages when it happens. For me it is line 805 but may vary in your commit.
In the version or in 2.0.8?
@userosos — This is Marlin from January 28 just before the serial refactor: https://github.com/thinkyhead/Marlin/archive/c929fb52dd5ed9b265f93e3df4b69ac8ea581735.zip
In the one you are testing. Does not matter.
I just saw in MarlinCore.cpp also
void kill(PGM_P const lcd_error/*=nullptr*/, PGM_P const lcd_component/*=nullptr*/, const bool steppers_off/*=false*/) {
thermalManager.disable_all_heaters();
TERN_(HAS_CUTTER, cutter.kill()); // Full cutter shutdown including ISR control
SERIAL_ERROR_MSG(STR_ERR_KILLED);
Which should send
#define STR_ERR_KILLED "Printer halted. kill() called!"
on a kill. Really strange. With the delay to send it it should have appeared on server.
Do you have the display connected again? Did it show anything on the stop?
Do you have the display connected again? Did it show anything on the stop?
No. I disconnected the display and commented it (serial 2nd and sdcard+LCD).
From the image it does not require serial 2nd so leave that, but would be good to have it on again to see if it shows informations we do not see on serial in error case.
To jump into the band wagon, you can actually send more than a command in the serial link, but only one is processed at a time. Recently, we increased the SERIAL_RX_BUFFER size so it allows a larger "elastic" buffer. However, there's a catch here: if you send too much data and you overflow the serial's RX buffer, these data are lost and you have no feedback about it (unless, as you said, you have hardware flow control). So as a safe rule, you should avoid sending multiple command. As an less safe rule, you can send multiple command, but you must:
The issue here does not seem related to the serial link (it's a symptom, not the cause), but to a change in the error reporting behavior. There multiple possible causes that the board is failing to send the error message, and one of them is that the watchdog triggers before the serial TX buffer is flushed, or that interrupt are disabled so that no progress can be done with serial TX flushing and so on. Probably a unsafe test to do is to do that:
void kill(PGM_P const lcd_error/*=nullptr*/, PGM_P const lcd_component/*=nullptr*/, const bool steppers_off/*=false*/) {
SERIAL_ERROR_MSG(STR_ERR_KILLED);
delay(600); // or SERIAL_FLUSH();
thermalManager.disable_all_heaters();
TERN_(HAS_CUTTER, cutter.kill()); // Full cutter shutdown including ISR control
which should flush the serial before calling the real kill
code
From the image it does not require serial 2nd so leave that, but would be good to have it on again to see if it shows informations we do not see on serial in error case.
Ok. But now do it all remotely, on the Internet, as soon as I will connect the display on site.
@X-Ryl669
As an less safe rule, you can send multiple command, but you must:
Query the serial buffer size first Monitor how many data is in the buffer yourself by counting the byte sends and subtracting the bytes acknowledged.
That is exactly what we always did. User has to enter the buffer size. Newer Repetier-Server versions even have a test loop to test different sizes and check if errors happen.
At least on my test skr1.3 watchdog is not triggering and I need to actively reset it to get it back. Will later try a newer version so can also play around a bit. Maybe even add a command to force a kill so I can test just if kill sends a message.
Please also change in in temperature.cpp … into … just to see if we get the messages when it happens. For me it is line 805 but may vary in your commit.
I replaced it in the version https://github.com/MarlinFirmware/Marlin/archive/refs/heads/2.0.x.zip and it work more good. I can do ~ 11 repeats before the error.
I want write what i do: connected(1).log
Maybe even add a command to force a kill so I can test just if kill sends a message.
Please take a look at Marlin/src/gcode/gcode_d.cpp case 100 for an example code to do that (you need MARLIN_DEV_MODE
)
Adding in GCode.cpp
case 1112:
SERIAL_ECHOLN(PSTR("Killing shortly"));
delay(600);
kill(PSTR("Manually killed"),PSTR("Manually killed"));
break;
Send:11:14:04.897: N15 M1112
Recv:11:14:04.897: Killing shortly
Mesg:11:14:05.503: Firmware stopped! You can only send host and shell commands until you hit emergency stop or restart the printer. Eventually running print is stopped.
Mesg:11:14:05.503: Error:Printer halted. kill() called!
So that gives the correct and expected message on serial. Sending M104 S200 without heaters also creates the correct message:
Send:11:16:14.627: N13 M104 S200
Recv:11:16:14.628: ok
Recv:11:16:15.768: T:-15.00 /200.00 B:-15.00 /0.00 @:0 B@:0 (2)
Send:11:16:16.082: @getip
Send:11:16:16.087: M117 192.168.1.34:8080
Recv:11:16:16.088: ok
Recv:11:16:33.769: T:-15.00 /200.00 B:-15.00 /0.00 @:0 B@:0 (18)
Recv:11:16:34.638: Error:Heating failed, system stopped! Heater_ID: 0
Mesg:11:16:36.760: Firmware stopped! You can only send host and shell commands until you hit emergency stop or restart the printer. Eventually running print is stopped.
Mesg:11:16:36.760: Error:Printer halted. kill() called!
This is with the latest version on github and the sample config for the E16 SKR. I noticed that the serial device name under mac os had changed with the upload, so not sure if that explains different behaviour or if it is different config. Last version was from december 2020, but no idea which config I used back then.
@repetier:
Recv:12:10:27.843: T:23.88 /0.00 B:23.63 /0.00 @:0 B@:0 (3)
Mesg:12:10:28.823: Warning: Communication timeout - resetting communication buffer.
The communication timeout seems very short here (1 second ?) Is it expected ?
@userosos On your first picture, the screen is garbled. Could it be possible the printer has crashed ? If so, can you enable POSTMORTEM_DEBUGGING
to see if you get a backtrace on the serial output ?
@userosos On your first picture, the screen is garbled. Could it be possible the printer has crashed ? If so, can you enable
POSTMORTEM_DEBUGGING
to see if you get a backtrace on the serial output ?
Yesterday, during a test, a situation occurred where the extruder was hitting the edge.
Yes, i can uncomment #define POSTMORTEM_DEBUGGING. What next? Repeat the test?
I moved the extruder around the corners of the work area from repetier-server:
Adding in GCode.cpp case 1112: SERIAL_ECHOLN(PSTR("Killing shortly")); delay(600); kill(PSTR("Manually killed"),PSTR("Manually killed")); break;
The pic correct?
Timeout seems to be 8 seconds for @userosos but that it is settable. Timeout is from last command where we expect a response, autoreported temperatures do not count here.
Send:12:10:20.818: M117 192.168.89.4:3344
Recv:12:10:20.820: ok
Recv:12:10:23.842: T:23.88 /0.00 B:23.63 /0.00 @:0 B@:0 (4)
Recv:12:10:24.842: T:23.75 /0.00 B:23.63 /0.00 @:0 B@:0
Recv:12:10:27.843: T:23.88 /0.00 B:23.63 /0.00 @:0 B@:0 (3)
Mesg:12:10:28.823: Warning: Communication timeout - resetting communication buffer.
Looks more like 8 seconds.
@userosos Not sure position is correct, the case ends at line 1021 in my version. But try M1112 in server and if you see at least the first message and no unknown command position is ok. I had added it ihere:
But as long as it is inside the case it is ok.
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:
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
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