[PrintToPeer: Your 3D Printer on the Web]

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.

 

[PrintToPeer: Your 3D Printer on the Web]

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/

 

[PrintToPeer: Your 3D Printer on the Web]

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

 

[PrintToPeer: Your 3D Printer on the Web]

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.