I would check the cables anyway. Disconnect them and connect them again and see if it changes anything.
I your ender 5 was delivered like my ender 3 was, then the cables on the board were already connected. If you didn't check them while assembling the printer this could be the issue.
Fair Point, I will check that thanks and revert back.
What is interesting is if you check the Serial Log in the beginning of the print there is a lot of echo:busy: processing responses it the clears up for a while and then starts again and just before I cancel the print due to this stepper disconnect there is a whole bunch of them so hoping the logs would help with what is happening here.
I'm having the same issue. The y- axis freezes but x- and z- keep on going. I've already checked the cables, the gcode, the logs, and nothing seems to be amiss...the prints just keep failing. For a while if I restarted the printer and octopi immediately before the print it would finish without issue, but the issue has recurred even after a system restart. Using a Pi 2B, OctoPrint 1.3.12, OctoPi 0.16.0, Marlin 1.1.8 with an Ender 5&silent mainboard. Unfortunately I'm starting to suspect the board.... following this thread in case anyone else has this issue.
Hi Spaceboi
I am glad I am not the only one that is having this issue, however and just check my Y axis does not Freeze per say its stops moving and if you the feel it it's loose like it was disengage. If it just froze it will not be able to move or moving it would be tough as you would be working against the stepper.
I have not had much time to troubleshoot this much further however I have found that is seems to happen more often with small objects and especially round corners, or round objects. for example :
I can print print the attached temp tower no issues but the other attached file I cannot print for no love or money.
It just does not make sense, and would be interesting to see what results you get.
The base post gcode file fails at about the 5th or 6th circle on the first layer if I recall correctly.
Keep me posted if you do try printing it.
lerminator_gcode.zip (2.3 MB)
I have an ender 3 also and the same problem occurs. Any help from anyone would have great.
@James_Nixon
Pls provide these informations - they might help us to resolve the issue 
Logs ( octoprint.log , serial.log or output on terminal tab, browser error console ...)
Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ...)
@PrintedWeezl just had a print fail a few seconds ago exhibiting the same problem again. Had logging enabled this time, attaching in case they help. I didn't see anything terribly out of place...it's almost as if the board just ignores the y position part of the command. Watching terminal as it fails, the commands still contain the y position updates.... not sure if they're not being received, if they're falling off somewhere, or if something else is happening. The same print does not fail when printing off the SD card directly to the printer.
Great you logged it. I'm not at my pc right now but I will look into the log tomorrow.
You said you're running Marlin 1.1.8 as firmware. Is it your own marlin build or the creality version?
Looks like a mechanical or firmware issue, because from the log OctoPrint is happily sending changing coordinates on all four axes.
It’s the creality version of the firmware.
Hi @foosel, Thanks for your response.
As all has mentioned printing from attached to printer is no Issue, so that irons out mechanical.
From a from a firmware perspective it could only be the way in my opinion be how octoprint communicates with the printer, as the same firmware has no issue with printing off SD and I agree with you it still sends all the correct commands but the stepper seems to disconnect.
I am happy to try anything to try get this to work, if you have any suggestions it would be great.
Thanks
The only thing that OctoPrint can do here is what it already does, send the commands from your file to the printer. It's the job of the printer or rather the firmware to do the right thing. I also do not see any kind of communication issues or something like that in the log that could indicate at a problem between OctoPrint and the printer.
I'm sorry, but I don't have an answer for you here other than, whatever this is, I have no idea how it could be OctoPrint's fault or be anything fixable by OctoPrint or any other host attached via serial.
I'm having the exact same problem. It prints fine for a while then at some point it randomly loses all Y motion.
I switched my cables to my X and Y axis stepper motors and the issue occurred on the same motor.
Ender 5 with silent mainboard.
Octoprint 1.3.12
Version 0.16.0, running on Raspberry Pi 3 Model B Plus Rev 1.3
Same here. Prints turn out fine from the SDcard.
Ender 5 with silent mainboard.
Octoprint 1.3.12
Version 0.16.0, running on Raspberry Pi 3 Model B Plus Rev 1.3
Okay, so you've proved that the problem isn't related to software or to OctoPrint; it's related to that motor and the related belts/pulleys. If it were me, I'd look for a loose set screw on a pulley, slackness in that set of belts, anything like bits of plastic caught in a gear or lack of lubricant.
What all do we have in common? 1.1.5 silent boards, latest version of Octoprint and I think the same Ver of Marlin from Creality,1.1.8. Has anyone tried a different version of Marlin and see if the issues remain? I doubt that the issue is anything mechanical, unless, we all installed our printers incorrectly or there is a bad batch of motors, cables, etc ,etc. My issue is that the same STL file prints just fine repeatedly from the sd card, but as soon I send that via Octo its craps the bed. If it was a loose cable or motor then it would be reproducible when printing from the sd-card as well. That leads me to think that it's either an Octoprint issue or a Marlin issue. I have seen where people have increased the USB buffer in Marlin ( I think ) and had some success fixing with other issues. Maybe they are related?
I ordered my 1.1.5 board from Amazon (Sovol was the seller) that already had 1.1.8 Marlin for the Ender 5 installed. I’m going to try a different firmware and see if I can reproduce the issue.
Considering that only people with the Ender 5 1.1.5 silent boards have so far run into this, I'd say it sounds more like either a firmware or a printer batch issue. As I already said, based on the logs that were shared so far, OctoPrint is sending the commands it needs to send. Something on the printer's side then stops doing what these commands say and does something else instead. Either that, or the commands don't go through correctly (undervoltage?) in which case it would be fairly unexpected to only affect one single axis however.
The case of the problem wandering along with the motor sounds like a hardware issue, could be that this only looks like the same issue but is an actual mechanical problem.
Different firmware might be an idea, and I'd also suggest to replicate the experiment of swapping the X/Y axis to see if the problem moves with the motor or stays on the axis.
SD card printing doesn't involve checksums, so switching those off temporarily could also give insights, in case there's a parser bug in the firmware regarding the checksums.
Also check for undervoltage and increased communication errors.
Thank you! I'll try those things before changing Marlin firmware. Is there a resource I can refer to regarding turning off the checksums?
Settings > Serial Connection > Firmware & protocol. There disable automatic firmware detection and set checksums to "Never":
Note that this will mean there will be no error detection and recovery possible, so if a transmission error happens between OctoPrint and the printer, it won't be possible for the firmware to detect that and request a retransmission.
Hi @OutsourcedGuru and @foosel i doubt this is a hardware fault as in faulty steppers, or cables, or tension etc. The reason I say this is and like we are all saying, printing from SD works 100%. I have now done 2 x 48Hour prints without a problem on my Ender 5 so I believe I am save to save to say the mechanics are fine. This is also not the only successful print, every single print via SD and there has been many has been successful unless it has been something else like power cuts or Filament.
@foosel as you have mentioned and agree this seems to be and issue printing through USB (Serial) unfortunately this is with OctoPrint doing it in this case.
I will try your suggestions further down in the thread and advise on the outcome.
