Teaser: we are rewriting a huge portion of Marlin.

3D Printing
,
1

Teaser: we are rewriting a huge portion of Marlin.

I may regret it, but I’m letting the cat out of the bag. We dug into Marlin to see if we could get an esp8266 to connect to wifi and our cloud services. After cleaning out a bunch of unneeded, (non-Printrbot) code, it became more and more obvious we needed to extend its functionality for a variety of reasons. And it was painfully obvious that many things needed fixing. I can’t overstate that last sentence enough.

It’s not that Marlin didn’t work, it does. But so many things we found in there just didn’t make sense. Some features were poorly written, some were not apparently abandoned and some features needed improvement. In all, we determined that if we were to move things forward, we couldn’t build on top of the existing system.

Mick is our rockstar software dude and he has done a variety of things to the code to bring it up to a level that will allow it to reach new heights. It now makes good sense and is well organized. We borrowed best practices from several places and in the end, it isn’t Marlin anymore. It’s something better.

Programmers will appreciate the change. Some non-programmers may not fully get why it was necessary. But I wanted to go on record and explain why we did it and what people will be able to with it.

Keeping with our values and the requirements of the license, it will be open source. To be clear, though, we won’t be helping anyone with an endless list of features that we haven’t built into it. At least we don’t promise to do so. Printrbot has specific needs and we are laser focused on our own hardware, software, and road map. We wrote what WE needed and make no apologies for it. We hope people use it as the basis to meet THEIR needs, but will offer no promise of support. We will document how it works and the code (for the first time) is sufficiently documented. That is our contribution. We won’t go back and add in all the the various features and mcodes, etc that don’t suit our own purposes. While Marlin is currently a community project that serves many, we have made something that serves our purposes alone. That is not to say it won’t work for others, I’m just saying this “fork” for lack of a better term will be maintained by us alone. Forks of this new improved Marlin will, undoubtedly, go in wonderful directions but we won’t be guiding those projects.

A few features:
It works on stock printrboards. It should work on all of them

It will allow the printrboard to accept a shield we are making that contains an esp8266 for wifi and an ad card

It will connect via wifi to our cloud services and software to authenticate the connection and let you control it with our UI that works in any browser.

It will not be usable with any desktop software until someone writes plugins for octoprint, repetier and Cura… We think this is a good idea, and will publish the knowledge needed to do so, but we don’t intend to do it ourselves. We are going all in on our own software to try and improve the overall experience for users.

It will allow us to include our vendor ID, product IDs and even add unique serial numbers to each board. This means that our software will be able to identify what equipment it is running on and smooth out several pain points that is too much to go into right now. In short, it will get the user up and running faster without laborious configuration, changing settings and the need to understand the nuances of slicing for your specific equipment you are using.

It will track the version of firmware you have and ease the decision process and execution of upgrading firmware.

It will introduce a few new features that we are working on in our road map… Many that are not ground breaking, but would have been impossible with the current Marlin. More details on this later.

It has been a huge undertaking and may become the subject of healthy debate, but our hope is that a newbie won’t need to know any details about what we’ve done… It will just render Printrbot’s easier to use.

This project marks a major shift in Printrbot’s course: we are transitioning away from the use of today’s most common desktop open source software and moving to our own cloud based software. This will eventually make the need for a computer hooked up via usb a thing of the past and soon have people using their phones, tablets and computers to run their machines wirelessly. I think this is where the industry needs to go and we are hoping this helps others go there with us.

Writing the cloud software has not been trivial, but it opens the door for lots of nice features that are absent from today’s typical 3D printer experience. Checking on your print remotely… Running print farms or multiple machines from one device… Freeing up your computer from its tether (usb)… Bringing a modern UI to your phone- the nicest screen you own- instead of some janky LCD or expensive, but limited touch screen…ditching sneaker-net (transferring files across the room on an sd card)… Doing away with the need for complicated driver installs and antiquated requirements for usb on a dizzying array of operating systems -some which are super frustrating to install. It will be a step forward.

So there you have it. We are working on it but it’s not done. We have enough success under our belt to know it will work. The amazing thing, both from a business perspective and a buyer-friendly perspective, is that we are doing this on very inexpensive hardware. We expect the add-card to be around $50, bringing the total package with the printrboard to $99. This should put Printrbot in a category all its own on price and feature comparison.

Yes, someday, we will integrate an Arm processor and maybe take advantage of the newly announced esp32, but for now it’s not necessary. We will make those changes when the time comes. We will launch this as an add on card, and if it goes well, put it all on the printrboard later.

We still think Tinyg is the future for our higher end machines and CNCs, etc but this is doable now with existing hardware and will allow us to continue building out the software chain, in readiness for bigger changes later.

Brook

2

As an owner of a Printrbot printer, and other Marlin-based printers, if all you end up doing for the community at large is documenting the code, you have done a huge service to the community.
I look forward to pouring through your code and documentation.

3

@Brook_Drumm ​​ I can see the need for you to take control of the firmware driving your products. A kitchen-sink solution is not ideal for hardware vendors.

I do have one reservation regarding your Cloud solution. You need to consider the fact that organisations may wish to operate their own instance of this. They may have legitimate reasons for not wanting control of their printers to be from the general Internet.

Being closed-source (a decision you might wish to reconsider. Parts could be closed but overall it could be open source) you need to have a means to permit local Cloud installations.

4

Where is the repo?

5

@Neil_Darlow His current product lineup is more toward consumer users that likely aren’t going to have the same requirements as businesses. A proprietary cloud solution is a non starter for many perhaps most businesses. I’ve got six bots here, soon to be eight and they all run from a single workstation, via WiFi sharing a common file repository that can also be accesed from the Internet.

I can see how using an exisiting device, a phone for example, is a better interface and UI for many if not most consumers. The weak link is UX and UI and as a dev many of the open tools are cumbersome to work with or aren’t fully integrated. I think this is a trend we’ll see more where the larger player will dedicate resources specifically toward serving their own user base. Ultimaker has done it with Cura and it looks like Printrbot is heading the same way.

6

tl;dr “we are taking a cool piece of code and making it cooler, but we are also making it closed source”

7

@william_foster that’s not true at all. He’s simply saying that they’re rewriting it, the code will be available, but they’re not going to do stuff like add delta geometry to their main branch, when they don’t even use stuff like that.

The fact that they could rewrite this from the ground up, and close source it if they wanted to, but choose not to, should be commended. But I fully understand the need to not dump a bunch of their own resources into machines that aren’t their own.

8

The word is fork.

9

I see no problem with developing and maintaining a PB-specific fork of Marlin. Honestly, it makes more sense than dancing around the limitations of the existing code, and it gets to the point where you’ve added such specific code that pushing it back upstream may no longer make sense.

What does concern me is no out of the box support for existing software like Repetier and Cura. While I don’t doubt that the new cloud-based solution will be useful and popular for a certain segment of users, it certainly won’t be something 100% of the user base is interested in. There are people with multiple printers that are all supported by a single piece of software, telling them that they will now have to use a proprietary web based solution for one of those printers probably won’t go over well.

Granted support for the new PB firmware will probably be added to the popular printing frontends eventually, but the timetable for that is anyone’s guess, and I can imagine preloading this firmware on new PBs before the existing software has caught up may be problematic.

10

@dstevens_lv I wasn’t specifically thinking about businesses when I raised my concern over the Cloud solution. I was considering educational establishments who will be a target marketplace for Printrbot. They might want to exercise control locally over the content that their students publish.

I am guessing (and that’s all it is) that @Brook_Drumm wants to keep the Cloud solution closed-source because he somehow wants to monetize it. There is no problem with this but an open platform could still be developed for others to offer free content while closed-source elements could support the monetized aspect.

11

@Brook_Drumm Please make it compatible with the Printrboard revD and the SimpleMaker :wink:

12

To be fair, my solution, BotQueue, is and always will be open source. You can install your own version of the software, and several groups, including @LulzBot ​ have installed their own private system. I’m working on a newer version which will have many many improvements over the current version.

I figured I’d point my software out since many people don’t seem to know it exists.

13

@Justin_Nesselrotte It’s the first I’ve heard of it, looks very interesting.

14

Sorry - dumb question: Does the cloud solution stream the g-code to the printer or download it? If it’s streaming, then what happens if the connection is severed? Not all of us have highly reliable connections to the cloud… (certainly not reliable enough to trust streaming commands to a machine).

15

Seems like wasted effort trying to juice up the 8 bit AVR platform with add ons and code rewrites, rather than going to a better 32 bit platform with similar or cheaper processors, lots more CPU cycles, ram, and flash. The same thing applies with tinyg, although they at least have the tinyg2 (if it’s still active) project. For similar money there’s the BBB with an appropriate cape and a much higher capability environment than a 8 bit AVR with some other processor boards tacked on. That new pick and place line should be able to handle ARM processors just as well as ATMegas, and come in less expensive than the current beagle.

Not gonna touch the whole open source thing, but what happens when you take your Printrbot to, say, the local high school that won’t share wireless passwords, so there’s no “cloud” to rain on you, in our cell challeged remote area. Stand there with an embarrassed grin?

16

For the love of God please clean up marlin…

The rest of the stuff is cool too :wink:

17

I like the approach, it’s exciting, like take Ocotoprint and host it. It would certainly remove a lot of pain points for new users. However, here are some concerns. I’m probably an edge use case, but what happens when your printer, like mine, lives in a room with zero or at best poor Wi-Fi? Also if you have an outage in your service I can’t use my printer? No cloud no print. You’re cutting the usb cord but adding the cloud/wifi cord. It sounds like this is an add on so I assume the SD/usb option is still there.
I also think you’re going to create a flood of feature requests for the Marlin Devs :stuck_out_tongue:

18

Well, at least you can use the fork of marlin that I made that puts printrboard support back in. I’d push it to marlin devs, but it added some non-standard m-codes to support the DAC. If it does get pushed then you can use marlin without any build issues.

As for closed source, the printrboard will always be open as long as it’s based on the teensylu. The firmware will always be open as long as it’s based on marlin.

I am disappointed that this announcement doesn’t coincide with a new 32bit board. I have my own 32bit board ready for beta test, and costs will be marginal above the printrboard.

19

32 bit board is in our future, but this is low hanging fruit.

We will work to provide a no-wifi option, our preference is autodesk’s print studio.

Keep in mind, the printrboard will always work with Cura, repetier and octoprint and others w/o the wifi shield. And there will be benefits there too

20

@Brook_Drumm ​ So I’m a bit confused then. When you say in the original post that the new firmware won’t work with existing desktop software, were you only talking about the WiFi functionality? In other words, if you’re plugging into the board over USB it’s still business as usual (with whatever enhancements to the core firmware that apply to the actual operation of the machine)?

That does change things considerably. As long as users have the option to continue using their existing software environment, I’m all for adding options ontop of it.