Some weird bug Im having, any help would be lovely.
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
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
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.
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 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.
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)
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.
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.