OctoPrint
octoprint.org
octoprint.org
The only downside I've found is I've lost the Ender 3 Pro's resume ability if the power goes out.
Asking because if it's a guess, then the electronics + stepper motors need to be factored in too. :)
Such as having an ATX midtower size 'gaming' desktop PC with an 850W power supply, that might be measured at 350W at the wall under full CPU+GPU benchmark load.
Generally when folk express concern about running random equipment on an UPS, they are concerned about peak power rather than energy capacity.
I'll also make the claim that most hobby grade 3D printers come with power supplies that are barely adequately rated for the printer's peak power, so using the supply's rating is probably in the right ballpark.
Edit: ah, I interpreted the thread a bit differently. Ignoring the UPS rating aspect, yeah the average power draw will likely be a fraction of the peak. My guess would be around 100W total for most Prusa style printers printing PLA. The stepper motor draw would be highly dependent on the speed of the print and the shape of the part, since power draw will be highest when accelerating at higher speeds.
If you have a UPS with, for example, 4 x 12V 8Ah AGM batteries, it has a certain amount of Wh you can realistically use before you deep-discharge the batteries into severe damage.
Taking that use case to the extreme, maybe someone lives in an area with very unreliable utility power. They might absolutely need to have enough energy stored to run their 3D printer for an entire print. Maybe they solve that with lots of batteries, but in many places with unreliable utility power, it's more likely they're just going to fire up a gas powered generator whenever the power goes out. Once again, the UPS only needs to last long enough for someone to notice and fire up the generator.
Folk certainly might have more exotic use cases. Maybe someone lives completely off-grid and powers their 3D printer off of solar panels, and a generator isn't a sustainable option. They'll definitely be more interested in energy capacity.
The power capacity seems important no matter what, since exceeding it will either result in a voltage brownout, tripping of a protection circuit, or melting something.
Hmmm, that seems more like a "maybe" thing? Stepper motors seem to draw a bunch of power when trying to hold position (eg not moving).
They can get very hot, needing heat sink + cooling, that it shows up pretty quickly when they're holding position.
That being said, many drivers seem to have options for lowering power consumption when holding.
Personally, I'm more used to CNC applications rather than 3D printing. So it might just be more noticeable for CNC things... :)
Conceptually though, ignoring any power saving idling features or other fancy algorithms, stepper drivers basically want to drive a constant amount of current through the active phase (which is what you're adjusting with the potentiometer). In order to do so, it needs to overcome the voltage drop of the resistance of the windings, and the induced voltage of any changing magnetic fields. The resistive voltage drop is roughly constant, while the induced voltage is proportional to the speed of the motor. Power is equal to current times voltage. The current is constant, and the voltage increases proportionally with velocity, and so power should go up proportionally with velocity. The motor gets hot regardless of what it's doing because of the constant resistive losses, but the total power goes up the faster the motor is moving.
Motors are a lot more complicated than that in reality, and higher end stepper drivers don't actually drive constant current at all times. Semantically, a stepper driver's promise is to move the motor one step "quickly enough" after each pulse on its step input. A clever stepper driver will only apply current when it's actually needed to produce useful torque. Torque is only needed when the motor/load needs to accelerate to get to its target position. Ignoring the rotational aspect, force equals mass times acceleration, and power equals force times velocity. For a maximally clever stepper driver, power is therefore proportional to the product of acceleration and velocity. The motor only gets hot when accelerating regardless of velocity, while the total power goes up when accelerating at higher velocities.
Watch 30-ish seconds starting at 2:57 here: https://youtu.be/Hvw3DrVAeTA
Also, the micro SD card slot has never worked well. For a while I had to be very gentle when inserting micro SD cards to have them stay in after the click. Now micro SD cards never stay in. I haven’t found any references to this issue with 3D printers online, but from what I can gather it is an issue seen on faulty micro SD card slots in other equipment. My fix has been to buy a micro SD card extender (flexible PCB), duct tape it in place, and pray it doesn’t come loose. It survived a 3 day print so far.
[You can fix this if you're using Marlin](https://www.reddit.com/r/ender3/comments/btjk22/octoprint_is...), since Marlin allows you to configure the buffer size. Generally more buffer is better, but do be aware that increasing the buffer size will cause the printer to be less responsive to the "stop print" command on octoprint (since the printer will continue executing the commands that have been buffered).
I use Marlin 2.0.1-bugfix branch for firmware because stock creality lacks some useful GCodes (such as for print pausing) but otherwise I did nothing special.
I'm also using OctoDash (https://github.com/UnchartedBull/OctoDash) on the Pi which is mounted onto the printer with the Raspberry Pi 7" touch screen (https://i.imgur.com/p8Mf5Em.jpg) and removed the stock screen.
I upgraded my printer's motherboard and didn't even bother to connect the screen and dial, Octoprint is now the printer's GUI, as far as I'm concerned.
- Terribly slow startup and load times.
- no support for mobile devices just with some app.
- While it can do lots of things with plugins they tend to kill performance which might cause artifacts on the print.
- slow on updates, they ware on Python 2.x until this year.
I'm currently migrating to mainsail (https://github.com/meteyou/mainsail), which looks much better.
All in all the main maintainer, which is working full time on it, is communicating well with the community. The iteration cycle has become faster during this last year, and updates seem to be rather stable.
Regarding the performance killing plugins, never had a problem on a RPi 4. What are you using?
I guess if you have reason to want process pictures?
Edit: plus visualization for auto-bed leveling is amazing trying to fine tune the printer bed.
These are the plugins I love so far. I guess it depends on which printer you have but these are all amazing for my uses.
1) It isn't pleasant to be near many industrial machines. Chemical vapor/off-gassing can be a real problem, so on top of the usually loud metal-component motion systems/gantries you have loud evacuation/exhaust fans. One place to deal with webcams/remote features on many machines at once is convenient.
2) Real time notifications create less machine downtime. A thermistor failed so a machine stopped mid-print? This time can be salvaged by a notification to browser or mobile for quick repair rather than discovering the issue by returning to the machine at the supposed end-time and being greeted with a non-finished print.
I now have a Prusa Mini, which is quiet and small enough to live in a cupboard in my office. It's far more reliable and the print time estimate is so accurate that I don't need Octoprint any more. It also has a USB port instead of SD card, so walking across my office with a USB stick is a viable alternative to sending jobs directly from my desktop browser.
So I guess it depends on your printer - if it's noisy, large, unreliable or you have lots of them, Octoprint is a godsend.
It depends what you envisage by 'remotely', I don't imagine ever starting a print while not at home, but I do want to sit at my computer, slice, and send straight to the printer; without faffing about with a USB stick.
I've got no interest in shuffling around sd cards in order to print models, nor do I want it connected to my primary pc that gets rebooted regularly.
And in their defence, I've been running OctoPrint for about 3 years and never had an issue with it across any updates.
as an RRF user I hope to see those features move over one day.
It's planned. I'm unsure if I like RRF or Klipper more, so kinda keep up with both.
input shaping allows one to get rid of mechanical resonances without re-engineering the motion system on a printer. It's pretty unique to klipper -- but it's one of those features that I suspect is brilliant enough to where the other groups who develop such software will probably follow-up with their own variations.
I've spoken to a few people on klipper who are inputing the variables for compensation in directly from an attached accelerometer on the printer frame. That'd be the way i'd want to go rather than taking a pair of calipers to the ringing artifacts on the print itself.
And there is an unofficial app: https://play.google.com/store/apps/details?id=com.kabacon.oc...
Even on a Pi 2 with a plugin heavy instance (TouchUI with custom theme, octolapse, etc) the web interface loaded acceptably fast enough.
Python 3 support was in Beta/RC for a very long time intentionally so plugin authors could update.
I spent a while wondering why octoprint wasn't responding to http requests before sshing in and seeing python using 100% CPU.
mariner is obviously not as fancy and sophisticated as OctoPrint, but I'm happy to take pull requests and improve it. Since MSLA printers are quite different from FDM, I found it would be simpler to write mariner than to add support for MSLA printers on OctoPrint.
Fantastic project.
The SideWinder was a breeze to setup. I need to sit down and spend a day hooking up the Duet though - gonna try using https://github.com/kriechi/DuetRRF-timelapse
I also found it super easy. The most difficult part for me was finding a data capable MicroUSB cable to connect the Pi to my printer. Most of mine were only for charging. I used an old RPi 3 and used the OctoPrint SD image. After that, everything just worked. It even worked with my USB webcam instead of the default RPi camera.
This was connected to a Creality Ender 3.
It might be more difficult to install as a package as opposed to using a pre-made RPi image, but it should still be pretty straightforward.
https://www.reddit.com/r/3Dprinting/comments/lv818a/purchase...
They are by no means perfect, and calibrations/adjustments come with the territory, but they have a certain threshold for quality that removes some of the most horrible sources of errors.
Eg, flex in the structure often comes from cheaping out on material or design, and is imo the worst kind of sources of errors. A static error (eg a fixed offset of the bed leveling) is more easy to calibrate/compensate away.
Other big brands may be as good as Prusa, but I have no experience of them. A friend got an Ender 3, bed was warped, replaced the unit, bed warped on that one too. Our Prusa mk3s2 had no such kind of quality errors. YMMV.
Some things I learned:
* do a z-level calibration (finding distance for the first layer) according to guides
* increasing temp (bed and head) by 5degC on first layer increased adhesion
* clean the bed with IPA only, that's well enough if you never touch it.
* never touch the bed with bare hands - I always used tissue paper as a glove
* never needed to use paper glue or hair spray or anything after the above things (but before that I used paper glue which didn't help, and was haaaaaard to remove)
* don't scrape the print off with the metal spatula, it'll scratch the bed surface easily
* when turning on the printer, don't use the small amount of filament that's been sitting in the print head since last time. Back out the filament and cut that off and start with new filament.
All that said, Prusa seems to be the benchmark.