repetier server stops working during print

2

Comments

  • edited July 2015
    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.
    #define DEFAULT_MINSEGMENTTIME        20000

    // If defined the movements slow down when the look ahead buffer is only half full
    #define SLOWDOWN

    maybe slow down means... let it stutter
  • i just realize the job commands value shows the complete commands left, nothing else... 

    however, i reduced the buffer size in the server interface and printed the same part with 300% speed. everything went fine.

    i still think it has something with the buffer size to do.
  • 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).

    Download url:

    Hope this gives some more insight. Please do not wast pla just cause the stutter problem to get some more precise logging of the problem.
  • edited July 2015
    thank you,

    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.


  • Just a thought but are you running the x window surface? I have it running without problems, but that could be disabled.
  • edited July 2015
    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.
  • The only change to previous download is more exact logging. No more changes in print logic.
  • edited July 2015
     the pi did not disappoint me, after it made 3 prints without any issue, it now stuttered immediately after the job was started...

    it seems like it tends to occure on long time jobs, the 3 successful jobs before did take 2 hours each, this job, as it stuttered, is a 6 h + job.
    or maybe its just random...


    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.


  • edited July 2015
    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..

  • edited July 2015
    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.
  • edited July 2015
    very good, so i install the update and test again.

    i can´t belief nobody else experienced this issues besides me... 
  • New version is out now.

    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.
  • edited July 2015
    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


  • edited July 2015
    im sorry but this issues is not really fixed now.

    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.

  • Host now installs 0.60.4 correctly.

    Since we have many buffers, which one is the buffer you are referring to? @debugcon buffered value?

    If it happens at every layer something is really wrong. Could you make a log of that problem. Hopefully I can follow what happens there from log.
  • so im back here again... 

    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.
  • i mean the buffer of the printer itself, the value given out with the command @debugcon

    it always says 0


  • now it stopped again... man... on two jobs in a row.

    it seems the only solution for me is to not use the server, this problem chases me now for weeks/month  :/
  • edited September 2015
    i want to add:

    i changed the SD card from the Raspberry PI to one with octopi installed... nothing else was changed with the following results:

    i was able to do 8 prints, on both printers, without any single issue or problem... they just print until the job is done.

    then i changed the SD card to the repetier server again, tried 3 jobs and 3 of them failed... 
    (even the g-code was the same)
    uncontrolled/wrong movements, stops, stuttering, con errors...  or/and just a shitload of problems.

    im sorry to say that, but the repetier server maybe simply is bugged?
    its impossible at this moment, to count on it... very sad.

    i hope you guys can fix this one day.


  • 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?
  • edited September 2015
    Server Version: 0.60.3 and 0.60.4 (both do the same)
    Pi: B+ and 2
    OS: Raspbian (version does not make any difference, tried 3 of them)
    firmware: marlin 1.0.1, 1.0.2, dev branch and 1.0.2-1
    wlan and lan, both tested
    x server off or on, does not make a difference

    i also tested: 4 microSD cards, 3 different ramps 1.4, two different arduino mega, a lot of usb cables, PSUs AND
    it is still the same if the server is installed on a windows OR Linux PC

    it happens on two printers, one is 3 years old, one was built this year

    i also shut off near every source of electro magnetic waves besides the printer
    nothing does help... but as soon i print with octoprint.. EVERY singe job works... every time


  • 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.
  • Hello guys,

    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.
  • edited September 2015
    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.


  • Hi, I am having a similar trouble.

    Just got a 3d printer and I did my setup with a raspberry pi 2. Raspbian + Repetier Server

    The firmware on the printer is a Marlin firmware. I looked at the code and the RX buiffer is set to a size of 128.

    I am trying my first part with the pi and Repetier host hooked to Repetier Server and there's big stall every minute.
    I had 2 major stall with loss of data, 
    image
    I don't know where this "lag" comes from. Any idea ??

    I'm using the latest version of the Raspbian, Repetier-Server ( 0.70.1 ) and the Host ( 1.6.0 )

  • 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.

    Let me know if i need to provide logs.
Sign In or Register to comment.