PrintToPeer: Your 3D Printer on the Web

[DidierKlein 729]

PrintToPeer is a Raspberry Pi upgrade for your 3D printer, connecting it to the web and to mobile apps

https://www.indiegogo.com/projects/printtopeer-your-3d-printer-on-the-web

Worth reading. Looks interesting

 

[Daid 306]

Octoprint is free...

I'm wondering how they solved the major "network printing" problem, which is "is the printer free for use? or is there still a print in there?"

 

[DidierKlein 729]

Yes octoprint is free and seems to do quite the same...

 

Cloud slicing done right, and fast

Performance is important to us. We host Slic3r, Cura, and Makerbot slicers on powerful servers that are always fast and available. So you no longer need to have a beastly computer slicing your files at home. Access your slicer profiles from anywhere and share them with others.

 

 

Why should I pay if it is open source?

Your support pays for more than just the Raspberry Pi software - it’s also a lifetime subscription to our backend services (cloud-hosted slicing and STL repair service), which means you don’t need a beefy desktop next to your printer anymore. It also helps us build our open developer API, and helps us contribute to the future of 3D printing.

Specifically, what parts of PrintToPeer are open source?

Everything that communicates with your printer, and everything that runs inside of your network, is open source. That includes the Raspian-derived linux distro that we ship on the SD cards, and all of the software running on it.

Isn’t doing everything through the Internet slower than just using USB?

Surprisingly, no! Because we do slicing on dedicated, highly-optimized cloud servers, we can actually slice things faster than the average home computer can. We use websockets for communication with 3D printers, and in real-world testing the round-trip is barely noticeable (see if you can see it in the video).

What if I don’t have a very good internet connection?

PrintToPeer is designed to work with any kind of Internet connection, even the really bad ones. The entire print’s GCode is downloaded to the Pi before printing starts, so if you lose your internet connection mid-print, there’s no risk of print failure.

 

If i understand well the only thing that you be paid for is the cloud-slicing stuff. I don't really see the real benefits of this (i'm not a big cloud fan).

The interface looks more user-friendly than octoprint

 

[jonnybischof 60]

Slicing with Cura only takes a few seconds on a non-stone-age computer. I think cloud slicing is going a little too far...

Besides, gcode files can get pretty large, so the download will take some time, too. And you don't want to use a mobile phone for that.

Maybe it's useful when you want to actually slice stuff on the Pi. But why would you want that? I doubt Cura will run smoothly on a Pi when you rotate and inspect a part. Or maybe it doesn't run at all (total Linux noob here...).

 

[Daid 306]

Maybe it's useful when you want to actually slice stuff on the Pi. But why would you want that? I doubt Cura will run smoothly on a Pi when you rotate and inspect a part. Or maybe it doesn't run at all (total Linux noob here...).

 

Or, you only run the slicing part on the pi, not the GUI? Then you can actually stream the GCode from the slicer to the printer, and so you can actually start printing before the slicing is finished. (Pi-slicing is possible, people with Octoprint are already doing this)

 

[conz 0]

Has the 3d-printer (better the raspberry) to be reachable from the internet for this?

That would remind me on this nice project (by someone at the "Berlin University of the Arts"):

He searched for open printer and for open scanner around the globe (no hacks) and started to print and scan on them. The scans are sent back to him and on the prints he explained the action with a link to his page.

'To Whom It May Concern,' http://towhomitmayconcern.net/

http://www.towhomitmayconcern.net/pages/about/

I wouldn't like to see my 3d-printer to be started / stopped by some stranger on the internet.

 

[DidierKlein 729]

Well yes that's the thing... would be pretty fun to raise the temperature or change the speed of the printers of some random people around the world (or not :mrgreen: )

 

[jonnybischof 60]

Well yes that's the thing... would be pretty fun to raise the temperature or change the speed of the printers of some random people around the world (or not :mrgreen: )

 

...and burn their house down?

I will probably make a webcam stream (don't care if strangers watch my printer work...), and implement an emergency stop function which is activated by SMS.

There's a nice GSM-addon for the Pi which should be able to do that. But that project is still a few weeks or months away...

 

[tombielecki 0]

Hi, I am on the PrintToPeer team. Thanks for posting and your questions The interface is easy now and it will be even better in the future, we have a designer on our team working on it.

@Daid We use and enjoy octoprint but the system should be hosted and realtime so we rewrote it for high performance. We use a Pi camera to see if the print bed is clear, to check progress, and to tell you if the print was a success.

Slicing is in the cloud because the Pi is slow, and most STL files are already in the cloud. The slicers, interface, and Pi are updated so you don't have to update your software. Security is very important to us, so we use HTTPS/SSL websockets, and you don't have to worry about ports and firewalls.

We are considering a local interface if you do not want cloud slicing, but this complicates the system.

@JonnyBischof if you start a print from your phone you don't have to wait for the GCode download, that all happens in the background.

@Daid you do not want to stream GCode to the Pi, because if the internet cuts out the print will fail. With PrintToPeer the whole GCode file is downloaded quickly then can print all by itself, with robust reconnect logic.

 

[Daid 306]

@Daid you do not want to stream GCode to the Pi, because if the internet cuts out the print will fail. With PrintToPeer the whole GCode file is downloaded quickly then can print all by itself, with robust reconnect logic.

 

No, you do not want to stream from the internet. You want to send the STL file to the Pi. Slice on the Pi, and during slicing, stream the GCode straight from the slicer on the PI to the printer. That's what I'm suggesting. This means it does not really matter if the slicing takes 10 minutes, as you can start printing as soon as you have the first layer buffered.

(And with some tweaks in the CuraEngine you could have the first layer in less then a second)

GCode files are usually a factor bigger then STL files. And if you convert the STL to CTM, you would have even less data to transfer. Cutting down on possible failures. Especially after seeing GCode files well over a few 100MB.

 

[tombielecki 0]

No, you do not want to stream from the internet. You want to send the STL file to the Pi. Slice on the Pi, and during slicing, stream the GCode straight from the slicer on the PI to the printer. That's what I'm suggesting. This means it does not really matter if the slicing takes 10 minutes, as you can start printing as soon as you have the first layer buffered.

(And with some tweaks in the CuraEngine you could have the first layer in less then a second)

GCode files are usually a factor bigger then STL files. And if you convert the STL to CTM, you would have even less data to transfer. Cutting down on possible failures. Especially after seeing GCode files well over a few 100MB.

Hi Daid, these are good points, and I'm glad we can discuss the differences. It's interesting that Cura can start a first layer sooner, but we are looking to support every slicer possible.

If the STL is sent to the printer, the slicing will fail if the STL is not watertight (an extra file transfer!), and you can't see the GCode unless it is sent back to the web (an extra file transfer!), I think this is backwards. By keeping the client code as lightweight as possible, we give the Pi more processing bandwidth for complex toolpaths and/or running multiple printers at once.

By hosting many cloud slicing engines, there are very useful things we can do. We can update and add slicing engines without the user needing to update their software. We could slice across multiple slicers in parallel to give you the optimal toolpaths, or the optimal orientation of a part. We could mix slicing and FEA analysis in the cloud to find the strongest orientation and slicing parameters for a specific print. We could offer multiple visualizations of your GCode so you have a better understanding of how it will print.

Thank you, this is very constructive discussion and analysis. Can I send you our demo for more feedback? tom@printtopeer.com

 

[Nicolinux 288]

Guys, I think you are a little too early with this project. It may be cool when 3D printing will be fully mainstream, but right now, the amount of tinkering, testing, failing and testing again does not fit your concept. A normal consumer will only tolerate a failed print only so many times. And I don't think you can do magic. After a model has been sliced, it has to be inspected and a good deal of knowledge about FDM is needed in order to guess if a print will be successful. Except when you print really simple geometric objects - but how much fun is that?

Connecting a printer to the cloud might be useful, but looking at the 3D printer development - sonner or later every major printer manufacturer would want to do the same and would render your project useless. Makerbot already ships printers with cameras and I guess (hope!) Ultimaker won't take long to realize that remote mangagement is very useful (at least the emergency stop which can save you house is a must have).

I am not sure about your target audience. Those skilled enough will use OctoPrint and have no problems with slicer settings. And the others either don't have a 3D printer or don't care about cloud slicing.

Sorry for the harsh words. It is just honest feedback.

 

[tombielecki 0]

You asked and we listened:

We just announced the stretch goals of our campaign. You will be able to print directly from Sketchup and Thingiverse, and the software is going completely open source and free.

Check it out! https://www.indiegogo.com/projects/printtopeer-your-3d-printer-on-the-web/

 

[nick-foley 5]

I've used Octoprint and Botqueue extensively (logged almost 1400 hours on BQ last summer, about half that on Octoprint last fall) and I am extremely excited for PrintToPeer.

Octoprint and Botqueue both suck. Sorry to those devs who might read this (sure Zach knows and has moved on), but they are both stagnant, buggy projects that do a disservice to the incredible potential that exists with cloud-connected 3D printers. The setup processes are tedious and easy to do incorrectly; the UI's are slow and prone to failure. They are challenging or borderline impossible to set up with multiple printers, and they do a poor job of helping you diagnose problems when things go wrong.

Honestly, I hope this doesn't become another orphaned open-source project. I'm supportive of open-source projects, but so far, the open-source community hasn't done a great job serving this amazing opportunity for wireless printing. Hopefully a funded competitor can. I would gladly pay something like $5/month/printer for truly excellent wireless printing, queuing, monitoring, etc...

 

[nallath 1,124]

Slicing won't always fail if the object isn't watertight. It completely depends on how horrible the object is. Even so; there are some check that you can do to filter out most horrible objects (and warn the user). Non manifold tends to result in more errors then small gaps in the object.

 

[tombielecki 0]

The campaign is now successfully funded, I hope you can join to get early access to the features.

 

Slicing won't always fail if the object isn't watertight. It completely depends on how horrible the object is. Even so; there are some check that you can do to filter out most horrible objects (and warn the user). Non manifold tends to result in more errors then small gaps in the object.

 

Yes we are looking into ways to repair objects or at least detect the errors. Our partner 3D Hubs has Netfabb repairs already, so if you receive prints into PrintToPeer through their service they will already be fixed.

 

I've used Octoprint and Botqueue extensively (logged almost 1400 hours on BQ last summer, about half that on Octoprint last fall) and I am extremely excited for PrintToPeer.

Octoprint and Botqueue both suck. Sorry to those devs who might read this (sure Zach knows and has moved on), but they are both stagnant, buggy projects that do a disservice to the incredible potential that exists with cloud-connected 3D printers. The setup processes are tedious and easy to do incorrectly; the UI's are slow and prone to failure. They are challenging or borderline impossible to set up with multiple printers, and they do a poor job of helping you diagnose problems when things go wrong.

Honestly, I hope this doesn't become another orphaned open-source project. I'm supportive of open-source projects, but so far, the open-source community hasn't done a great job serving this amazing opportunity for wireless printing. Hopefully a funded competitor can. I would gladly pay something like $5/month/printer for truly excellent wireless printing, queuing, monitoring, etc...

 

Thank you Nick, these tools didn't match our needs either. Queueing is very important to us, and we know that it is to many of you as well.