› ›

Print stopped half way through when printing from Windows 10

rodthomasrodthomas
in Windows
I'm a 3D print newbie, and hving just build an Anet A8 and printed a couple of things from the SD card I thought I'd try out Repetier Host/Server.
I was initially very impressed with the software, brilliant!
That was until I left a print to continue and returned a while later to find that the print had just stopped in the middle.
I'm guessing that the connection was lost but I can't find anything in the Windows 10 Event Viewer except some Edge crashes (quality Microsoft software eh?).
I saved the gcode to the SD card and it printed fine.
Is there anything I can do to troubleshoot what happened - are there any Repetier log files I could look at?
Is it possible to configure Repetier to download the whole of the gcode to the printer so that it isn't dependent on the connection to the computer?
As you can understand I'm nervous about printing via the Repetier route again in case it fails again wasting time and material, but its so good I'd like to use it as long as I can make it reliable.
Thanks for any help.


Comments

  • RepetierRepetier
    Server is meant to print over usb only. Only that way you can benefit from all the cool features. Of course you can store with host to sd card and start sd print but then all you can do is watch temperatures.

    Printing from server is normally very stable and only real problem with W10 is that you can not prevent windows from updating and rebooting.

    So first you should find what the problem is and then hopefully fix the source of it. In server in web frontend you have a printer menu with log entry. There you can enable logging and later download the log file and check it for errors. There is also a general server log under c:/ProgramData/Repetier-Server/logs whcih also show special things happening. Both together might give the required hint.

    If you have repetier-firmware you can run tests without real filament usage by enabling dry run (in host manual tab or by sending M111 S14) for testing. In some cases this works and real prints not. That would indicate heaters introducing the problem either by induction to usb cable or power (voltage) going up/down from the switching of heaters. If it drops too low it might stop usb communication completely. You see this simply because you can not connect again to printer without unplugging usb and unpowering printer. 
  • rodthomasrodthomas
    I think I may have found the problem. The USB port uses a CH340 driver and when I did a troubleshoot on the port it said that it may not be compatible with USB3. My laptop has USB2 and USB3 sockets and the printer was plugged in to a USB3 one so I'm going to try plugging it into USB2 and see if that fixes it. It only seems to be a problem with prints over 2 hours, I've printed several smaller items with no problem.
    Thanks for the feedback.
  • rodthomasrodthomas
    Forgot to mention that I found a BugCheck event in the Windows logs which had created a crash dump. This is what pointed the finger at the CH340 driver.
  • RepetierRepetier
    Ok, if drivers crash there is nothing we can do from our side. Hope using USB2 port helps here.
  • rodthomasrodthomas
    Seems OK so far. Hopefully it could be useful info for other users who may run into this problem.
  • rodthomasrodthomas
    Nope, still getting a BSOD without warning every now and then.
    Do you think it would help to upgrade the firmware from the stock Anet A8 to Repetier?
  • RepetierRepetier
    I don't think firmware is responsible for blue screen. The serial->usb converter is what communicates with windows over usb and if that is the reason for blue screen it does not change with other firmwares.

    What would help is not printing with windows, e.g. store repetier-server on a raspberry-pi like computer and just use the host on windows. Then a windows crash does nothing to your print or if it really comes from serial driver it will not crash at all as you are then using the pi for connection.
  • rodthomasrodthomas
    Yes, I suppose it serves me right for using a Windows 10 machine! :(
    I don't have a spare Pi at present but could try my Ubuntu machine - do you think the serial interface from Linux would be more robust?
    Printing fine from the SD card - as an aside is it possible to download the gcode to the SD card in the printer? The options seem to be disabled in Repetier host.
  • RepetierRepetier
    Yes, there is a safe for SD printing option. Just plug sd card into windows machine and copy file. It is much faster then using usb to copy, whcih works if you have sd card enabled in printer settings.

    Ubuntu is linux as well on pi. They have one driver for most serial devices and that works normally very good. So at least woth a try.
  • bdenkersbdenkers
    Repetier said:
    I don't think firmware is responsible for blue screen. The serial->usb converter is what communicates with windows over usb and if that is the reason for blue screen it does not change with other firmwares.

    What would help is not printing with windows, e.g. store repetier-server on a raspberry-pi like computer and just use the host on windows. Then a windows crash does nothing to your print or if it really comes from serial driver it will not crash at all as you are then using the pi for connection.
    What is the point of having windows server if your just going to tell people to use linux? I use windows for my server because of ease of use. All in one place rather than having another set of hardware to run it. Is this going to get fixed?
  • RepetierRepetier
    The problem is a buggy serial driver for windows here as it seems. We did not write this driver so this is a point of failure we can not fix. Why it does not happen on host with same driver I can not say. But that is a different programming language using the microsoft provided c# class while server is written in C++ using the direct interface which the c# also does in the end. So what is the difference? No idea. All I know is that server is working stable on windows for many users and printers. And all talk the same way with Windows and the driver.
  • MiniziumMinizium

    The issue I have with your answer is that repetier host works perfectly fine with the same USB COM port driver. Why does repetier server have this BSOD crash issue while repetier host doesn't? Surely they must be interacting with the COM port slightly differently? Why not look into that and find a solution?

    I've used repetier server on several computers and they all crash with the same BSOD error using repetier server, but all work perfectly fine with repetier host. Can you explain this? I would really love to be able to use repetier server if at all possible...

  • RepetierRepetier
    Host uses the C# serial class for communication. Server uses Boost ASIO library to communicate. Server version can communicate a bit faster and has a better access, but is also known to be very stable, except as far as I know for the CH340 chip/driver. You can try changing the DTR/RTS signal state and see if that makes a difference for the driver, but the problem is that the driver causes the BSOD in the end. Maybe there are new versions not crashing any more I don't know. Do not have a printer with that chipset, so never got the problem.
  • TheMattRayTheMattRay
    Any updates on this. I am intrigued. Having periodic issue like this where a print stops mid print via usb to my Monoprice mp10. Log indicates some communication troubles but only after 20% or more is printed. Ideas?
  • RepetierRepetier
    Depends on the problem you have. If it keeps connected and just communication stops also host tries to send after timeout, then communication stack is corrupted somewhere. Nothing we can solve on our software side. You can try different usb cables and usb ports. Especially long usb cables can be problematic also some have it with no problems. Really depends which components are on the 2 ends of cable and which cable you use.
  • xpsionxpsion
    nothing wrong with driver , it is power mode settings even in high performance mode mode of windows
    disable the USB selective suspend mode  in power plan advanced settings!
    that solves the problem
  • BobSBobS
    I have had several long prints fails after many many hours... as in 82 of 88hr print it just stopped.
    The log was full of communications errors...
    I am reluctant to restart my 88hr print as it was a LOT of filament and emotional energy watching and fixing minor foibles over 4+ days only to have it fail within sight of the finish...

    And... I haven't found a way to recover from it. There is no "resume at layer X" type function...
    The place it failed was messy, so no chance of re-starting at that level and glueing it on...

    I will try reducing the queue size and the power setting, and maybe the commands/sec as well and try some other prints  before I re-start an 88hr print....

    Any and all other sugestions welcome
  • RepetierRepetier
    Or directly select ping-pong mode and see how communication errors change. That is the easiest communication solution for printers.

    Server has a recover feature but you need to enable and configure it. Then you can continue failed prints that stopped from communication issues at last known position or which ever position you choose. But ofen extruder is cold sticks to object or has poked a fat hole where it stands so only sometimes useful if it is in infill for example.
Sign In or Register to comment.