i have bad news... the printer destroyed its hotend, i have to print a sparepart on the other printer (which is also connected to the server)
its job now is at 60% when it started to stutter... it is the printer which never had a issue, now it does the same than the other.
500 ms pause between every move, buffer not empty.
btw there are no connection issues in the log, no resend etc. it just sends the commands to slow, buffer is around 80 all the time and it stutters.
edit: i noticed somthing, @debugcon tells me the job commands, if 5000 is the max then 2500 woukd be 50%. always if the command count falls below 2500 it stutters. sometimes its more than 2500 then it prints normal.
i can remember on some setting somewhere, which said "reduce speed if buffer is below 50%" i belief in the advanced setting from marlin.
this brings up two questions,
why does it not keep the buffer full?
why does it keep it full until some random point, and start then to let it fall below 50%?
edit2: found something in the firmware
// minimum time in microseconds that a movement needs to take if the buffer is emptied.
the server stopped the printer again and i wasted 7 print hours.... i don´t know what it is but with such an issue, on both printers, i cannot use the server. sooner or later it beginns to stutter or it stops. sometimes i print gets through without problems but the most jobs are a waste of time and money.
You are mixing buffers. The 5000 buffer are the lines buffered inside the server. At the end of print this will go down to 0.
The minsegment time is ok. Still only 20ms which is less then your wait between commands.
It is bit of a problem that marlin does not support debugging communication as easy as repetier. I understand you do not want to waste print and I wouldn't either. I would just let it run in dry run mode which means without printing. But maybe you could with pla temperature 0. Then marlin prevents cold extrusion but I guess it will complain every line then. Better would be to additionally replace all E by a A i guess.
I have compiled a new server version for testing that now logs with ms resolution, so we can now see if there is a too long delay from ok till sending next command on host side or if it is firmware taking so long to send ok. Use @explaincom to see the details while stuttering.
The new version can enable/disable logging and it is disabled by default. So you need to first enable it in printer menu -> logs (where you download the logs as well).
meanwhile i installed the server on a old pc, and let it run instead of the PI....AND.... i does work really well and finished its first 10 h print without problems.
it must be something with raspian or the PI. so i wanted to install arch for a try but it is not compatible for the PI 2.
i also repaired the 2nd printer. i gave it a new x end part, new extruder and new hotend. i have to wait for new carbon print surface which will be shipped next week, then i can print with both at the same time.
carbon is probably the best print surface for PLA and ABS.
after this job here got finished i can try your new server and do some tests.
ok i just finished a print with the new server. i installed it on the pi 2.
it was a 2 h job and the printer did not stutter or stop. i have to do more tests, this could just be luck, or did you do anything to fix something?
if you mean the x server on raspbian, no i just boot it headless and it does not make any difference if the x server runs or not, at least did it stutter even in the commandline without x server running.
it begun to stutter from the first line, the skirt. i saw it and executed both commands. the printer then stopped somewhere, and after it did not move for some minutes, i aborted the job.
and here is a log after i disabled/enabled the printer in the interface from the server, after this it worked again.
but i had to abort because of wrong Z level. just to show how it looks when it prints normal.
i wanted to produce some additional logs and tried the same job again, this time it came to a stop because the server had a hang.
lost connection in the webinterface while the pi remained reachable via ssh.
after i rebooted the pi the server worked again.
edit: something strange happened,
the server running on my old pc (windows 7) finished 9 jobs without any issues, but now i put the usb cable from port 3 to port 4, started a print and it immediately stuttered.
i put the cable in port 3 again and it prints, this is a 6 hour job, lets see how it goes..
ok i did a lot of testing now and its still the same... both printers are working great with any host software except the repetier server, with the server its a gamble. sometimes a printer finishes more jobs in a row, sometimes not...but the printer always have the stutter or stop issues sooner or later, regardless what i try or do.
they complete 2 or 3 long term jobs, then they stutter on a 1 hour job. or they print 9 hours and stutter in the last 30 minutes... it seems to be random, or if something with the server happens.
the issues are on both servers, the one installed on the pi 2 and the one installed on my pc. this makes no real difference.
it helps to reconnect them, but not always, sometimes it stutters on every job, on the next day the printer works without any changes, even when the server and printer was not shutdown or disconnected, just some hours between the jobs changes its behaviour.
it also is not important if only one printer is connected or both, the port also does not matter.... every single idea i got what it could trigger the stutter is not really reproducable, its always mixed with some randomness.
but it seems if a printer has currently a stutter-state... it will stutter on 10 jobs in a row until i reconnect it, then i cast the dices new and this generates new behaviour, like 2 or 3 working jobs until it stutters again. but sometimes the reconnect leads to the stuttery behaviour and i have to reconnect it until i reach a "not so stuttery state" or a "stutter in the next 2-10 jobs but not on this current job" state.
i hope you found something to fix this, because it makes this software useless.... very sad
Yes, we found the reason. We are currently working on host 1.5.4 and server 0.60.4 coming today which solves the problem. The reason is a communication error where the returned "ok" is not detected due to missing return or o or k sign. Then with bad luck it manages to send a M105 every second accompanied with one command which is your stuttering. You will still get a pause of connection timeout seconds after the update but then it continues again normally. In ping pong mode this should also happen now but then you loose the advantage of the buffers.
So please check tomorrow for updates and then it should be solved.
There were some others with the same problems in an other thread who helped me find the problem.
Original problem is still a hardware issue namely missing chars in return to a command. That breaks the protocol and caused the problem. The new solution now detects this problem and solves it to continue.
You might want to change communication timeout to a lower value or switch to newer marlin versions that send line numbers in ok message (1.0.3 I think has it). Then the problem can even be solved without any pause.
i tried the new server version, and it came to its first "stop", the timeout setting is set to 3 seconds so it continued soon after the stop but why does this not occure on other platforms?
lets say octoprint (which works fine but lacks the ability to run multiple printers) or pronterface even with repetier host it does not happen... why?
and: looks like the buffer in the new version is almost always at 0 or close to 0.
btw: the repetier-host setup installs the 0.60.3 server
currently, i have a job which lets the printer always stop at the same position, in every layer it has con problems at the same point and then it stops for some seconds and continues.
since the update of the server, its buffer is always empty.... in combination with the issue above, this leads to many short stops = blobs
why does it not fill the buffer? the 0.60.3 version did this.
both printers do not stop any more, but now they do a "mistake" on every 2nd print... like do a 50 cm retract... or miss the half infill of a layer... proceeding to the next... or instead of a circle, they print a square... in the middle of a job.
i mean... WTF?
this still only appears on the repetier-server, just there.
For the combination we test it works witout any of these problems. Can you tell which combination you are using? Server version, Pi version, os, firmware and version, wlan or eth0 connected? X server running?
Ok, if it happens also on a pc i do not think it is the device and with octoprint working I also assume the printer is ok. So it might be the configuration of the printer (could you send me your xml config file you are using). Also a log with the errors would be helpful analysing what is going on. Might be some incompatibility with some marlin answers you are getting causing this.
same problem... the print stops after 8h and at the second trial the print stops on the same point. Connection status: Buffered:0 manualCommands: 1 jobCommands: 5000 The g-file to print is 33MB big. Maby too big? I`m printing with Print-Server 0.60.3, free Disk Space 10GB with a rpi B. Most files are smaler than 20MB and they always getting perfekt. I`ve no other reason for that.
First update to latest server version. It is just one click and already solves all known issues for the release time, some were print relevant.
File size does not matter for the server. Could even be 4gb if it fits on your card. The server always only reads the next 5000 lines into ram to allow any file size.
Since 0.60.4 fixes hangs of this kind especially if temperature still updates, I would suggest first updating before doing further tests.
this thread is full of logs from both of my printers... i spent weeks here, figuring the problem out... i don´t want to do this again.
the problem is still always the same: its connection error based.
sometimes it did some really strange moves.. until a endstop was hit, or shit like this.
the only thing, the 0.60.4 fixed, was IF it came to a stop, the printer does continue after the timeout time... but this is not a solution because the main problem still persists -> connection errors all the time, sometimes at the first layer, sometimes after 6-9 hours of printing... filament gets wasted.
and sometimes it did not continue after a stop...
i tried out really every possible setting in the server interface, this is not the problem...
octopi did not had one single con error.. not one in more than 20 jobs now, with exactly the same hardware.
(and if it had one, it did something to avoid a impact on the print job)
maybe i will try one last thing:
im bulding a new, big printer, it will get a smoothie board... could be interesting if the problem is there the same or not.
First buffer should be 127 not 128 or you get errors.
Then you should log a print and watch where you get hangs. This normally gives a good hint. From your image I see temperature drops to 0 that could be from transfer errors. Also if you get timeout second stalls it is from communication errors where the returned "ok" is not received as ok but with modifications. Often a different baud rate helps to reduce errors.
I've had the same issue. Twice with about half an hour in between. It got so bad that after it stopped, the layers got misaligned and it continued printing about half a centimeter to the right. I used repetier directly connected and that has worked fine for many prints.
I have to investigate if it's because of the raspberry pi, or if it's a problem in the server itself. I'm using the rpi 3, and it has over 20 gb of free space.
Comments
same problem... the print stops after 8h and at the second trial the print stops on the same point.
Connection status: Buffered:0 manualCommands: 1 jobCommands: 5000
The g-file to print is 33MB big. Maby too big? I`m printing with Print-Server 0.60.3, free Disk Space 10GB with a rpi B.
Most files are smaler than 20MB and they always getting perfekt. I`ve no other reason for that.