›

Any way to resume print after losing connection? I just lost 36 hours of printing.

psaccesspsaccess
edited February 2019 in Repetier-Server
I've had my Raspberry Pi / Repetier Server Pro (.90.7) setup fail on me a few times in the month and a half that I've been using it, and each time it's caused a catastrophic failure of my running prints. How on earth can I mitigate this? The server has, on all three occasions, crashed during the upload of a gcode file to one of the printers. It makes me afraid to do anything with any printer on a server that is printing. Are there any logs that I can provide, or more detailed information? I'd love to never have this happen again, as it's a significant opportunity cost for me.

Comments

  • psaccesspsaccess
    I'm also now randomly losing connection to one of my printers, consistently. It will happen in the middle of a print, seemingly randomly. Hopefully there's a log of what's going on, but I can't seem to find it.
  • RepetierRepetier
    Upgrade to 0.91.2 which contains a rescue system to continue prints in these cases. Works especially well with dev version of Repetier-Firmware which helps to preserve such prints actively. You need to enable rescue system in printer settings.

    Your symptoms let me think your power supply is not stable. After a while of usage login via ssh and enter 
    dmesg
    and see if it contains linux warnings about under voltage. This can lead to disconnects and in hard cases will crash linux. This happen often under bigger load like when you upload a file and it gets analysed increasing cpu usage.
  • useruser
    Repetier said:
    Upgrade to 0.91.2 which contains a rescue system to continue prints in these cases. Works especially well with dev version of Repetier-Firmware which helps to preserve such prints actively. You need to enable rescue system in printer settings.

    Your symptoms let me think your power supply is not stable. After a while of usage login via ssh and enter 
    dmesg
    and see if it contains linux warnings about under voltage. This can lead to disconnects and in hard cases will crash linux. This happen often under bigger load like when you upload a file and it gets analysed increasing cpu usage.
    Hi! I tested the rescue system. It not work for me. I flashed dev repeiter-firmware (11.03.2019) into an mks gen l. I start to print and disconnect an USB cable from raspberrypi. Hotend goto home position and axis Z(bed) goto Z=10 (near). After it i connected USB cable and press continue printing. Print was strted work but axis Z was not correct.
  • RepetierRepetier
    >  Z was not correct.
    Did z axis move between restart or on reconnect through server? The rescue system requires that z axis holds position or it will loose it. That does not include the z move that gets reported to server from firmware rescue system assuming this happened as you said extruder did go to the side.
  • useruser
    Repetier said:
    >  Z was not correct.
    Did z axis move between restart or on reconnect through server? The rescue system requires that z axis holds position or it will loose it. That does not include the z move that gets reported to server from firmware rescue system assuming this happened as you said extruder did go to the side.
    Z axis was move after i disconnect the USB connect. I understend now that is not ok but i not understend why my bed is moved. I will try to make an video.




    G
    M
    T
    Y
    Определить языкАзербайджанскийАлбанскийАмхарскийАнглийскийАрабскийАрмянскийАфрикаансБаскскийБелорусскийБенгальскийБирманскийБолгарскийБоснийскийВаллийскийВенгерскийВьетнамскийГавайскийГаитянскийГалисийскийГолландскийГреческийГрузинскийГуджаратиДатскийЗулуИвритИгбоИдишИндонезийскийИрландскийИсландскийИспанскийИтальянскийЙорубаКазахскийКаннадаКаталанскийКиргизскийКитайский ТрадКитайский УпрКорейскийКорсиканскийКурманджиКхмерскийКхосаЛаосскийЛатинскийЛатышскийЛитовскийЛюксембургскийМакедонскийМалагасийскийМалайскийМалаяламМальтийскийМаориМаратхиМонгольскийНемецкийНепальскийНорвежскийПанджабиПерсидскийПольскийПортугальскийПуштуРумынскийРусскийСамоанскийСебуанскийСербскийСесотоСингальскийСиндхиСловацкийСловенскийСомалийскийСуахилиСунданскийТаджикскийТайскийТамильскийТелугуТурецкийУзбекскийУкраинскийУрдуФилиппинскийФинскийФранцузскийФризскийХаусаХиндиХмонгХорватскийЧеваЧешскийШведскийШонаШотландский (гэльский)ЭсперантоЭстонскийЯванскийЯпонский
    		АзербайджанскийАлбанскийАмхарскийАнглийскийАрабскийАрмянскийАфрикаансБаскскийБелорусскийБенгальскийБирманскийБолгарскийБоснийскийВаллийскийВенгерскийВьетнамскийГавайскийГаитянскийГалисийскийГолландскийГреческийГрузинскийГуджаратиДатскийЗулуИвритИгбоИдишИндонезийскийИрландскийИсландскийИспанскийИтальянскийЙорубаКазахскийКаннадаКаталанскийКиргизскийКитайский ТрадКитайский УпрКорейскийКорсиканскийКурманджиКхмерскийКхосаЛаосскийЛатинскийЛатышскийЛитовскийЛюксембургскийМакедонскийМалагасийскийМалайскийМалаяламМальтийскийМаориМаратхиМонгольскийНемецкийНепальскийНорвежскийПанджабиПерсидскийПольскийПортугальскийПуштуРумынскийРусскийСамоанскийСебуанскийСербскийСесотоСингальскийСиндхиСловацкийСловенскийСомалийскийСуахилиСунданскийТаджикскийТайскийТамильскийТелугуТурецкийУзбекскийУкраинскийУрдуФилиппинскийФинскийФранцузскийФризскийХаусаХиндиХмонгХорватскийЧеваЧешскийШведскийШонаШотландский (гэльский)ЭсперантоЭстонскийЯванскийЯпонский
    Звуковая функция ограничена 200 символами
  • RepetierRepetier
    Just to be clear. If you have in eeprom the value for
    Park position Z raise [mm]
    it will raise that amount and that is ok. Any additional rise maybe because it drops a bit after reset would not be ok.
    You can try to set this raise to 0 for testing. Then you know any raise you get is causing the problem. For testing I just use a simple fast object and unplug usb at some point.
Sign In or Register to comment.