Finished up the printrboard marlin merge. I completely stripped the DAC library to the bare minimum. Also changed the M909 gcode so that it prints out the stepper motor current instead of the raw value. I find this much more useful.
A note: I find that this release versus the printrbot version uses up 25KB less program space, from 104k to 75k.
Find it here: https://github.com/StephS/Marlin
Very cool! Good job. We have a significant… I guess you’d call it a fork… Coming soon. Mick dug into the code pretty deep. He stripped non-Printrbot code as he came across it and is finishing rewriting how Marlin handles serial. We wanted to write to an sd card from the cloud and also have use of the usb cable when people want it. He also has implemented json to spit out all the m501 info plus some new stuff. We will be adding unique serial numbers to every board that is tied to your specific hardware setup and your account with our cloud services. The idea is to simplify slicing and material choice when slicing.
I am considering an optional QR code in an app to show what filament you are using to automatically set hotend temp, speeds, and heated bed temp.
The board we are making should be compatible with all legacy printrboards and even help to resurrect any boards that people have ripped off the usb. We will integrate into a new revG version but a stand alone board will be available.
The code will be open source but the stuff in the cloud won’t be shared. We hope other people will use what we’ve done.
Brook
Awesome, are you going to move to 32bit anytime soon? I know you focus on your products, releasing the source for those looking to modify, but reprap really needs 32bit at the price-point of what you’re selling the printrboard for. Your tinyg investment is outstanding, you’ll be a hero of the community, and people won’t know it (modesty always was your style).
Are you going to push for a new standard instead of gcode? At the same time, we need to move away from stl files.
And you should definitely use QR or even NFC. There is the ufid working group that has developed standards.
Tinygv9 (g2) is based on arm, so that’s the long game. The new board will work with any RepRap (not delta). While I’m I’m focused on Printrbot, others will be able to use it. It’s still gcode, but it makes sense of all the crazy add ons and moves a bunch of stuff to json. We’d love to push to get it as a new standard but time will tell. The benefits are undeniable. I’m pushing to have it include wifi and move the UI to a phone app or browser. There is still a rub between the choice of local control and control via the cloud, but I think the cloud is the right choice. Again, my emphasis is ease of use, not power (lots of power-user options) but that will be choices we make in software, not limitations of the electronics.
@Brook_Drumm So you’re making a fork of Marlin that is (more) compatible with TinyG’s protocols?
What I’d be really interested in is if your serial rewrites make it possible to print from an SD card and write to it over USB simultaneously. We should be able to start a print from host software, and rather than writing it to a ring buffer in the firmware as it goes, the code should be written to a file on the SD card as fast as possible (which with current architectures is pretty slow, but still much faster than execution) while the printer reads from the beginning of the file to run the print. I’ve also heard that the microcontrollers should be able to write to pull data over USB and send it to the SD card faster if they have enough free memory to write a full block at once, but I haven’t looked into the details.
Once I build the espressylu board I plan on giving some free to developers. It supports usb2.0 speeds, and native microSD support.
once we move from 8bit,anything is possible.
Whosa: since i’m not the programmer, I’m afraid I can’t speak technical details… But as far as changes… We are using an esp8266 with very light code that goes bare minimum to contact the Amazon web server, authenticate (a hash?? Whatever that is) and open up a port to communicate back and forth. It will report status to the cloud (like m501 stuff and more) via json to provide info about the machine needed to slice properly-- all relevant hardware, etc will be tied to that user account when they register an account and a bot. Registering multiple printers will be possible, b/c we are writing a unique id to the firmware that will be associated with their unique hardware. So we can talk back and forth. The cloud can send a file - the baud rate is limited to 115000 or about there. As far as I know it transfers the file then prints-- we will try to get the file printing as it loads the file but not sure on that yet. Communicating between the esp chip and the printrboard is via UART, we tried i2c but that didn’t work out. If you plug in a usb cable, that will override the wifi and you are back to normal. We still flash firmware with usb so that can’t go away. The change we made is how Marlin handles serial… The firmware was the only limiting factor so we are wiring our own serial driver (if that’s the right word).
Mick has been digging deep in the code and turned up all sorts of surprises. Big libraries of code that actually only use two lines of code… Abandoned features that were have finished, features that were good ideas but not finished (baby stepping), and all sorts of strange and obscure code that we’ve never heard of and appear to be unused.
We are forking Marlin for a couple reasons-- one is that we are discarding all possible features that we don’t need (non-Printrbot stuff) to make room, another reason to fork is that our changes will result in something that shares tons of code with Marlin but after we are done, definitely won’t BE Marlin… Lastly, the code in its entirety is just so bad that we see now that it would be too big of a time investment to fix it all… We can’t pretend like we are going to “fix” Marlin… We are not. We will be able throw out some bad code-- even code that some are using- and write some new stuff that suits our immediate needs. It is a bootstrap until Tinyg is ready for prime time. We don’t know how long that will take and we need to move forward with adding workable wifi and to continue the work on our cloud software and browser-based interface. We may even write some native iPhone app or something too. This will work on a printrboard for the near future.
We will open source it of course because we are standing on the shoulders of giants and are thankful, it is required and we want to be a good citizen. There is a line that many hardware companies walk… That line between what is ideal for all (expensive, even wasteful) and what is practical (low hanging fruit and what is profitable). We do hope some other manufacturers or community members will run with what we’ve done and maybe make the main branch of Marlin more healthy, but we know that may not make sense for them.
We will publish our protocol so others can comminicate with our board and either use it for their purposes or write software or plugins that can talk to it. We think that WILL make sense for some…, like a Cura plugin or an octoprint plugin.
We also hope we can get autodesk’s attention to allow print studio to talk to it via wifi so you can print to it untethered.
So that’s the deal.
Brook
@Whosa_whatsis I am planning to put SDRAM onto my final hardware to permit (Inter)net streamed printing. The ultimate goal is for Printing-as-a-Service where users can do single-click printing of prepared objects (the printer and service would negotiate material requirements and material profiles would be streamed along with the object to the printer).
So the calculation for amperage is messed up, but i’ll be able to upload a fix soon.
Other than that, I loaded the firmware on my printrboard and I’m happy to report that it works 100%.
I’ll see if I can add proper configurations for all of printrbots products, but right now I’m using it on my prusa i3, so personally I’m not in a hurry because I’m selfish. Eventually I’ll do it because I want to load multi-point bed levelling on all of the local libraries printrbots.