I have set up the printer similar or exactly the same as other CR10S profiles are on this site and every time I try to print a file via Octopi the print fails because before it starts to print the print head goes into a far corner even to the extent that it scratches the print surface, although correctly leveled. What did you already try to solve it?
I tried to print one of the demo files, which are printing just perfectly when being printed directly, and even those fail.
Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible)
Since I installed octopi yesterday and then upgraded to the latest version, it should have the latest version. octopi is running on a pi3
The printer is a CR10S pro V2
Creality, CR-10S, rect, origin lower-left, heated bed - yes, X - 300mm, Y - 300mm, Z - 400mm, X & Y speeds - 6000 mm/m, Z speed 200mm/m, E speed 300mm/m, no invert controls, nozzle 0.4mm, 1 extruder
Is there a verified to be working profile for the CR10S pro V2 that I can download?
I did and I did. Set it up exactly as described. Still. A print file that works perfectly when printed directly drives either the gantry up until it hit the top stop or to the side until it hits the sides, but it does not print. Everything else seems to work. I can see and set the temps and everything and I would love to love it because that , ... well because, if it would just print the same way a known good print file does when started directly from the printer
I would suggest getting comfortable with the meaning behind some of the basic gcode commands themselves, especially the concept of absolute/relative mode.
Many scripts try to do things in a relative way. For example, the average pause/resume short set of gcode scripts might change to relative mode, move the hotend assembly up by 10mm and wait... then lower by 10mm and continue. But if that pair of scripts doesn't return the X/Y/Z motors back to absolute mode (assuming that's what you had before) then all hell will break loose when your gcode file continues and the hotend will be moved somewhere else.
So mismanagement of absolute/relative movement state is often a primary reason why things crash into other things.
Review the contents of all the scripts found in OctoPrint -> Settings -> Gcode scripts. If code is there, know what it does. Review the first 30 or so lines of your gcode file. Know what that does and why.
I understand what you are saying, yet ... I would have expected a software package the quality of octopirint to arrive in a somewhat usable form and not be a kit that I have to put together. I give it a working file and it f*cks up. This is frustrating.
I would have expected if nothing is done to octoprint out of the box it is fully transparent. A file that already printed would print again, and afterwards I can do things.
Anyway, when the currently running print is done I will look into that to see if I can see anything in there.
Not all gcode files are the same. A benchy or 10mm cube might print nicely on yours without any worries. I've seen where nozzle-wiping routines or prime lines cause problems in some cases and they have little to do with the actual part itself.
For myself, OctoPrint out-of-the-box doesn't include homing commands which my Robo board and forked Marlin firmware seem to want before honoring any movement commands. So I'm expected to do these manually each time I start the printer or I'm expected to add them to my startup gcode within OctoPrint in order to be successful. But you wouldn't expect everyone's printer to be forced to do the same just because mine does.
I wouldn't really say that 3D printing is yet to the same level of user-friendliness which you might expect from opening up a brand new inkjet paper printer, for example. We're still in the Phase One of all this where things are still problematic and the kinks aren't ironed out yet. This is the time of the California Gold Rush in which people are out there selling questionable shovels to the throngs of would-be '49ers all hoping to strike it rich. Note that foosel didn't charge you anything for OctoPrint so she's not who I'm talking about in this but rather the people selling you printers with wonky firmware they barely understand.
In the meantime I dug into g-code and created proper start and stop scripts. I am going still not 100% happy but when I am I will post the whole configuration here so that other folks don’t have to do the same.
It will be more than worth it once you get the kinks ironed out. Definitely post the config once you have it figured out. If you need some help, you are sure to find it here also. Thank you for contributing!
I had this happen to me aswell (Also CR10S PRO V2), it destroyed my first bl-touch by jamming it into the buildplate, however this did not occur when starting a print, it occured when connecting octopi to the printer, this was a few weeks ago. Today i ran into another problem, Octopi crashed, i rebooted it and installed an update to "Layer Progress" plugin and it autorebooted again. This time when it booted up and connected to the printer the bed started moving all the way to the front and just kept on trying to move it forward, it stopped after a while but i am concerned something like this will happend again. What might be wrong?
I've had some problems as that as well. It was related to TMC drivers, (CR10s pro v2 has 2208's), loosing their configuration and falling back to badly initilised spreadcycle. It would then go way to fast and crash into bounds.
In my case it has to do with cutoff of 24v line, which is operated by a relay.
For this particular case there are two solutions:
have Marlin enable / disable itself with M80 / M81. M80 would then re-load the TMC settings.
I was having too troubles with the start gcode of my prints on my Creality CR10S PRO, Marlin 2.0, Tiny Machine version, and all started after upgrading my slicer cura, from 4.5 to 4.61, after cursing my days with the printer firmware, I reverse the cura upgrade back to 4.5 and that solved the problem with gcode exceeding the print volume of the currently selected printer profile. I can still see in octoprint gcode preview that my model is way outside the printing area, just a part of the model, but, cura fixed it. I dont know why this is happening, and I dont know how to fix it better, I mean, to be able to center the model in octoprint printing area in gcode preview, maybe somebody, one day, will add this functionality, best of luck!
