Not sure what is going on here, but on 3 of the last 6 prints, it gets some period into the print (sometimes a few mm and sometimes a few cm) and it loses it's Y position by about 2-3cm. The height is not consistent. The first 2 fails were in XT, and with all the snot balls figured that was it. This one was in PLA, and definitely no snot balls (was printing beautifully as you can see on the overhead up until it lost it).
I had the same issues during the first prints I did. Whatever voltage I used I could not solve it. Until I replaced the Y-stepper driver with one of Geeetech I had laying around. Problem solved, and the motor is very silent now.
Apart from the obvious i.e. loose pulley, failing driver and incorrect voltage setting, my worry is that it was a comms error via OctoPrint. It is the sort of thing that used to happen to me with spikes on the power line when driving from Repetier via a PC; moving to SD card source cured the problem, hence my reluctance to use the full features of OctoPrint. You are using a separate supply that will be more susceptible to power line transients, whereas the on board supply and voltage changer provide extra isolation from such events. I always upload to SD as it removes a comms interpretation layer from the printing process as I am not sure if there is a CRC in the handshake protocol used between the OctoPrint and Rumba. If there is, then it is less likely to be an issue. By the way, regarding the snot balls, I notice you are using the triangular fill pattern as I have been and, eventually, I noticed that the process draws the triangle pattern as three lines that cross each other (no surprise there!) but without a layer change between them; this means that where they cross over is a build up of three levels of filament that leaves a small hump at each crossing. On the next layer the nozzle has to traverse these humps and it is highly likely that it will hit them and grab some filament off the top; it is audibly noticeable with 200nm layers. Also, as the nozzle crosses the humps it is trying to extrude filament at the same rate as before so causes sideways extrusion creating hedges and filament wrap-around of the nozzle. For my CF20 prints, this really enhanced the pickup problem, so I am going to experiment by increasing the layer height and switching to fast honeycomb for the infill.
This has been an issue for me too, at least I am not the only one... Mark your pullies and rods so you know if they slip. Then you can at least check that off the list. What's your stepper voltage?
Had this on my i3 also. 2 seperate cases. -Overheating of the stepper, by too much/too low voltage and/or overheating of the stepper (was testing heat chamber (cardboard box fuly sealed, with arduino/ramps inside (temp - 50°+). -Other case was @ the start of Octopi implementation, RPI2 + Wifi dongle and very very bad coverage (cage effect of metal frame). Lagg caused by the Wifi reconnects and the permanent video stream on my TV, caused the Octopi to go to 100% CPU causing the Serial-over-USB to lagg (yes, that what we all are doing). Solved by, putting in Lan cabling Cat7A minor overkill but hey that's the benefit of working in one of the biggest cable company in the World. -Nexans- Were you not talking about enclosed printing? Add to your OctoPi the temps plugin (incl the one of your Rpi, it is a great indicator of the ambiant temp of your electronics) - 35-36°C is a normal operating temp, 45+ is becoming to hot for any electronics.
Just added the plugin so we will see. I am not on wifi, but on switched gigabit ethernet, so hopefully I am not printing so much that we are exceeding that bandwidth!
heh the Pi3 idles a lot hotter than that and plenty of electronics are designed to operate flawlessly and without measurable affect on their life at higher temps than that. The Pi foundation say +80C max I think (the SoC can go a bit higher which is where this temp reading is generated) but the other components like the flash chip can't. Interesting thought though on wifi reconnects nicking so many cycles that octoprint stats lagging behind, if the CPU cost for the wifi reconnect is in userspace then we can do something with the process priorities to resolve that.
Henry check you have a bit of distance (like at least a few fingers worth) between your Pi to Rumba USB cable and all the stuff with heavy current switching like the Stepper and Heated Bed/Hot end cables. Inverse square law and all that, an inch makes a lot of difference Also the original short Pi to Rumba USB cable was screened and presumably you are now using a longer one with your Pi outside the printer...the cheap ones are just foil screened rather than braided screened and the data pairs aren't twisted properly (it's differential signalling on USB so it only really rejects interference really well if it is on a twisted pair) Actually my old K8200 had the opposite problem and used to get this when I printed from SD, the cause was that I extended the cabling between the display and the Marlin board so the display was better located on the printer and that length of unshielded ribbon was picking up noise from allsorts
Yeh but how does the USB lead get to the rumba, are you using the E3D USB port (that also has screened cable I think) or are you feeding a longer cable straight from the Pi to the Rumba ? If so try a different cable.
