tombielecki

The campaign is now successfully funded, I hope you can join to get early access to the features. 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. 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.

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/

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

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.