You’re right. I wasn’t very clear on that first post. Everything will work as it does now but if you plug in the Wi-Fi and want to use it that’s available too.
Give me a board that’s easy to use, easy to configure and allows me to put it on a variety of printers, and while I will lament the ‘Open Source-ness’ I will still buy it. I have 3 printers that are proprietary in some way and they all still work all day every day. And well.
@Brook_Drumm What it the rationale behind supporting tinyg as the future?
A significant clean up and rewrite of Marlin is something people have been pushing for for quite a while, it’s nice to see someone doing it, even if it doesn’t contain support for every feature that old Marlin does.
If nothing else, this should be a good starting point for people who want to clean up Marlin but need additional features not available in PrintrMarlin.
That’s a good price point, too. I’m always impressed by just how much prices have come down since I started in on this hobby a couple years ago.
@ThantiK sorry, must have miss read it.
i’m very glad they’re keeping it open source,
and i fully commend that.
breaks my heart when companies that started from open source roots forget that.
@dstevens_lv Tinyg is doing things that will leap past the competition when we finish adding support for 3D printers. Alden and Rob are high level math guys. That puts it lightly. Too much to mention, but it’s cool stuff. I’ve spent enough time w them to know they are way ahead. If acquire them if I could 
Good stuff coming in 2016!!
@Brook_Drumm Whew! When I thought you were totally killing the ability to use Repetier / Cura over USB, I was really bummed. But yes, cleaning up Marlin and getting rid of non-Printrbot clutter (like Delta) makes a lot of sense for you. It will allow you to provide a better user experience. If I read this correctly, it’s more about adding flexibility and options than taking options away. Personally, I’m never going to run my printer from a phone, but maybe that’s just me.
Woah thx for clearing things up brook! Sorry for the previous trash comment (already deleted it). It’ll be great if your cloud software will have USB printing support, though, (and lots of print options too)
@Alex_Wiebe Any solution working with Cloud storage would need built-in resiliency.
At a minimum sufficient buffering is essential to allow for communication interruptions. Longer communication losses will require the print context to be saved and the machine safely parked so that printing may be resumed.
These are not trivial measures and they need to be carefully considered during the design stages.
I am a printrbot owner and I belive customization for printrbot alone is not a good idea. Similar to the situation with linux kernel on one hand there is a tendency to have a lean kernel for a specific device, on the other you want it to be standardized, so other software layers can built upon it. There is a lot of overlap in needs for Printrbot and other projects and I belive it would make more sense to have a single place where people can reuse their ideas. I would very much like to see contributions from many developers as oppose to a few dedicated developers for this specific code.
I have a Printrbot LC myself and I outgrew it before I started calibration. I would love to customize it into a Metal…hmmm…maybe a Simple Frame with the LC guts…hack hack hack!
Yes, we want to add options, not force anyone to abandon what they already like. I do think printing from a phone could make sense for everyone. If it works locally, it could simply provide a screen for a beautiful UI without the cost of a screen. Leveraging the screen in your pocket w/o giving up anything sounds good to me. Our personal print cue in the cloud would free folks from needing a dedicated machine to organize their files. The ability to run multiple bots in a print farm without the need of a computer will be cool, too, I think. Imagine you need to print 17 parts for a big build… The auto cue would spread the parts across open machines and when done, you signal that the printer is cleared of the last print and ready for a new part. The app will deliver the next fine and start automatically. This would also allow multiple printers to service multiple people too- like a school or hackerspace. Approved members could get in the cue from any location. Potentially, a 3D hubs type app could allow people to farm out their printers by submitting prints too. The app would know what equipment you have and match the requirements ifbthevrequedted print. Then after approval, you are off and printing w/o the manual slicing and file shuffling.
Brook
Now that’s a plan @Brook_Drumm
Will the cloud software be available for self-hosting?
Yes, not immediately, but we want to offer this especially for print farms that don’t have Internet available. I’ve heard some schools are quite restrictive w their wifi access.
@North_Woods Brook mentioned that you will still be able to use all the current software options (Cura, Repetier, Slic3r, etc), he is just adding this extra functionality to make a better user experience. Starting with an add on board for existing printrboards, but in the future maybe having it all on one printrboard. They are only adding functionality, not removing anything. You will still be able to use your printrbot without an Internet connection.
@Ryan_Branch the way I read it, you would only be able to use desktop software if you either don’t upgrade to the new firmware once released or you would have to wait for plugins to be released for the desktop software to support it.
Ok, tripping over my own feet here
So the wifi feature is optional and wifi is not supported in Cura or other open source products yet. You will be able to plug a usb cable in and continue as always- even with the new firmware. The firmware will always use the Ian connection if it’s plugged in. If you unplug usb, AND have the optional wifi board, it will work with our cloud software. We don’t intend to write the wifi software for Cura or other software, others will I am sure and we will open source the code for firmware, and publish anything needed to get community/manufacturers up and working to benefit from the wifi work we are writing. I only meant that our work will focus on our own software. We did a lot of heavy lifting to get the esp working with our Marlin derivative and while we are happy to share that work, we won’t be writing code for other platforms ourselves. The only exception will be to assist Microsoft and Autodesk with anything they need. I don’t know how Microsoft will react to this move, but wifi 4d printing has gotta be coming sooner or later to Windows. Autodesk print studio already has it - it’s a really great solution, but I think it does require Internet. Both companies want us to identify each of our printers automatically- something we have struggled with using Marlin. Now that can be fixed with our new firmware.
I have been thinking about this for a very long time- how to honor our legacy equipment and love forward at the same time. We added some functionality to Marlin (mcodes, auto leveling) at first but it wasn’t enough. This new push required a significant rewrite. We could have made it work w/o the rewrite but I think this is the right thing to do to see if we can get some new life and innovation out of Marlin.
Open source software is difficult when you get 200 cooks in the kitchen and everyone is writing for their own needs… The code turns to spaghetti and it becomes very difficult to navigate and code for w/o huge overhead as you navigate some abstract or just plain bad code that has been included.
This rewrite doesn’t throw the baby out with the bath water, but it does strip it down to bare minimums, brings sensible practices in and extends it by adding some smart features that have been lacking.
The current work is now integrating the cloud software infrastructure to dump the chrome app we made (a temporary hack to get a connection between the server and the printer), and connect directly with the printer via wifi. There is a lot more going on with the esp than we had in the chrome app.
We also are opting to integrate spark from Autodesk to take advantage of model healing and their slicer… Cura and slic3r are either lacking or too slow currently- at least on our test Amazon instance. Admittedly, we didn’t throw big iron at it, we are wanting to keep the cost low since it’s a free service.
Integrating w spark will allow the new file format to work and we can take advantage of other benefits that the spark platform is bringing to the table.
If you follow it closely, and I do of course, there is a shift happening among 3D manufacturers… Some are endorsing astroprint and other 3rd party solutions that have business models that include freemium, pay for premium files and features (kind of like in-app purchases) and paid storage. I want to hold off on all that as long as we can and make it free. There may be a time to offer paid services, but I don’t want to do any sort of bait and switch. We will likely offer quick links to buy filament, offer discounts to software users, and ntegrate customer support / troubleshooting.
I do think the 3D hubs business model is neat, and 12.5% isn’t a bad cut. Info greatly want to manage a payment system, so I’d prefer a small monthly fee to play (sell) and figure out how to get people to get paid directly- how I don’t know but I don’t want to be constantly dipping into people’s pocket if I can help it. If the cloud service takes off, I’ve got to figure out some business model if the bandwidth and storage fees get out of hand. The real worry is bandwidth, btw. For now, we will keep it simple, leverage autodesk’s free services and see how it goes.
Local software is fine too but there is additional hardware needed to run the server - this drives up price (beaglebone black or other powerful electronics are needed to reduce lag in slicing, etc) or it just ties up your computer (not a big deal to many). Local software also reduces the total feature set - you can’t connect to a file repository w/o Internet.
Figuring out how to find and download models is hard to integrate… Look at Cura. I’m surprised they haven’t fully integrated the youmagine repository yet. Running a file repository is also a thing I’m trying to avoid. We will get around it initially by just offering a few featured models to get a user up and running quickly. A browser plugin could hijack a downloaded model (say, an stl) and send it off to our server for slicing but I’d like to avoid clunky plugins. iOS requires a service running in the background from identify unknown file formats and could give you the option to open our app that maybe could side load the file to our service. A native app may make more sense to just use a browser to download the stl and move it to the server. Mobile phone/tablet 3D printing is tough to do without moving to a walled garden like MakerBot did w their app- they own the repository and you can only send a file to a MakerBot.
Anyway, the idea is to improve the user experience- and I have to be honest- we are doing this for new users first. Power users may not be interested in our cloud services b/c when you simplify, you either remove or obscure (hide) the power features.
While the adoption of consumer 3D printing has gone slower than I expected, Printrbot is still focused on newbies and getting bots into schools and homes that don’t have them. The current crop of 3D printers aren’t ready for prime time… It’s a death of 1000 cuts of little annoyances that all to often frustrate those w/o the stomach to push through a tough learning curve. We think that if we can lower the barriers to entry, new users will have better success and some power users will stop endlessly fiddling with all the settings and just get to printing. No offense to power users, sometimes the tweaking is required for challenging materials and situations, but we think a lot of people will be thankful to just hit print and get on with it. That whole 90% rule thing.
So that’s a little insight as to where we are going w this. It’s the big picture, but also keeping people happy who have legacy printers and existing requirements that don’t include the cloud.
One last note- we do think that forcing and encouraging some good practices with our cloud software will improve reliability. Correct heat up time, optimizing setting for different filament, keeping speed to sane levels, making firmware adjustments to upgraded hardware, healing bad files and using one slicer, etc. we also hope to add a couple of hardware pieces to improve reliability… Filament sensors, ambient room temperature alerts, maybe even QR codes on our filament to track problem batches and set all the right slicer settings. There is a lot of improvements in reliability / repeatability to be had but we have to reduce the variables - Unknown software, hardware and filament are the big ones.
Sorry for the long post, but appreciate the engagement and welcome feedback good and bad.
Brook
@Brook_Drumm That’s a good post. I think what happened is a) it wasn’t explained comprehensively and perhaps more important b) people hear what they what to hear. That’s particularly true when someone thinks they sense a threat to open source. People get all fired up to distribute the torches and pitchforks regardless of the need. When the message comes out “cloud, cloud, cloud, cloud” with nothing specfic for those that either can’t or don’t wish to use it consternation is being invited. The messaging is focusing on technology and not solutions even though that tech is providing solutions. This is a case of ineffective marcomm more than anything.
A few observations…
It won’t be the first Wifi offering. Perhaps the way you will do it may but Octoprint has been doing it for a while. I’ve even got a BBB here that thinks it’s a printer connected to Spark. It’s great that it’s going toward wireless.
This isn’t something that has to be built out on the network. I think if you run the financials you paying for that processor time, requests and network traffic is going to add up. You are distributing the power to AWS but any of that can be handled locally with an SoC for those without desktop machines. An RPi or BBB will slice. The RPi2 with the Cura plug on Octoprint works well though needs some implementation and interface work. If Cura Engine isn’t performing run it on a t2.large instance. If you are running it on a t2.micro instance on the free tier it will be a world of difference. but you’d still have to pay for it and I don’t see Spark being free once you start throwing several thousand users at it. I don’t see Carl’s board being keen to pick up the tab for thousands of users not using Ember or other for pay Autodesk products.
The reason the Marlin project is in the current state is a project management issue and not an open source issue. Plenty of closed source projects have that exact problem. Someone is approving those pulls and merging them. It’s not because the code base is open source. It’s what happens when you have too many coders and no project managers.
The reason the open source model has worked well for Linux is because Linus is a hard ass about what does and doesn’t make it into the kernel. Projects like Apache, PHP and Maria (pretty much the LAMP stack) all have coding conventions, roadmaps and a high bar for adding features. That didn’t happen with Marlin. I appreciate what they’ve done and I’m glad to have been able to use it but the project is in a world of hurt. I can’t even get the current release to build under the current IDE without it barking warnings and in many cases throwing errors.
Kids, what Brook is doing will become the norm for those that not only sell complete machines but for many kit integrators as well. It’s still open but it’s developed in such a way that one size doesn’t fit all. In the big picture there are only a handful of us that rely on a code base being open. Many of you are just making noise and that’s not helpful.
@Brook_Drumm When you stated "The firmware will always use the Ian connection if it’s plugged in. If you unplug usb, AND have the optional wifi board, it will work with our cloud software. ", what did you mean by the lan connection? Were you speaking of the wifi adapter you are working on, or is there another Printrboard with a wired LAN connection in the works as well??
That aside, I’m glad I misinterpreted what you were saying. That the plug-ins you were referring to were simply to allow for WiFi access to your cloud based offerings and that the traditional method of control will still work.
I’m a journeyman machinist by trade, and have been for nearly 20 years now. I’ve seen vast changes in that field. One of the changes I regret the most is the push to train new people in the field with CAM written programs without 1st and foremost teaching them how to manually control the machine they are operating. The skills learned by having to do things manually cannot be overlooked, but in today’s society, we do just that. We create simplistic methods to do things to make people feel good. This is like someone only being restaurant fed, they’ll never learn to cook for themselves. Learning the nuances of a machine tool (and every tool is somewhat unique), and learning how to overcome them is what builds knowledge… and knowledge is a powerful thing. I see 3D printers in the same light. Going through the learning process of making it work and seeing 1st hand what changes do what is what builds the knowledge to know what is going on when you don’t get expected results.
Now, all that said, I’m not against the cloud based project you have going as long as the manual methods are still available as you stated they will be. I’m sure I’ll even use them to see how well it all works. I’m definitely looking forward to eyeballing the new firmware code. Any chance there will be enough room cleaned up for a GLCD library??
Maybe I’m just an old grumpy man, maybe not… I don’t know. All I ask is that in your quest to make things as fool proof for the general masses as possible, don’t forget those of us who enjoy having full control over the machine we are running.
Please take this for what it is, just the ramblings and thoughts of a happy customer.