Render

Thanks, dudes! Yes, I like that too. Tinker firm is full of little things that I really like. But I'm not sure if that kind of expert info should stay in the land of geek-mode firmwares. I need to set a limit somewhere and I find it logical to say "to show only parameters that can be directly modified" (with the exception of Z height, that I find it really useful to know even If no baby stepping is done). What Tinker is actually doing is to calculate the volume of material looking at the length and speed of the extrusion. This is not really a translation of the flow factor but a final consequence of many things. On the other hand, thanks to the scroll, it's easy to include additional data anytime because I don't need to find a place where to draw it, so It's always possible to implement new items without redesigning the whole interface. The door is open to new features, but they are not on top of the TODO list. BTW, I understand that comparisons are almost unavoidable, but I want to say that I'm not trying to create some kind of aesthetic/graphic version of Tinker firmware. Tinkergnome is much more experienced in Marlin workflow than me and he focus on advanced features that I would need to study and learn from his code. My background is closer to PC and mobile games, I like to build graphic frameworks so all my effort is going to modify Daid's code to extend the graphics lib and to optimize the UI

Thanks Labern I supose you ditn't see it for the first time because I only select that item in the demo but I don't change the value as I do with the rest. The reason is I haven't yet implemented baby stepping (and I don't plan to do it for now).

By main screen I guess you mean the top of every single menu, the current "temperature bar" in my code. The thing is, It needs to be compatible with dual extruder and also with this "split view mode" thing, and Z height takes 6 digits max (w/o icon neither measure unit "mm"), there's no room for anything else without swaping/scrolling it. On the other hand, I can't think a situation where I find necessary to see the z height all the time, I only need to know the exact height if there's a print in process/paused or the printer is controlled by USB, otherwise I will only need to know if it's up or down, that unlike temperatures, is something I just need to look at the printer to know. Even If I want to move the buildplate without printing, I think I would create another option inside the buildplate menu to move it "manually" and to see Z height. I mean, you can't do anything but raise/down the platform from the main menu, why do you find useful to know the exact position outside the print screen?

Thanks mates! The truth is that I'm pretty happy with the overall look and feel, and specially with the print screen. After going back and forth with several designs I ended up with this split screen concept. The transition between advanced users and amateurs not depend on an initial question that the user has to decide what level of skill has. It's just there if you want to know or tune anything and it's not if you want to KIS anytime. On the other hand, even less advanced users need to know how to use a slicer, how to deal with material properties... Peter, I haven't published the project yet. I'm still working on the basics and it's not fully functional for the time being, but the hardest part has already been done. Now I have to focus on cleaning and refactoring a bit, also there's a couple menus still to be done. I plan to release some alpha versions before going to beta and RC, so if you're interested... And of course, I will open the source then

Another demo. Print menu already implemented. Most of my time is going to refactor and optimize code, otherwise the flash allocation size exceeded 128K, and this has forced me to study and solve other problems. It's being a looooong way. BTW changing motor steps/mm is already implemented, it was one of the first things I did

Nicolinux, your program exceeds 128K of flash (134910 bytes) and I guess you're dealing with a problem related to AVR. Daid talked about it a few posts before yours, and you can find the workaround he did here (only if you are using make to build the firmware). The thing is, if function pointers are used (and they are), their targets should reside in the lower 128k of the chip, so you have to force the linker to start with those files. So, edit the makefile and move "electronics_test.cpp" from the end of line #221 to the end of line #216. This will solve the warnings. On the other hand, you have to consider this matter for any other files that you create if they have function pointers targets. By the way Daid, does this issue affect MarlinSimulator? I guess the environment doesn't consider this kind of low level stuff, but I've been finding a weird behaviour since I exceed 128K and I'm not sure if it's related. Everything goes right but sometimes, when I close the simulator window, it won't return to CodeBlocks, instead, Windows complains about the program not exiting fine. Also, if you are not using make to build your releases, are you dealing with this problem within CodeBlocks? I mean, you don't need to because Ultimaker2Marlin doesn't exceed 128K of flash but, have you done the same workaround in CodeBlocks with compiler and linker settings? I will love to also have your CodeBlocks project for Marlin besides MarlinSimulator, would it be possible?

Yeah! I've attached a rocket engine to the printer to make things faster Yes, everything is related to the simulator, Daid already talked about this weird behavior, nothing to care about. And yes, I agree with both statements: info density is not a priority but I try to make the paths shorter (and related hierarchically). I'm focusing on aesthetics and intuitiveness, but the thing is, this way brings faster access to some parts of the firmware than going throw the current menu structure, it's not about a beauty but useless screen. On the other hand, the print info screen is where info density becomes crucial (or not, depending on the user needs), I haven't worked on it yet, It's a pending task. I'm also turning an idea since I started this project, something that I already discussed with tinkergnome: the possibility of allowing the user to configure the menu options. The concept is very clear to me, I would create another icon in the main menu, a quick-launch submenu where the user selects icons as shortcuts to any other node. Then it should be possible to choose to start at main menu or quick-launch menu, both also accesible from the other one. The problem is the way it has to be coded, this is a modular approach, the one I'm used to work with OOP, but currently the menu system is very hardcoded and I should rewrite a lot. For now I'm still working on the main UI, the ToDo list is huge! Thanks for your feedback

So, here I am... This is the current state of my creature:

I've been out of town a few days and I could not write until today. I'm on vacation this month and will not be able to work in the firmware. geert_2, I don't think that all the information you mentioned fit on one screen at once, at least not with this font size, but basically these are all things that I intended to draw on the print screen. In my other printer firmware (also with a 128x64 display) I have less data on the screen and fill almost whole, but on the other hand, use margins, spaces, icons and boxes to make a more aesthetic design. Of course some parts can alternate, or to use a different font for certain data. Anyway, I need to work on it and to make test to know what can I do. As tinkergnome told you, babystepping is what you are looking for. Since this is already coded in Marlin, it can be adapted to UM2. The thing is, as tinkergnome also mentioned wisely: the time. The priorities in my to-do list, the fact that every feature I can add to the firmware takes a lot of research, code digging... and then, start doing the job. But yes, this is something I know I'm going to need and something I would like to add. Tinkergnome, you nailed the point. My main concern about going open source is how long can I maintain the project, I mean a project with version control. Maybe I will only publish the files periodically and I won't use git. I already have designed the menu without scroll, with two rows of 5 icons + bottom text and also another design with 2x4 + bottom text + extruder and buildplate temperature info. This was my first version (and also the design of my current P3Steel firmware). I like it but, the truth is that I really liked the scroll easing and the minimalism of Daid's design when I saw it, It's basically the opposite of what I was used to: lot of information and functionality over aesthetics. I guess it was one of the priorities of Ultimaker when they designed their whole machine, something like "what Apple would do if they make a printer", but fortunately open source This machine is beautiful as no other, It works well enough to not have to be so aware of more technical aspects that are crucial in many reprap printers. So, after I tried my old menu system here (5x2 icons) I felt like that was not the thing I was looking for, I want to keep that sense of minimalism not filling the whole screen and to try to be closer to Ultimaker style, but also adding many of the things that I use to need... and graphics, I love displays with graphics On the other hand, what would be the point of doing a geek style firmware if you are already done an awesome one? This is something I wanted to talk with you, I'm not going to create another expert version of Ultimaker 2 firmware, my intention is to focus on a intermediate level interaction. I already have a machine that meets my geeky needs! This one has to be beautiful and elegant or my girlfriend is going to throw me out of home! But also, if I'm working on something that I like to have, why not share and ask the people what they think. If there's anyone looking for something like me, I will be proud to share my work. You know exactly what involves making the menu editable at runtime, handling the types and the callbacks is a pain in the ass. Letting some kind of configuration/reordering is a possibility that I have in mind, even to allow selecting between Scroll / 2 rows and stuff like that, but trying to convert the system to structs or arrays to get a fully customizable menu is hell! Thanks for your feedback, of course I'm interested in your opinion

Ultiarjan, yes I know the tinkergnome firmware and I plan to add many of its options as well as print info / tune options. I wanted to start with the UI to arrange the structure and the main appearance, but I've already worked in a custom firmware for my Prusa i3 Steel with this kind of features. In fact, some of the options we are talking about are already present in reprap Marlin firmwares. My intention is to create a hybrid that keeps the simplicity of UM2 and the advanced options of reprap versions / tinkergnome firmware. On the other hand, part of my effort also goes to allow an easy implementation of UM2 Marlin updates without re-coding and digging too much so I need to adopt the way Daid works and his nomenclature pattern. I appreciate your feedback and I'm open to any suggestion. Thanks guys!

I'm working on a custom firmware for Ultimaker 2 and so far I have focused on the UI of the main menu. I have restructured the original menu options into something that I personally find more intuitive. Unlike the original, it is structured according to the different parts of the machine, as well as all submenus are based on a single main menu (a dock with icons), it reduces the number of keystrokes required for most options. For the development of the start menu I have tried to keep the minimalism of the original interface and the feeling of deceleration (easing) on the scroll. You can see a demo running on the Marlin Simulator here: The video gives the feeling of lack of smoothness in the movements, but because of the capture. I'm using a Windows virtual machine on OSX which in turn makes a Marlin simulation, as in Rick & Morty, a simulation inside a simulation... Running on the printer looks really great. I have only implemented some extra functionality for now, and I'm working on the preheat menu, but the list of changes and updates that I have in mind is quite extensive. I want to know your opinion on the overall appearance and structure of menu options. And of course, in a later time I will open the source.

I though I wasn't revealing the secret if I just write the function name as It's already there for years, but now I'm not sure if I shouldn't say anything... I think I'm gonna edit my post... Sorry Daid

........ooooooorrrr to be working on a custom firmware and find the function ******************* by accident Sorry to recover such an old post, I needed to know if humanity had discovered your easter egg and I've found this

It depends on your interests and your background. If you're only interested in changing the E steps once and you don't plan to modify anything else or to create your own custom firmware, certainly it won't be the fastest way to do it, you just need a couple of G-codes to do the job. In my case, I love robotics, programming and electronics, I've build my printers from the BOM and schemes. I modified original parts to match 1.75mm filament/PTFE needs, changed the feeder, tested different drive gears... and I'm also coding a custom firmware that fits my taste and needs... So to answer your question: You don't have to edit Marlin, it's only the way to do it if you want to. I was only answering the cuestion he made about building firmwares from source.

Although you've already solved your problems thanks to the awesome TinkerGnome, you may still interested in knowing how to modify E steps in the firmware and how to compile and upload the program to the board. To answer your question: yes, basically the process is the same as with any other version of Marlin in any other Arduino board. There is only a problem with the Wire library that comes preinstalled in the Arduino IDE. There are different ways to avoid the problem but maybe the easiest way to solve it is to just remove the lib folder from its location. Go to the Arduino IDE library folder (".../Contents/Java/hardware/arduino/avr/libraries") and remove (or move outside) the one called "Wire". The Ultimaker 2.x PCB is based on Arduino Mega 2560 so you can choose that board in the IDE and it will work perfect. Now you can download the official firmware from Ultimaker's GitHub: Ultimaker2Marlin where you'll find a "Marlin" folder, this is what you've to copy to your Arduino projects folder. And finally, I don't really get why don't you already know where to change the E steps since you already have done the same with other reprap printers. You have to edit the same "Configuration.h" file. Find the line: #define DEFAULT_AXIS_STEPS_PER_UNIT {80.0, 80.0, 200, 282} where you specify the {X, Y, Z, E} steps, so change the last number to whatever you need. It's important to remember that once you've uploaded the firmware to the board, you have to do a Factory Reset from the printer's menu for this setting to be updated.