What’s the state of Octoprint? Any caveats?  

RE: What’s the state of Octoprint? Any caveats?

For me Raspi 3B+ is working fine together with streaming. But It's always better to have more power. Maybe you want to use it for other purposes as-well.

In general I like the combination Raspi+Printer. It's very convenient to handle the print remote and monitor it. Although I prefer to print objects over 24 hours from SD card. Just because you have more options to recover the print.

RE: What’s the state of Octoprint? Any caveats?

What do you mean by more options? What differences are there?

RE: What’s the state of Octoprint? Any caveats?

For example recover from power loss.

You have also more menu options if you print from SD card, like pausing/changing the filament.  I'm pretty sure this can be also done via manual commands in Octoprint console. But from the menu it's more convenient. There is less risk that something is going crazy on octopi. Not that it happened to me but why taking the risk for >24 hours prints. Most of my prints are <24 hours, and even the bigger ones  I can at least monitor my prints via the camera in this case. For me it was a no brainer to add octopi.

RE: What’s the state of Octoprint? Any caveats?

Okay that's good to know as a lot of my prints take longer than 24h. Power loss is not really an issue here so I could do without the recovery feature.

Did you ever notice any difference in print quality?

RE: What’s the state of Octoprint? Any caveats?

No quality difference. Even technically I see no reason why there should be a difference. Printer receives same commands either from SD card or USB. 

RE: What’s the state of Octoprint? Any caveats?

I think what caused the difference in quality was that the Zero was unable to feed the commands quick enough. Prints were noticeably worse when printing via Octoprint.

RE: What’s the state of Octoprint? Any caveats?

No quality differences.  I really enjoy being able to monitor my prints via Astroprint.  

RE: What’s the state of Octoprint? Any caveats?

@charles-h13 looked at Astroprint (on their site), and am not sure what it offers over plain old Octoprint by itself... would you mind elaborating a bit as a user? I can monitor and control prints on both my printer via my Octoprint server running on RPi 3B+ remotely through a web browser.

Looking at Astoprint, it just looks like a cosmetically slicker solution, however I'd have to give control of all sorts of private information, my print data files (IP), etc., to a third party. Gotta have some pretty significant value for me to do that (you can guess I'm not a Facebook user :-))

RE: What’s the state of Octoprint? Any caveats?

I used the astroprint plugin for Octoprint and not Astroprint by itself.  

RE: What’s the state of Octoprint? Any caveats?

Posted by: nikolai.r

No quality difference. Even technically I see no reason why there should be a difference. Printer receives same commands either from SD card or USB. 

Not true... Octoprint is a "filter" that can modify the gcode passing through it, as well as add additional code. This all depends on how you've set up Octoprint, what plugins you've installed and activated, etc.

For the most part, Octoprint passes code through without changing functionality. However, note that every line of code is modified to add a line number directive at the beginning ("N123 G1 X130 Y50 E0.1254" for example, the N123 was prepended by Octoprint).

Given this, what gets streamed to the printer from Octoprint has significant differences from what is "raw" in the gcode file, and would be all that's processed by the printer from the SD card.

While things like line number directives shouldn't affect the print, as all engineers know there are bugs. With that much changing of the gcode (every line!) it's not a surprise that differences show up in printing from SD vs. Octoprint. It could be a timing issue with some race condition in either the Octoprint code or Marlin on the printer, and adding line numbers to each line changes the timing enough to expose the bug.

Pure speculation, I don't know that there IS in fact any such bug. Wanted to provide some more technical depth as to how Octoprint works, and that printing with it does not send the same data, unchanged, to the printer that is read by the printer from an SD card file.

RE: What’s the state of Octoprint? Any caveats?

Posted by: Dave

Given this, what gets streamed to the printer from Octoprint has significant differences from what is "raw" in the gcode file, and would be all that's processed by the printer from the SD card.

Thanks for pointing that out. I agree that plugins do change the gcode. That's usually their purpose. But plain octoprint just prepend the line number. This does not affect the actual print or change how it prints. If you look into the firmware source code, you will see that this data is only being used to store the location in error states. Speculations on bugs in this case is really far catched. 

RE: What’s the state of Octoprint? Any caveats?

actually the N number is also checked to make sure it's greater that the previous line

RE: What’s the state of Octoprint? Any caveats?

Posted by: Dave

Posted by: nikolai.r

No quality difference. Even technically I see no reason why there should be a difference. Printer receives same commands either from SD card or USB. 

Not true... Octoprint is a "filter" that can modify the gcode passing through it, as well as add additional code. This all depends on how you've set up Octoprint, what plugins you've installed and activated, etc.

For the most part, Octoprint passes code through without changing functionality. However, note that every line of code is modified to add a line number directive at the beginning ("N123 G1 X130 Y50 E0.1254" for example, the N123 was prepended by Octoprint).

Given this, what gets streamed to the printer from Octoprint has significant differences from what is "raw" in the gcode file, and would be all that's processed by the printer from the SD card.

While things like line number directives shouldn't affect the print, as all engineers know there are bugs. With that much changing of the gcode (every line!) it's not a surprise that differences show up in printing from SD vs. Octoprint. It could be a timing issue with some race condition in either the Octoprint code or Marlin on the printer, and adding line numbers to each line changes the timing enough to expose the bug.

Pure speculation, I don't know that there IS in fact any such bug. Wanted to provide some more technical depth as to how Octoprint works, and that printing with it does not send the same data, unchanged, to the printer that is read by the printer from an SD card file.

I have not noticed any difference in prints.  I would say if you so that you might want to deactivate some of the plugins.  

RE: What’s the state of Octoprint? Any caveats?

Why was PrusaPrint built for the Pi Zero W? It's the least capable of the Pi family. Why build something that will be hobbled by hardware? I really don't understand why the 3 B+ wasn't selected as the default hardware. This is well and truly dumb.

RE: What’s the state of Octoprint? Any caveats?

Hi,

I am a fresh MK3S User and added Octoprint on RPi3B recently (all newest versions and octoprint MK3 setup as found via google)
I do not plan to slice using Cura on the RPi. I am perfectly happy with the Prusa-Slicer on the PC (Also a MMU2S sill be in sight...)

=> I was somehow disapointed from the first prints over the RPi:
- Some warping effect and also once had a print loose from Base plate (the standard, not the powder) coated, when printing PLA.
(All test before with MK3S were out of the box top quality and never a fail)
- The print time which showed up on the Octoprint Webinterface was always much shorter (for example 1:50 hrs instead of 2:30)

I read about Octoprint mangling gcodes (yes, it's designed to filter; no it only adds line numbers for error logging...)
But actually (as I was 100% satisfied by printing from SD Card) I do not want Octoprint to do any 'optimisations' as I do not trust any additional 'automatic' intermediate layer (would not trust a self driving car either 🙂   )

The optimal system (as I would see it currently) would be
* A prusa control board printing from a network share instead of SD-Card (To my opinion the crash detection, heating runaway prevention, power loss immunity are outstanding features I do not want to miss)

* Any software (or Octoprint on the RPi) that does only 1) Remote Control of Prusa Controller (Start Print, Cancel, Progress, Status) and Webcam streaming. All other gimmicks of Octoprint I do not need at all (like slicing; even the temperature graf is nice but I trust the Prusa controller)

QUESTION 1: Maybee I did something wrong. Does anybody have a link for the ultimate Octoprint for MK3S/RPi 3x setup?

QUESTION 2: The Prusa Controller uses SPI to access the SD-Card. Theoretically it should be possible to emulate a SDCard by
 a RPi or any other controller supporting Slave SPI protocol. Wouldn't it nice to just drop a file to a network share and
print it as if it came from SD-Card. Would this be of interrest for others too?

Greetings
M.

RE: What’s the state of Octoprint? Any caveats?

Posted by: gr8kampe

Why was PrusaPrint built for the Pi Zero W? It's the least capable of the Pi family. Why build something that will be hobbled by hardware? I really don't understand why the 3 B+ wasn't selected as the default hardware. This is well and truly dumb.

Over-zealous enthusiasm, I'm sure. At the time (2017) the Zero was still relatively new and hard to get. For some reason, everybody expects anything that runs Linux to work miracles, and all sorts of expectations were set for the Zero. Quick testing in the forge of reality usually resets those expectations, but there always is a surge of "The RPi can do anything!" with each new board release. I suspect lack of comprehensive testing is to blame, although it's possible Octoprint got bigger around the same time. I'm not sure when exactly the recommendation was made not to use the Zero, especially since the single-core Bs had (apparently?) been OK.

The Zero's sharing of serial and network bus may have been a non-obvious contributing factor. The thinking may have been that a single core B works, so a Zero should too.

RE: What’s the state of Octoprint? Any caveats?

I have had zero problems driving my MK3S with Octoprint on a Pi 3B+. It has never even entered my mind that I'd want to use an SD card. It just works.

RE: What’s the state of Octoprint? Any caveats?

Posted by: holmes4

I have had zero problems driving my MK3S with Octoprint on a Pi 3B+. It has never even entered my mind that I'd want to use an SD card. It just works.

Same here, pretty idiot-proof.  

RE: What’s the state of Octoprint? Any caveats?

Posted by: Marcovaldo

=> I was somehow disapointed from the first prints over the RPi:
- Some warping effect and also once had a print loose from Base plate (the standard, not the powder) coated, when printing PLA.
(All test before with MK3S were out of the box top quality and never a fail)
- The print time which showed up on the Octoprint Webinterface was always much shorter (for example 1:50 hrs instead of 2:30)

I read about Octoprint mangling gcodes (yes, it's designed to filter; no it only adds line numbers for error logging...)
But actually (as I was 100% satisfied by printing from SD Card) I do not want Octoprint to do any 'optimisations' as I do not trust any additional 'automatic' intermediate layer (would not trust a self driving car either 🙂   )

This is how rumors are being created...

Again ... Plain Octoprint installation does not mangle or optimize gcode. It's still send the same gcode instructions which are being passed through the USB interface as it would read from sd card. If you want a confirmation and more details, just contact the developer. I'm pretty sure she will be happy to clarify any rumors of this magic black hole "Octoprint". If you don't believe her, then just check the source code. It's open source.