![]() ![]() gcode files sliced by Cura 3.4.1 configured for a CR-10 5S (which I do not own and do not need for this experiment). I'll do you one better, Temp.zip (50.5 KB) contains two. Ultimaker Cura 3.4.1 includes a profile for the CR-10 S5, did you add that as a printer in Cura? Tell us what slicer is supplied / recommended with the CR-10 S5? Second, the slicer you use does NOT need an OctoPrint interface. They are totally irrelevant and obsolete. ini files and Cura 15.04 out of your brain. Sure would help in understanding octoprint!įirst, can you please get this fixation with. Wish we had a visual picture of the flow control process of octoprint, with drill down capability. I tried to generate one by downloading 15.04x to the Winblows machine and running it, but no luck there, either. ini files on either the Windows or Debian Linux hosts, and none that I could find on the octopi RPI. I suggest you follow the printer manufacturer's advise until you have a few successful prints under your belt. The printer should have come with either a bundled slicer or a recommendation of which slicer to use. If your slicer of choice does not have a profile for your printer already defined, it is possible to create one but this is not classified as a "newbie" project. stl files and print them successfully via OctoPrint. If Cura 3.4 has a profile for your specific printer, then you should be able to slice. The key here is to have the printer properly defined in the slicer including any custom start gcode. stl files (old or new) can be sliced by just about any slicer. I personally have used Cura (versions from 15.04 through to 3.4), Simplif圓D, KISSlicer, IceSL, and slic3r to generate gcode which was uploaded to OctoPrint and printed successfully. I believe this is the source of your confusion. As I suggested previously, ignore this process as it is obsolete. If you wish to change the slicing parameters, you need an external version of Cura 15.04 to generate compatible. stl files with the bundled Cura 15.04 and the default. This is the way the majority of people use OctoPrint, slice on an external machine, transfer gcode to OctoPrint.īy default, OctoPrint will only process. OctoPrint will print gcode files produced by a wide variety of slicers (and slicer versions). So I was hoping to cut out a LOT of fiddling by Cura's 3.4.x claims that it can print via octoprint. As I understand it, I can't use the gcode generated by anything newer than 15.04x due to the structure of the gcode being changed after that version. Sheesh, did I really type all that?Īll my objects to print are saved as. ![]() So comms were good just the print hung and failed miserably. Due to physical layouts, the hosts are in one room, and the (monster!) printer is in the kitchen but I had already run an ethernet to the kitchen. So I went to the printer and manually fired up the extruder heater but the RPi just hung there, forever, and nothing moved/happened after that. However, when I try to print from Linux Debian host from the computer room, Cura says it is connected and the stl / sliced gcode (maybe) was transferred to the RPi, but 1) the printer got the bed heat command and executed it, but that's where it stopped. ini file (instructions are very vague on that.)ĭiscovered that Cura 3.4.x SAYS it can print through octoprint with the appropriate add-on, so added it on. Could NOT get cura 15.0.4.x to cooperate through octoprint because I could not generate the proper. Got one SD card print to work (the cat,) and one octoprint to work from remote by bare-bones octoprint directly to the RPi, of a gcode previously generated for the other printer. Assembled and tested a CR-10 S5 just yesterday. Glad someone pointed me toward your group and thanks for the add. ![]()
0 Comments
Leave a Reply. |