[Request] Multiply timeout value based on feedrate settings

[sanchosk]

What were you doing?

I was printing long print overnight. It contained long lines that were triggering timeout warning. Later, to have better sleep, I slowed the printer down using feed rate to 50%

What did you expect to happen?

I expected the printer to quiet down and continue printing.

What happened instead?

It printed the infill on current layer, but when it had to print the next layer walls, it timed out. I would expect OctoPrint to multiply the timeout value based on the feedrate percentage - e.g. 50% feedrate would increase the timeout value by a factor of 2. If possible, it would be nice to monitor the G-code, too, to ensure even manual M220 commands would have the same effect - for some reason the feedrate only goes to 50% while I would appreciate 25-30%, too. I would not suggest to go under multiplier of 1 to avoid limitations of print speed from the firmware.

Did the same happen when running OctoPrint in safe mode?

N/A

Version of OctoPrint

OctoPrint 1.4.0.dev808+gb1c46cc9

Operating System running OctoPrint

Linux Description: Raspbian GNU/Linux 9.3 (stretch) Release: 9.3 Codename: stretch

Printer model & used firmware incl. version

Tronxy X5S with RAMPS and TMC2208 drivers

Browser and Version of Browser, Operating System running Browser

Linux, Firefox 58.0.2 64-bit

Link to octoprint.log

N/A

Link to contents of terminal tab or serial.log

https://pastebin.com/nJYA2A0x

Link to contents of Javascript console in the browser

N/A

Screenshot(s)/video(s) showing the problem:

N/A

I have read the FAQ. Yes, I have read the FAQ.

[ntoff]

how long are these moves and how short is your timeout? Maybe provide a sample gcode to test against and also please provide octoprint.log as it contains information about octoprint's environment which may assist in replication of the error.

[sanchosk]

I used the M220 S25 for 25% speed, timeout set to default 40s, sample g-code attached from serial.log. Is it sufficient?

On Fri, 9 Mar 2018, 08:20 ntoff, notifications@github.com wrote:

how long are these moves and how short is your timeout? Maybe provide a sample gcode to test against and also please provide octoprint.log as it contains information about octoprint's environment which may assist in replication of the error.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/foosel/OctoPrint/issues/2469#issuecomment-371733735, or mute the thread https://github.com/notifications/unsubscribe-auth/ACPMYwPUjj_7uSxI1f9HB3A-288-rgnYks5tci02gaJpZM4SjyaR .

[ntoff]

I mean an actual gcode file someone can load into octoprint and press print on. In all the prints I've done, I've never had a G1 movement trigger a timeout, I'm curious to know your movement speed and length of the move. 40 seconds is a LONG time for a print to be moving in a single straight line, how large are your prints?

edit: To clarify why providing the gcode helps, it just means the testers don't have to guess at A) your part size, and B) your slicer settings, or to waste time trying to replicate such long moves manually. If your part is some super secret squirrel thing you don't want out in the wild, that's fine, it just makes it easier to work on an issue if a developer can replicate your setup as close to 100% as possible.

[foosel]

As @ntoff pointed out, please provide all requested information. Without that information this ticket cannot be looked into and will be closed. Thanks.

[sanchosk]

Unfortunately, I deleted the g-code as I re-generated another one again. But I can recreate it in the evening again. The print is quite simple - 230x55mm "box". The problem is it has 5 perimeters, the outside perimeter is printed at 80% speed, print-speed is 40mm/s and the source of the problem might be the printer uses 24 command buffer size - therefore the whole whole outside perimeter commands fit into the buffer and cause timeout. Now I am printing the same with increased timeout to 60s and so far no error.

[foosel]

Your firmware should be using the busy protocol to signal when it's busy processing something and not able to receive but still alive. That was designed specifically to avoid situations like this and should be supported by modern firmware.

There's no way for OctoPrint to retrieve the current flowrate modifier from the firmware (it's a write only value so to speak), so if you change speed on the printer's controller, it goes past OctoPrint anyhow. So this is never going to be a reliable workaround for this issue anyhow. And to be honest, I don't want to add on the fly timeout adjustment based on flow rate values, this is just going to make everything even harder to maintain and it would only be needed for firmware that hasn't been updated to support the busy protocol anyhow, so add unnecessary complexity and maintenance overhead for a situation that will hopefully resolve itself over time.

If someone wants to write a plugin that somehow provides this functionality and maintain it, be my guest, but this is not going to be built into core OctoPrint.

Your actual problem here however doesn't appear to even be what you think it is:

2018-03-09 04:57:53,110 - Send: N133042 G1 X80.711 Y53.933 F4800.000*106
2018-03-09 04:57:59,118 - Communication timeout during an active resend, resending same line again to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.

You are not just running into a timeout, you are running into a timeout during an active resend. So something went severely wrong earlier in the communication here and the timeout might be the least of your problems/a symptom of a larger problem.

[sanchosk]

Here is the G-code. corner 2020_0.2mm 50% 3perim slow_20180309-185651.zip