›

Some weird bug Im having, any help would be lovely.

CookieHunterCookieHunter
in Repetier-Host
So I wanted to print this item, 2hr print using serial connection and from time to time the machine freezes than I get a "communication timeout - reset send buffer block" after 30 seconds , and it continues the print- now the problem is that it creates longer print times and unwanted spots of extra material.

Now the weird part is that if I press the OK button in manual control, than it does not give me the message, unfreezes and carries on. 
I've tried checking baud rate issues, cable issues, even checked on compatibility because I saw it helped someone else.

Im using windows 10 and repetier host 2.0.5 - latest version at the moment.  

thank you very much

Comments

  • RepetierRepetier
    You have communication errors, so some "ok" are received maybe as "o" or "k". And once you have accumulated enough errors so host things input buffer is full, it will not send anything until the timeout is reached and host can safely assume something is wrong and continues.

    At the current time there are good solutions to this problem. In firmware if you compiled it on your own enable line numbers for ok and sending wait when idle. The first allows detection of missed ok on the fly and the second reduces timeouts to 1 second.
     
  • CookieHunterCookieHunter
    I didnt compile the firmware on my on, so what should I do?

  • RepetierRepetier
    Check if your vendor offers the firmware sources with his settings, then you could do easily. The only way to add these settings is by compiling. 

    Alternatively try other usb cables/ lower baud rate and see if errors go away and reconnect before a new print to free buffers. You could also reduce timeout but that might be a problem if you get too low. Must be longer then the slowest command it does not expect to be slow anyway (like heating, homing). So essentially longer then the slowest move you will ever send. That gives at least faster recovery then now.
  • gok4pagok4pa
    This is only a recent problem.
    I checked all my wires and connections.
    Just changed my usb cable today.
    It has stopped 3 different times on my cut.
    Wasted 3 pieces of wood now.
    Is there anyway to start back from where it aborts?
    The rough cut is 3hr 40 minutes.
    I can get 2 to 2 1/2 hrs in and it aborts on its own.
    Please help.
    My controller is from MPCNC pre installed firmware.
  • gok4pagok4pa
    I was just scrolling through the code at the bottom.
    I found 3 lines in red.
    Error: No Line Number with checksum, Last Line:0
    Error: Line Number is not Last Line Number+1, Last Line: 0
    Resend: 1
    (then it says)
    ok
    Resend: N1 M110*34
    Resend: N2 M115*36
    Resend: N3 M105*36
    Resend: N4 M114*35
    Resend: N5 M111 s6*98
    Resend: N6  T0*60
    N7 M80*28
    ok
    (then it looks like thats where it aborts)
  • RepetierRepetier
    That code looks like the normal start code. At startup it often happens that a command is not received correct and resend is required. After 2:30 hours I expect bigger line numbers.

    As said normal communication errors normally recover and you see it in the log if oyu have logging enabled. Timeout is here the last fence of this.

    The worst case is when the os says it is connected, but does not send data in one or the other direction due to a broken usb stack or something like that. To my knowledge this is normally some electronic problem causing it and maybe a bad driver implementation not detecting this case.
  • CookieHunterCookieHunter
    Repetier said:
    Check if your vendor offers the firmware sources with his settings, then you could do easily. The only way to add these settings is by compiling. 

    Alternatively try other usb cables/ lower baud rate and see if errors go away and reconnect before a new print to free buffers. You could also reduce timeout but that might be a problem if you get too low. Must be longer then the slowest command it does not expect to be slow anyway (like heating, homing). So essentially longer then the slowest move you will ever send. That gives at least faster recovery then now.
    I did as you said and it still happens, what should I do?

  • RepetierRepetier
    So now firmware firmware sends "wait" and line numbers in "ok" response and it still gets timeouts? Or did you change usb cable?

    If the latter was the case you need to use the first solution whcih is the only way to detect error on the fly without longer waits. If you can not do it you can only reduce timeout to continue faster and see if that makes problems. There is a limit if timeout gets too low it may add more timeouts from long running commands assuming your firmware does also not notify about this using busy protocol.
Sign In or Register to comment.