Glad someone pointed me toward your group and thanks for the add.
I am puzzled about how to proceed. Assembled and tested a CR-10 S5 just yesterday. 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. Could NOT get cura 15.0.4.x to cooperate through octoprint because I could not generate the proper .ini file (instructions are very vague on that.)
Discovered that Cura 3.4.x SAYS it can print through octoprint with the appropriate add-on, so added it on. 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. 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. 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 comms were good; just the print hung and failed miserably. Sheesh, did I really type all that??????
I suggest not bothering with the Cura bundled with OctoPrint. I suggest slicing on another computer and then transferring the gcode to OctoPrint.
Instead of jumping right into a marriage between Cura and OctoPrint, I'd suggest that in Cura, you save the gcode to a file and then use OctoPrint's web interface to transfer the file and start the print. Understanding OctoPrint's web interface is good knowledge to have.
If this gcode file fails to print, then troubleshooting will be much easier because you can post the .stl, the .gcode, and the .log files for us to look at. Once you are successfully printing using these steps, then you can try the Cura 3.4 / Octoprint interface and know with confidence that if it fails, this interface is suspected.
The physical separation of the slicing host (Debian) and the printing host (OctoPi / OctoPrint) is common. My printer is located in an adjacent room and I communicate via WiFi. It is not convenient to run either a USB cable or an Ethernet cable into that room.
Thanks, b-morgan.
My second print was a test to do just what you suggested. Used a previous gcode file and sent it via the RPI's web interface and it printed just fine. That method is a bit fiddly, though, which is why I tried the Cura 3.4.x route for the 3rd print - and that is where i ran into the trouble. 
That gcode was generated by an older version of Cura that came with repetier and I'm unsure what version it is.
All my objects to print are saved as .stl's except that one. 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. So I was hoping to cut out a LOT of fiddling by Cura's 3.4.x claims that it can print via octoprint.
Your understanding is incorrect.
OctoPrint will print gcode files produced by a wide variety of slicers (and slicer versions). This is the way the majority of people use OctoPrint, slice on an external machine, transfer gcode to OctoPrint.
By default, OctoPrint will only process .stl files with the bundled Cura 15.04 and the default .ini files included. If you wish to change the slicing parameters, you need an external version of Cura 15.04 to generate compatible .ini files. As I suggested previously, ignore this process as it is obsolete. I believe this is the source of your confusion.
I personally have used Cura (versions from 15.04 through to 3.4), Simplify3D, KISSlicer, IceSL, and slic3r to generate gcode which was uploaded to OctoPrint and printed successfully.
Your .stl files (old or new) can be sliced by just about any slicer. The key here is to have the printer properly defined in the slicer including any custom start gcode. If Cura 3.4 has a profile for your specific printer, then you should be able to slice .stl files and print them successfully via OctoPrint.
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. The printer should have come with either a bundled slicer or a recommendation of which slicer to use. I suggest you follow the printer manufacturer's advise until you have a few successful prints under your belt.
There are no .ini files on either the Windows or Debian Linux hosts, and none that I could find on the octopi RPI. I tried to generate one by downloading 15.04x to the Winblows machine and running it, but no luck there, either. Wish we had a visual picture of the flow control process of octoprint, with drill down capability. Sure would help in understanding octoprint!
In using Cura 3.4.x, I did send the gcode (I think) file down to the RPi, but that's where the process broke and would not print anything.
First, can you please get this fixation with .ini files and Cura 15.04 out of your brain. They are totally irrelevant and obsolete.
Second, the slicer you use does NOT need an OctoPrint interface. Your browser is all that you need.
Now...
-
Tell us what slicer is supplied / recommended with the CR-10 S5?
-
Ultimaker Cura 3.4.1 includes a profile for the CR-10 S5, did you add that as a printer in Cura?
Please supply (you can .zip them together) us with the .stl file and the .gcode file (Save to file in Cura). I'll do you one better, Temp.zip (50.5 KB) contains two .stl files and two .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). Unzip these files on your desktop and use your browser to connect to OctoPrint and upload the .gcode files and print them.
If you successfully print those two files, see if you can duplicate the process of converting the two supplied .stl files into .gcode files on your client machine. Use your browser to send your .gcode files to OctoPrint. Did they successfully print?
If at any point you have problems, please provide us with a detailed step by step of what you did and what happened.
But I WANT Cura to send the file directly to the RPi, saving multiple steps per printed object. The printer is currently working using a file saved by Cura 3.4.x, then sent to the RPi via it's web interface, so that works. It's just extra steps and I have to write down or remember the file to send.
Creality, manufacturer of the CR-10 series, sends no software nor any recommendations for which software to use.
Yes, the S5 is set as the current printer in Cura 3.4.x.
Thank you for the help, Mr. Morgan.
David
Since you have successfully printed using the manual method, there's no reason not to add printing directly from Cura and we can troubleshoot any problems that occur knowing that everything else is working.
What errors do you get when you try to do this?
Although I might be able to print directly from my Cura slicer, I never do this because I always prep things in OctoPrint like this:
- Autodesk Fusion 360 -> STL
- Cura <- STL, adjust settings -> GCODE
- OctoPrint <- GCODE and select this file
- Printer: verify that the print bed is empty/clean/adjusted
- OctoPrint: adjust temperature offset
- OctoPrint: preheat for PLA
- OctoPrint: extrude 5mm (to remove any old filament in the hotend's throat)
- OctoPrint: start print
If I tried to print directly from Autodesk, I'd lose the ability to adjust the slicer settings. If I tried to print directly from Cura, I couldn't preheat, set an offset nor prime the extruder.
Perhaps a year ago, I might have taken the faster approach but in my experience, not prepping the printer is often a recipe for a failed print.
There is a misunderstanding about Cura and Octoprint. There is a specific version of Cura and profiles if you want to use Cura as a slicer in octoprint.
But, if you want to slice in Cura in your desktop or laptop and send it directly to your octoprint, you can do that.
I think there is a Cura plugin to install, then at printer profile in Cura settings will be a tab octoprint. You configure the octoprint ip address, inser the API and tells if it should only be transfered, or transfered and printed.
It’s very simple in fact. I’m away from my computer today, but tomorrow I give more details.
Hope it helps.
You can, you just need to add these to the preliminary G-codes.
I print direct from Cura, and preheating happens (I didn't even have to configure it)
Adding a 5mm extrude (and a wipe along the edge of the bed) is easy to add, though might be there by default.
I dunno. I think you'll get to the point where you're printing a variety of filaments. What's in there now? Oh, it's the carbon fiber. That means that I'll need to heat it to almost 210 to clear that out of there. It's the flexible PLA or the XT-Clear? I'm probably going to have to clear a fair amount of that out of there since it likes to stay in the hotend throat. (etc)
I can print from Cura now, through octoprint. All it took was a complete shutdown of host, RPi, and printer control box. Apparently, someone doesn't flush old control data somewhere in that tool chain. Andy, yes, you can add pre- and -post Gcode so you don't have to do anything manually. Guru, if you were asking me, I'm still on the white (sample) PLA that came with the printer. In all, now I'm working out the small stuff, like stringing here and there but only sometimes. Thanks for the help, guys, in getting this new S5 and Cura and me whipped into shape!