nerd fork

[selmo 0]

I spent a day this week and took some of the additions I made to Marlin for my Printrbot and brought them over to the UM2 firmware. I also added some UI info to help diagnose print quality issues while printing, like showing extrusion flow, head speed, extr temperature, buffer depth, etc. I also added more audio feedback, faster sd card listings, fixed a couple bugs, etc. There's a list of changes on the github splash page, as well as a pre-compiled hex binary.

https://github.com/norpchen/Ultimaker2Marlin

I've been testing it for the past day or two and haven't found any major issues. But that's not a lot of testing, so use at your own risk. But if anyone finds any issues, please let me know (via github's issue tracker)

This firmware isn't for everyone -- if you never use the "tune" menu during printing, stay away from this. This version is more "nerdy" -- showing more information, more noise, more colors, etc. and that may not fit with everyone's tastes or the official Ultimaker aesthetic. I made it because I wanted to know more about what was going on inside and I like to tweak / customize interfaces. Personally, I found the live extrusion volume value during printing very helpful when trying to figure out an under-extrusion issue.

Anyway, I'm putting it out here in case anyone wants to play with it. If there are some parts UM finds useful, I can make a pull request.

It's currently in sync with Daid's June 5 14.06.1 Ultimaker branch on github, so it has all the latest fixes, etc. I'll probably continue updating it and adding crap, fixing any bugs I find, maybe adding a few new bugs, etc. over the next couple days....

Here's a couple sample pix:

 

[Daid 304]

Cool stuff

I hope my code wasn't to horrible to work with

 

[IRobertI 516]

You beat me to it, no surprise there I started tinkering a bit with something similar a while back but my progress is painfully slow. Maybe this means I can quit.

edit: @daid, for me it is

 

[selmo 0]

Asking one programmer to comment on another's code is asking for trouble! Seriously, there was nothing too ugly in there -- everything was well named and even the menuing callbacks were reasonable to work through. I'll probably look at moving some of my tweaks into the menus as user preferences instead of configuration.h constants.

My biggest complaints are with Marlin originally. Probably the biggest thing I'd like to change is to bring in a string class. All this c=buffer *c++='\0' strcpy_P business is tedious and error prone. Life's too short to be directly manipulating C strings. One doesn't want to diverge too much from Marlin, as that makes it hard to sync back (same goes for my fork vs your source) -- but for files like the UM2 menus, where you do a lot of work with strings and don't have to worry about sync back, I think it would be worthwhile. We've got plenty of code space on a 2560 (unlike on a Printrboard, which has half that) -- so I may look into that just to make everyone's life easier.

I saw you added lifetime stats recently. I also added that to my Printrbot fork. I haven't looked at your implementation yet, but it would be interesting to compare notes. I did notice you added some printer state information, which is something that Marlin really needed all along (and is required to do lifetime stats). I did too, introducing State and Job objects to encapsulate those concepts (but that change was wide reaching across the codebase, which made it harder to back-sync going forward -- luckily the Marlin base moves slowly these days).

I also added some G-codes to manage stats and the metric of a "degree-hour" to track temperature of the bed and extruder, which lets you calculate average temperature of each across the lifetime of the machine. For example, that could be useful to track how much heat the extruder's plastic / teflon parts may have been exposed to over it's lifetime, or how hard the heater Mosfets have had to work. You can find it here: https://github.com/norpchen/Marlin

 

 

[selmo 0]

There were also a couple other ideas I implemented in that Printrbot Marlin that I'll mention:

First -- a G-code to update "progress" at periodic intervals within in file. Basically a percentage done at that point of the file. (I used M73, which had Replicator already defined for that purpose) I needed it for USB hosted prints, where the printer does not know the filesize. The slicer can pepper in G-codes, showing true progress rather than estimates based on SD card file position / filesize, thereby giving a more accurate time-to-complete estimate.

Second -- I added a "quality" Q value to the G1 command -- basically the slicer tags each movement with a desired quality level, which lets the printer decides how to best achieve that. In Printrbot Marlin, I implemented that as adjusting jerk, max speed, acceleration, etc. for each move planned, based the Q value. Slicers currently adjust feedrate based on quality desired, I think it's more flexible and smarter to let the printer decide how to best achieve quality. Maybe it doesn't need to retract for support material? Maybe printer model X works best with a higher jerk on unimportant extrusions? etc. Philosophically, this is similar to how the material settings have been moved into the printer in UltiGCode.

Both of these ideas are really dependent on having cooperation with the slicer developer...which is possible here.

 

[sergiucip 0]

Hello , just a quick question:

How do you change the ultimaker logo with the robot,picture? Where to look?

Thanks,