Lots of comm timeouts -- but printing continues seemingly uninterrupted

Hi. I'm suddenly noticing piles of communications errors in the log. I'm unsure when this began, since I haven't been monitoring the log carefully and printing does not *appear* to be affected -- at least not yet. This is using repetier-server on Linux connected to the printer via the same short, shielded USB cable I've been using all along, and a reasonably stable build of repetier dev firmware. These seem to routinely appear every minute or two, though longer gaps without them can occur especially in the early phases of a print. Again, this does not appear to actually be affecting the printer in any obvious way so far -- and perhaps it's been going on for quite some time before I noticed it -- but I'm not getting a warm fuzzy feeling from seeing so many timeouts, and any suggestions would be appreciated. Thanks very much!

Example:

18:22:37.648: Warning: Communication timeout - resetting communication buffer.
18:22:37.648: Connection status: Buffered:49, Manual Commands: 0, Job Commands: 5000
18:22:37.648: Buffer used:49 Enforced free byte:19 lines stored:2
18:22:45.769: Warning: Communication timeout - resetting communication buffer.
18:22:45.769: Connection status: Buffered:61, Manual Commands: 0, Job Commands: 5000
18:22:45.769: Buffer used:61 Enforced free byte:15 lines stored:3
18:22:46.820: Error:Wrong checksum
18:22:46.821: Resend:40190

Comments

  • Hard to say from this short part without ack responses and commands send.

    Errors like wrong checksum are detected fast and fixed on the fly.

    Communication timeout appears if firmware did not respond in time with a "ok". Reasons are:
    1. timeout in server is set too low. If then a move takes longer you get the timeout also it is no timeout.
    2. Missed "ok" from firmware.

    Since we know that errors can occur (also not that frequent normally) we catch them and continue to safe the print. Depending on firmware you can help making the fixes faster so less harm is done to prints.

    Typical things are making the firmware send "wait" and line numbers after "ok". Repetier-Firmware does that by default, in Marlin you can at least enable this I  think in advanced setup. This helps server to detect a missed "ok" and the wait makes it continue fast if it missed too many "ok" in a row.


  • Thanks. I wouldn't have changed that setting when I compiled the firmware, but next time I'll make the log more verbose. How do I increase the timeout in repetier-server? Thanks again!
  • Timeout is set in printer configuration. But only increase it if it was too short. Default is 30 seconds i think. With repetier-firmware and busy protocol activated it can be reduced to 3 seconds as firmware would tell if it takes longer.
  • It turns out that the default (I hadn't changed it) that was pulled into Repetier Server from the printer EEPROM (running my build of version of 1.0.0dev firmware) had the printer timeout set to 3 seconds. I doubled it to 6 seconds, and (for what it's worth) just ran a successful 6 hour print with no errors in the log at all!
  • edited April 2020
    Hello, 
    I believe I have the same issue, but I can't change the default 3 seconds in repetier server.
    In fact I can edit it and save the configuration, but when I autodetect from the firmware it comes back to the 3 second by default... So I assume it is not taken into account...:o(
    Any advice to solve that?

    I would add that I don't find any such parameter in the EPROM parameters list. 
    So where is it saved?

    Thanks in advance.
    Best regards
    John
  • Default is 30 seconds in repetier-server settings, not 3 seconds. Autodetect might change it if it sees the busy capability. Set it only to 3 if firmware supports busy protocol. You see it in console sometimes if ack is enabled. Values should be saved to the server printer config file if you press save. If it does not get saved, there is an error in your configuration settings preventing this.

    There is no matching parameter in eeprom!

    Do you have lot of timeouts? If you can compile firmware your self, add line numbers and wait message if using Marlin firmware. That allows detecting missed "ok" messages on the fly so it does not generate time outs.
  • Hello,
    Thanks a lot for your answer ;o)
    Maybe I am setting up this parameter at the wrong place (?).
    I mean in the printer settings under the «connection» topic.
    I have «Input Buffer Size» then «Ping-pong mode» and «Communication Timout» parameters side by side...
    (I don't know how to post a screenshot here)
    This «Communication Timout» is set to 3 s.
    I can change it to 5 s for example. It stay at 5 seconds but with the «red» circle (doesn't match firmware value).
    If I «save configuration» and «auto detect value from firmware» it comes back to 3s.

    Anyway : set it to 5 s solved my timout problems (or messages...), even if I can't save it.
    Maybe I found a reason for these timeouts : sometime I have long travels to do with low acceleration and low speed. I measured that if this travel time is greater than the «communication timout» I receive a timout message.
    So I have the feeling that the firmware (Repetier) is waiting for the end of a move before to answer, then if the travel time is too long I get a timout.
    30 second would be great, (I never have 30 s single moves...).
    I can adjust it to 30 s, but I hesitate...

    John

  • You can save and it was the right place. Just do not run autodetect afterwards! That overwrites the value.
  • Repetier said:
    You can save and it was the right place. Just do not run autodetect afterwards! That overwrites the value.
    Thanks, I don't «touch» the autodetect afterwards. 
    Now it's ok, I don't have anymore these messages. ;o)
    Kind regards
    John
Sign In or Register to comment.