Printing gets slow and choppy after several prints

skutch

After upgrading to v1.5.0, I've noticed, after about 2-3 successful prints, the printer will be printing fine on the next print then it will just start going in these slow, choppy steps, staying at each spot for several seconds, completely destroying the print thereafter. The only way to correct is to close the program then restart. Never had this issue with the previous version. Anyone else see this?

Repetier

Not seen so far. What does the log say when it happens? What are the line numbers? There is a line number reset after a million lines but that should not block communication. Please enable file logging and check that log around the time when it happens to give usable hints.

unltd108

I'm getting same problem. But, I just upgraded to 1.5.0 and this is my first print using since upgrading. I ran print twice, and it gives problem in exact same Layer and same location. It will print fine until it hits the spot, then it takes a second or 2 per each movement of the head. I didn't have log enabled, and will do so. But, the prints were 143 layers and it hangs on layer 8. I use Slic3r. I was printing 1 part and 1 copy of that part. I will try again with no copies, just the part and see what happens.

Will update with results

unltd108

I ran with just the orig - no copy, it went to layer 12 and choked.

I had looked at the PRINTER - JOB STATUS when it choked previously and it was on line 1297xx at layer 8

And I ckd job status with no copy and again it was at line 129700 and something... at layer 12 so it seems to be snagging at around the same line number.

Here is what the log showed me - ah, logs were too long to post, even snippets : was fine until:

> 23:11:17.134 : ok 65535

< 23:11:17.134 : N65541 G1 X37.791 Y28.683 E8.24088 *67

> 23:11:17.138 : ok 0

< 23:11:17.150 : Warning: Missed line detected - correcting buffer usage.

< 23:11:17.150 : N65542 G1 X37.678 Y28.797 E8.2471 *116

> 23:11:17.159 : ok 1

then it started missing lines....

It was sending data fine up until around line 65535 - that is right at 16 bit binary....

< 23:27:01.090 : N131077 G1 X12.483 Y54.649 E20.56228 *78
> 23:27:01.094 : ok 0
> 23:27:01.107 : ok 1
> 23:27:01.123 : ok 2
> 23:27:01.139 : ok 3
> 23:27:01.148 : ok 4
> 23:27:01.164 : ok 5
> 23:27:02.163 : wait
> 23:27:03.168 : wait
> 23:27:04.167 : wait
< 23:27:04.181 : Warning: Seems like we missed a ok, got a wait - continue sending.

I will post again with later log data, as it says my post has too many characters

unltd108

rest of post

< 23:27:04.181 : N131078 M117 ETE 1h 32m 09s *35
< 23:27:04.181 : N131079 M105 *58
< 23:27:04.181 : N131080 G1 X12.369 Y54.763 E20.5685 *121
< 23:27:04.181 : N131081 G1 X11.669 Y54.575 E20.59648 *67
< 23:27:04.181 : N131082 G1 X11.627 Y54.419 E20.60269 *76
< 23:27:04.181 : N131083 G1 X11.868 Y53.521 F12000 *98
> 23:27:04.187 : ok 6
> 23:27:04.249 : ok 7
> 23:27:04.250 : T:192.58 B:70.00 B@:80 @:78
> 23:27:04.250 : ok 8
> 23:27:04.253 : ok 9
> 23:27:04.257 : ok 10
> 23:27:04.257 : ok 11
> 23:27:05.260 : wait

At the end of the log it looks like this:

> 23:37:02.942 : T:151.64 B:47.32 B@:0 @:255
> 23:37:03.940 : wait
> 23:37:04.939 : wait
> 23:37:05.939 : wait
< 23:37:05.999 : N131390 M105 *62
> 23:37:06.001 : ok 318
> 23:37:06.007 : T:154.34 B:47.20 B@:0 @:255
> 23:37:07.004 : wait
> 23:37:08.004 : wait
> 23:37:09.003 : wait
< 23:37:09.058 : N131391 M105 *63
> 23:37:09.061 : ok 319
> 23:37:09.063 : T:156.71 B:47.13 B@:0 @:255
> 23:37:10.0

I have no idea what it all means, what N131391 is, since the job status showed line 129700 something when i stopped print and closed out Repetier. i don't know if those number are to coincide or what.

If this can't be resolved quickly i will need to go back to 1.0.6

Your help will be appreciated

Repetier

Thanks for analysis. The 65536 might be the hint we need. Internally line numbers are wrapped at 65536 so that is a special position. Will analyse code and see what might go wrong there. Quite sure it is a problem with the wrapping.

Repetier

Ok found the problem. Updated host to 1.5.1 where the problem should be fixed. At least I did not get it after the correction.

skutch

Thanks guys, I'll check 1.5.2 out today; I print a lot of stuff each run, so it should be a good test.

unltd108

Well, so far so good. It's zooming past the point where it choked before. But, after installing 1.5.1 I wasn't able to connect to the printer. I rebooted. But, i've never used the Server before, not sure how that is to be set up. I downloaded 1.5.2 when i saw there was another update already, but still couldn't connect to printer. I finally Deactivated the printer from the Server and i was able to get the Host to connect and is now in the process of doing a 4 hour print (at 55mm/s .3mm layer thickness). I will need to read how the server thing is supposed to work, or maybe disable since I really don't think i'll need it.

Repetier

After setting the right port and baudrate it should connect automatically if not disabled. Sometimes autodetect baud rate will not work.

What board/firmware did you use? Since the server has less config options it tries a connection procedure that should work for all boards and firmwares. But that is not an easy task.

unltd108

Actually, the Server connects with the printer, I can control it from the server control panel. But, when the server is connected the Repetier Host won't connect with the printer, so i can't do any printing until i deactivate the printer from the server. Then I can connect from the host.

BTW - I have another issue, I should probably start a new thread?

While the print is printing - I just now accidentally right-clicked in the 3D-view window. As soon as I did the printer STOPPED printing. It is almost 5 hours into a 5.5 hour print. I panicked and started left clicking, right clicking and it started again. Not sure if it started because i hit the mouse keys or it just paused. Since it is so close to finishing up the print, i don't want to take chances and try things until after it completes. But, 14 hours ago I started the same print, got several hours into it and the PC screen had gone to sleep. I hit the mouse to wake it up, and I think i hit the left button accidently then too, the printer stopped. I don't recall what i did, but, i know i tried some things and it didn't revive. The whole program froze - task manager wouldn't even close Repetier, so i had to do a reboot. But, this time I know for sure, just as I hit Right Click the printer stopped, was stopped for a good 2 seconds, after hitting right and left (in a panic) it started again like normal.

When this is done I will do some test runs and see what happens. I am running Windows 8.1 64bit

Repetier

I think you have missed one important part using repetier-host and repetier-server. Since the server connects with the printer you can not use the normal serial connector in printer settings you are used to use. We have written for this a server connector so the host will talk through the server to the printer so you use the servers serial connection. Only in this combination you get the benefits of both. Easy use like you are used to and independent printing spooler that does not hang when the host does like described in your problem.

Regarding your stall problem I think it might be update related. It suddenly wants to update the screen waking it up but 3d model has changed quite a bit since last update. Communication blocks while using main thread for updates so you get a stall for the duration of the update. WIth server this can not happen as the server uses a separate thread for printer communication so the host hang will not disturb - at least in our tests.

unltd108

Ok, I will look into seeing how to use the server. If the Host is to communicate with the Server then the Host should see that the Server is already connected and instead of showing the Red Connect button, it should be - maybe Blue - showing that the Host is connected to the Server and the server is connected to the printer... Seeing a Red button showing no connection, the natural thing to do for someone who never used this setup would be to try to connect - nothing showed that it was connected to the server.

Anyway, as far as hanging, I tried test prints and it didn't hang when i right clicked like it did at least once before. BUT, i was just doing another long print, 11 hours, and when i unplugged my Android from the usb port (which i use to charge the phone, but it also opens a serial port connection / file manager with the phone, which closes when i unplug it). As soon as I unplugged the phone the printer just stopped. I found that Repetier was still running. But, not communicating with the Printer. I had thought Repetier had crashed because I tried to stop the printer and then home the head (so the hot head isn't melting a big hole into the print). It didn't home it. So, I thought it was crashed, but, then i noticed it said 1 -

Command Waiting. Repetier was still running, but just not communicating with the printer. So, I went ahead and saved the .gcode file - because what i do is find the layer where it stopped then edit the gcode file and have the printer resume at the same layer. When communication gets lost like that it messes up the USB port logic, Inside Repetier I Disconnected from the printer, then I rebooted the Printer, then Reconnected, and it shows Green as Connected, but, still when i try to control the printer it just says commands are waiting... so, the connection is actually lost or not processing in the USB port.

When this happens the only thing i know to do is reboot my PC. (Disabling the Serial Port and re-enabling never helps).

So, if using the SERVER will side step these problems, i'll definitely learn how to use it.

But, I never had these hang up issues with 1.0.6, so the new version must have some unplanned features... (which is how a company i programmed for years ago used to refer to 'bugs').

And, it does seem to have some problem with the communication logic somewhere, because when i've right clicked one time, it stopped, when i unplugged a USB connection it stopped. Both use USB/serial port as does the printer.

Repetier

The server handling is in deed a bit complicated. Here connected means connected with the server independently from printer connected to server. Server tab shows here if printer is disconnected. A blue button would maybe in deed a idea to show connected without working printer on every screen.

Your symtoms indicate a hand in port stack somewhere. I do not really think this can be fixed inside the host because host only uses the serial port offered by windows. The crash is after that point. I heard the same with 0.95 and 1.0.6. Fact is if a port is crashed especially with host still connected the host often hangs because the low level serial routine do not return. I have this in a serial console and here restarting host and unplugging usb/disabling printer helps. Only in rare cases I had to reboot windows. Seems like unconnecting restarts the usb com stack.

But anyhow, would be interesting to see if the server has the same problems. It is written in C++ so it does not use the slightly buggy .NET serial classes for communication.

unltd108

It seemed to be going good using the Server, until I plugged in my cell phone to charge, when i unplugged it, again the Communication with the printer stopped. It didn't just pause, it broke. The print was a loss, but, i tried unplugging the usb and plugging back in, at least it was able to reestablish connection without rebooting the PC. But, there is definitely something amiss with the serial/usb communication. I am tempted to go back to 1.0.6 because i never had that problem before, just to see... I am also using a USB hub for both the phone charging and the 3D printer. My printer is 15 feet away from my PC, my desk is in the middle and my PC is on the other side, the hub is on my desk in the middle. If I can find a long enough cable I might see if plugging it directly into the PC would resolve it for now. But, I just never had these problems before.

I also have 2 other questions:

1) i'm using the Server to connect, but in Host it doesn't show me the layers. It used to show current layer / total layers and time remaining, now it just shows the time to completion. In the Server page it Printer Control it does show current layer, but it is showing total layers as 0... like right now it is on layer 17 and so it shows 17/0 (I know there are 250 layers in the current print, but it shows 0).

2) Previously in Repetier host it would show time to completion. Such as showing me the print would take 1hr 32 min to complete. That was always spot on. But, with Host it shows the ETA, such as 5:32:36 PM, as an actual time stamp, but, it is Way Off. When it said a print would take 6 hours, it took over 9. I know there are values to set in the printer settings, But, why was the Host able to give me a precise time estimate, and server calculations are way off?

3) and while I'm at it, the Host still displays the 3D view correctly, showing the printer bed and shows the filament and travel (if selected), as it is printing. The Server has a preview and live view also, but, what it shows is WRONG.

I think it maybe because i have a Delta (Circular) printer, with circular bed. What it appears to be doing is only showing Positive X & Y and crops off the image at 0 and doesn't display any of the object that is negative X Y. On the circular beds, at least mine, x=0, y=0 is at the Center of the bed, so it prints in both positive and negative X, Y. The print still prints properly, and the Host still displays it properly, but the Server doesn't display it right.

Repetier

0) Other devices on usb have no software side effects to the serial connection (or shoudl have). So I doubt that connecting/disconnecting a other device normally causes any problems. In fact I do this all the time when adding/removing test devices. In your case it is a device consuming some power so my guess is that this causes some electrical problems braking communication somehow. Try charging to a different usb port of the PC and see if it still happens or test with other host software and same usb port in which case I think it will still happen.

1) Will check. Should get layer counts from server but maybe it fall back to own counting and has not all informations.

2) Our experiance is that server is much more precise. At least with right firmware settings. Host doe snot account for limited speeds and acceleration while server does. I think the problem might be related with your error in 3)

3) You have set xy min to 0 which is why moves are cut off at 0. Set them to -radius and you will see the complete moves.

amigoloko

After upgrading from Repetier V. 1.0.6 to 1.5.2/1.5.3 when ever i send any print, printer goes to pause every couple of lines of codes. approx. every second or so. it seems that the pause its different due the geometry or the path the extruder is following to extrude. on each stl file the pattern of the pauses/stops timing and duration is different but still stops/pauses

Printers run with Marlin 1.0.0.

Test has been made:

Repetier V. 1.0.6 with slic3r 1.2.9\1.1.7 without issue,

as soon as the upgrade to:

Repetier V 1.5.2/1.5.3 with slic3r 1.2.9\1.1.7 with issue.

It might be the new server runing on the background,

or the octoprint routine

Any ideas?

Best Regards

Repetier

@amigoloko If you are using new Host you need to be more precise. Did you have the problem while printing with the server controlled by host or did you connect with the host directly to printer. These are different routines and I need to check the right one. Please also provide logs with the error including ack and commands send. Best is always a file log.

amigoloko

OK, I have not used the Server, just the regular interface of repetier host..

there are no logs of an error, the printer just pauses for a second and then continues, but the print end in a fail due to plastic smashed on the spot were it pauses.

But i will test it again with the new version and post the result.

it will be a nightmare to let the printer to finish the whole print due to the behavior. or let me find a small print for let it to finish

Repetier

I have a theory how this can happen.

First I guess you have set "Input Buffer Size" to 63 since it is the smallest common buffer size. If you have a avr board you will have 127 so setting this value up should help.

One time it happened you got

< 16:23:19: N87776 M105

< 16:23:20: N87777 M105

> 16:23:20: ok

< 16:23:20: N87778 M204 S4000

< 16:23:22: N87779 M105

> 16:23:22: ok T:219.8 /220.0 B:60.0 /60.0 T0:219.8 /220.0 @:127 B@:127

> 16:23:22: ok T:219.8 /220.0 B:60.0 /60.0 T0:219.8 /220.0 @:127 B@:N87779 ok T:219.8 /220.0 B:60.0 /60.0 T0:219.8 /220.0 @:127 B@:127

< 16:23:23: N87780 M105

> 16:23:23: ok T:219.8 /220.0 B:60.0 /60.0 T0:219.8 /220.0 @:127 B@:0

< 16:23:24: N87781 M105

> 16:23:24: ok T:219.2 /220.0 B:60.2 /60.0 T0:219.2 /220.0 @:127 B@:0

< 16:23:25: N87782 M105

Important is the line with 2 ok where the trouble starts. We are now missing a ok so some part of the buffer keeps reserved. Now see 2 common commands:

N87531 G1 X77.852 Y96.297 E16.42255 *234

N87731 M105 *122

41 + 17 = 58

Together we have a length a 58 so with 63 buffer length we can only add 5 bytes - not enough for one more command. Now first command gets removed with next ok. Leaves 17 byte usage = 46 byte free. If the next command is longer because it has F2400 in addition it will not fit until M105 is removed. But it will not be removed, because we missed the corresponding ok. Next second server will insert M105 which is a short command so it fits. It is also the shortest possible command so we will never get more free room in our buffer. So all we see is a M105 every second and print job hangs because it can never send the long command. Would the M105 also not fit, we would get a timeout and buffer gets freed completely. With next Marlin generation we get lines to prevent exactly this issue. Now I have to think how I could detect this strange hang condition. A first start is increasing buffer to 127. That should solve it for a longer while.

Same problem of course occurs with host in same condition.