Sounds like timeout from communication problems. Best is of course have a error free communication. In meantime there was some great development regarding better detection of such errors. Marlin and Repetier-Firmware introduced a busy protocol allowing it to reduce timeouts to 3 seconds instead of 40s, so no big blobs appear and no misalignment from crossing blobs (which might be your problem since I don't think printer id execute wrong commands). Host 1.6.2 and server 0.80.0 will be able to understand this and should come soon. Of course you need the matching firmware as well. Currently means dev tree I think.
Server version: Repetier server 0.75.1 Printer electronics:Megatronics V3.1 and Leapfrog Creatr (Both ATmega-Ramps compatible) Firmware: Marlin 1.1.0-Rc2 and most recent Bugfix Baudrate: 250000
Tried Raspberry A and B and an Intel D510 board. All hardware and OS versions give the same random stutter. Ping-pong improves a little bit but still not usable. For now printing with a PC connected direct to the printer and then no problems occur.
I am not using auto bed leveling but would like to use the server because i run 5 printers in total and needing 5 PC's is going to far for me.
You need to check the log to see what happens during stutter. I have found that some boards receive under certain timings the data they send back to server mixed with incoming line. This causes the communication errors and requires resend. If such things happen during parts with short lines you get stuttering. I have verified that this behaviour is independend of firmware and host software and os so my guess is usb-serial conversion on arduino. But this problem is hard to tackle as it is completely random and only if firmware returns bigger chunk of data like temperatures while receiving a usb packet at the same time. Could also be normal com error or something else. As I said without logs it's only guessing and even with it is some part guessing.
Server would also run on windows, which is faster and has different timings which might be why it does not happen here, also I get faster communication with Linux.
Depending on extra functions used, a Pi 1 might be a bit underpowered as all runs on a single cpu processor while pi 2/3 have 4. Especially rendering of images might cause also some stutter here if communication is error free and just gets slowed down.
It also happens on W7 home premium running on a quad core with 4Gb ram and a 180Gb SSD. Only one printer running and nothing else is done on the server system.
Logs give no clues and switching back to repetier host on the same hardware solves the problem.
I dare to say that there is a 'tiny' problem in the server software. For now disabled the whole server and running with repetier host to keep going but would like to use repetier server.
My problem is that I get no stutter, so I can not analyse it myself or fix it. In fact most have not that problem. So would still be great to see a log part where it stutters. Maybe I see things you do not see.
As you see from my last post here I'm still waiting for someone having the problem sending me a log where it happens. As long as I do not know why this happens to someone I can not do anything and it might even be just bad communication or something else outside of servers responsibility. So if you have the problem report the log part around the time where you have stuttering. Include a good part before it and mark the part where it stutters and which firmware you used on printer. Then we might get closer to the problem. I know many users have no issues at all, so that problem really depends on conditions not normally found.
The log shows no errors at all. Perfect communication till the end when it seems to stop.
I recently learned that the pi for some users disconnects the usb connection which of course causes a stop of print.
Have a look at /var/log/syslog around the stop time and look for messages containing usb. If you see a usb with reset or EMI you know that linux disconnected it. I know that the same printer would often not disconnect on windows. May it be a more stable power connection or different handling of usb, who knows what an os does internally.
you may be more correct than you know. Invariably one of the pitfalls of the Pi's are the powering of the devices through USB. Even the USB psu that's official has some voltage droop in some cases potentially causing this issue.
Sadly this means for me I must go back to Windows with a low power solution
Most boards can be modified to be always powered from main power and not over USB. Maybe that would help. I have this for my test setup with pi and also I sometimes see the low power icon I have no connection drops.
Comments
Server version: Repetier server 0.75.1
Printer electronics:Megatronics V3.1 and Leapfrog Creatr (Both ATmega-Ramps compatible)
Firmware: Marlin 1.1.0-Rc2 and most recent Bugfix
Baudrate: 250000
Tried Raspberry A and B and an Intel D510 board.
All hardware and OS versions give the same random stutter.
Ping-pong improves a little bit but still not usable.
For now printing with a PC connected direct to the printer and then no problems occur.
I am not using auto bed leveling but would like to use the server because i run 5 printers in total and needing 5 PC's is going to far for me.
Only one printer running and nothing else is done on the server system.
Logs give no clues and switching back to repetier host on the same hardware solves the problem.
I dare to say that there is a 'tiny' problem in the server software.
For now disabled the whole server and running with repetier host to keep going but would like to use repetier server.
I think this problem is still up to date because I got the same problem with rapsberry pi zero w and repetier server.
As there is no answer from july 2016, I assumed it has been fixed.
Could you, please, share the solution with us?
See log.
https://drive.google.com/drive/folders/1sVFvS897VLzuGhIoolxAxWFAUwtxm9b9?usp=sharing
I recently learned that the pi for some users disconnects the usb connection which of course causes a stop of print.
Have a look at /var/log/syslog around the stop time and look for messages containing usb. If you see a usb with reset or EMI you know that linux disconnected it. I know that the same printer would often not disconnect on windows. May it be a more stable power connection or different handling of usb, who knows what an os does internally.
Sadly this means for me I must go back to Windows with a low power solution