Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prusa MINI: Smart and compact 3D printer

blog.prusaprinters.org

Post reply on HN
Print view View original

151–156 of 156 posts

Re: Prusa MINI: Smart and compact 3D printer

#151

Post by dual_basis »

dfasdfasd wrote: post #74
jrockway wrote: post #50

Earlier quoted context omitted.

The price seems fine to me. This is going to print a lot of useful parts for people and comes with great software for both your computer and the printer that you can hack and modify. If this is anything like my i3, then it's going to have high quality parts (Noctua fans!) and come in kit form to let you assemble it yourself so you know where everything is if something breaks and you need to repair it. I am surprised…

> While it is something Reddit endlessly complains about (despite having no software engineering experience) While I agree Reddit's obsession with weird technical details is annoying, this is a pretty arrogant position. I've written motion control code for both 8-bit and 32-bit designs, and the difference is bigger than "read a string and pulse an IO a few times". The Atmega has been outdated for the past 10 years, t…

> There is also much more advanced motion planning they could do with a little more power available.

But for 3D printing isn't the printer simply reading the instructions in the gcode? It's not doing any motion planning at all, that is all decided by the slicer.

Re: Prusa MINI: Smart and compact 3D printer

#152

Post by dual_basis »

jrockway wrote: post #103
dfasdfasd wrote: post #74

Earlier quoted context omitted.

> While it is something Reddit endlessly complains about (despite having no software engineering experience) While I agree Reddit's obsession with weird technical details is annoying, this is a pretty arrogant position. I've written motion control code for both 8-bit and 32-bit designs, and the difference is bigger than "read a string and pulse an IO a few times". The Atmega has been outdated for the past 10 years, t…

Sure, but now they are a small company that has to maintain two separate codebases. Even big companies like Google can't keep their Android and iOS apps at feature parity, so something has to give and it's the early adopters with old hardware that is just not going to get any new features. Or they are going to have twice the software engineering overhead. I get why you would start from scratch with an M4. I don't get…

I think that they're just using Marlin, a lot of the work is done for them.

Re: Prusa MINI: Smart and compact 3D printer

#153

Post by dual_basis »

jrockway wrote: post #58
j-pb wrote: post #54

Earlier quoted context omitted.

My guess is that driving that big color display and more importantly ethernet/ip stack would be a huge PITA on an 8bitter.

Yeah, I posted a few comments here without actually watching their marketing video, and didn't realize it had those two things. Upgrading to get those features seems like a good idea, to compete with the cheaper models. I don't think I would have engineered a new board and control stack just to get a web interface and a screen. Their last model (the i3 MK3S) has headers to accept a Pi Zero, and that seems like a good…

> I just want a USB serial port that accepts gcode.

From what I've heard, this is not reliable in the current implementations. If the computer goes to sleep, is under high load, or crashes this can result in a failed print. Of course you could build in more and more safeguards for this sort of thing (buffer the gcode, have some "emergency stop" movement which moves the head up and away from the print and decreases the temp of the hot end if there is a break in the stream of instructions) but this is a lot of additional effort when you could just as easily push all the gcode onto an SD card on the printer.

Re: Prusa MINI: Smart and compact 3D printer

#154

Post by dfasdfasd »

dual_basis wrote: post #151
dfasdfasd wrote: post #74

Earlier quoted context omitted.

> While it is something Reddit endlessly complains about (despite having no software engineering experience) While I agree Reddit's obsession with weird technical details is annoying, this is a pretty arrogant position. I've written motion control code for both 8-bit and 32-bit designs, and the difference is bigger than "read a string and pulse an IO a few times". The Atmega has been outdated for the past 10 years, t…

> There is also much more advanced motion planning they could do with a little more power available. But for 3D printing isn't the printer simply reading the instructions in the gcode? It's not doing any motion planning at all, that is all decided by the slicer.

No, on most CNC machines the controller actually handles much of the motion planning.

The slicer will generate a command that says go from point (x1, y1, z1) to point (x2, y2, z2) with speed f, but it doesn't say anything about acceleration, or how to transition into the next move. A very simplistic controller will use a trapezoidal ramp profile where it will ramp up to the programmed feed rate at a fixed acceleration, then stay at the programmed feed, then ramp down in time to reach the end point. However, if the move was a very short line or arc as part of a large surface, the machine doesn't need to reach 0 speed before starting the next move. A smarter controller will 'look ahead' to predict the next few move and plan the motion of the machine to eliminate jerkiness or stopping.

The slicer may tell the machine what acceleration to use, but that's really just setting a parameter in the machine controller, and isn't settable per-move.

This isn't as critical for 3D printers as it is for big, heavy milling machines. Nevertheless, you can do clever things like trying to compensate for vibration, or speeding up or slowing down the extruder motor based on the pressure of the plastic in the nozzle.

This isn't to say Prusa is switching just to do better motion planning, it sounds like that isn't a primary goal, but I'm trying to illustrate there is a lot more room for intelligence than 'just wiggling some IO'.

Re: Prusa MINI: Smart and compact 3D printer

#155

Post by dual_basis »

dfasdfasd wrote: post #154
dual_basis wrote: post #151

Earlier quoted context omitted.

> There is also much more advanced motion planning they could do with a little more power available. But for 3D printing isn't the printer simply reading the instructions in the gcode? It's not doing any motion planning at all, that is all decided by the slicer.

No, on most CNC machines the controller actually handles much of the motion planning. The slicer will generate a command that says go from point (x1, y1, z1) to point (x2, y2, z2) with speed f, but it doesn't say anything about acceleration, or how to transition into the next move. A very simplistic controller will use a trapezoidal ramp profile where it will ramp up to the programmed feed rate at a fixed acceleratio…

I see.

I can see some benefit to motion planning on the device if, for example, decisions are being made based on real-time data. For example, if there is a pressure sensor for the nozzle then the board could use this this realtime data to adjust it's motion.

If there's no realtime data being input then everything is simply a deterministic function of the gcode, and all of these aspects related to acceleration and jerk can be precomputed on your powerful multi-core desktop and "rolled into" the gcode.

Re: Prusa MINI: Smart and compact 3D printer

#156

Post by dfasdfasd »

dual_basis wrote: post #155
dfasdfasd wrote: post #154

Earlier quoted context omitted.

No, on most CNC machines the controller actually handles much of the motion planning. The slicer will generate a command that says go from point (x1, y1, z1) to point (x2, y2, z2) with speed f, but it doesn't say anything about acceleration, or how to transition into the next move. A very simplistic controller will use a trapezoidal ramp profile where it will ramp up to the programmed feed rate at a fixed acceleratio…

I see. I can see some benefit to motion planning on the device if, for example, decisions are being made based on real-time data. For example, if there is a pressure sensor for the nozzle then the board could use this this realtime data to adjust it's motion. If there's no realtime data being input then everything is simply a deterministic function of the gcode, and all of these aspects related to acceleration and je…

It can't be "rolled into" the gcode though. Gcode is sadly extremely limited, and while you could build some pretty complex extensions, there is no reason to avoid switching to a (cheaper) more powerful microcontroller to avoid building gcode hacks.

Regardless, I was just pointing out one place where a bit of extra power could help with printing. However, that's not really the point. It's not that the core _needs_ to be 32 bit, it's that most modern microcontrollers are 32 bit. The Atmega is more expensive, has less memory, no JTAG, no DMA, poor debugging support, and mediocre peripherals. The extra power to run more advanced motion control is just a bonus when you switch to a modern Cortex-M.

The real usefulness of power is the possibly to add other features not directly related to printing like built-in ethernet/wifi, or a larger screen (it drives me nuts that I can't see longer file names on my Prusa screen).

Post reply on HN