lars86

@mariuszem, I find that hard to believe. What do you mean you "hear scratching". That is not how you would determine a failure to clamp the belt. If you want to check belt holding, grab the belt near the block in one have, grab the block in your other and give a tug. You should see no movement between the two. Are you running GT2 belts?

Mine are superior.

About how much did the frame components cost you? Post up some pictures!

I bought a couple rolls of Polymaker PolyMax PLA from Printed Solid, and like it so far. One of the selling points is higher impact toughness than PLA (by a lot) and even ABS. It definitely has a softer, more ductile feel than normal PLA. It prints very nicely. the surface finish of the filament is very smooth, and it seems dimensionally consistent.

I am hoping so! It looks like the devs have improved it a lot with the upcoming release.

It looks like this is is not of the new Rev B, but I'm not sure how much has changed. A very thorough review, and it all sounds awesome... until you get to the software side:

It looks interesting, but a more modest upgrade. It seems like if you are going to the trouble of sorting out different power requirements, etc, that you might as well jump to something even faster, and with more features, like integrated networking.

That looks like a really cool controller! I have been eyeing a replacement for the Arduino.

I'm with gr5. There is a lot of value in the official bed kit. I found room to further improve stiffness of it, but I don't regret buying it for a second. Should have sooner. https://ultimaker.com/en/community/view/15881-official-heated-bed-upgrade-kit-ultimaker-original

It does take a bit longer to set large values with these new settings (ie setting temp from 0 to 220). It would be super cool to add in a velocity dependence to the pulses per step. If you track the clicks per second over the last X number of clicks, then use that calculated knob velocity to increase the pulses per step, it would let you have your cake and eat it too! Whatcha think @amedee?

Unfortunately: configuration.h #define LCD_FEEDBACK_FREQUENCY_HZ 400#define LCD_FEEDBACK_FREQUENCY_DURATION_MS 20 seems to have no effect at all.

I can confirm that: configuration.h #define ENCODER_PULSES_PER_STEP 4 #define ENCODER_STEPS_PER_MENU_ITEM 1 ultralcd.cpp: #define ENCODER_FEEDRATE_DEADZONE 1 Work very well.

The only other references to those variables I could find are these. It looks like if not otherwise defined pulses / step is 1 and steps / item 5. People seem to be having good luck with pulses/step @ 2 and steps/item @ 4. I'm guessing that these need to be integers. Kind of tough in that case to get exactly what you are after. Seems like you can end up with say every 4th knob click not causing a menu change. ultralcd.cpp: #if !defined(LCD_I2C_VIKI) #ifndef ENCODER_STEPS_PER_MENU_ITEM #define ENCODER_STEPS_PER_MENU_ITEM 5 #endif #ifndef ENCODER_PULSES_PER_STEP #define ENCODER_PULSES_PER_STEP 1 #endif#else #ifndef ENCODER_STEPS_PER_MENU_ITEM #define ENCODER_STEPS_PER_MENU_ITEM 2 // VIKI LCD rotary encoder uses a different number of steps per rotation #endif #ifndef ENCODER_PULSES_PER_STEP #define ENCODER_PULSES_PER_STEP 1 #endif#endif Also found this guy. I had wondered why I had to turn the knob so far (even with the UC) before getting a feedrate override: ultralcd.cpp: #define ENCODER_FEEDRATE_DEADZONE 10

What about browsing the commit log? This changelog ENCODER_PULSES_PER_STEP in the config file. By default one encoder pulse generates one unit step in the values. Difficult to find a good compromise there, if you increase it, you will have to turn a lot to make big changes... Also, ENCODER_STEPS_PER_MENU_ITEM relies on that one, so if you change the first, it will affect the menu browsing as well, so you need to tune both. Personally I wouldn't go there... Ah yes, that makes perfect sense now! I'm a github noob. Both those lines are commented out in my config. It seems simple enough on the surface: tune pulses / step to give the behavior desired on value setting, then use steps / item to to get menus working again. I'm guessing the reality isn't that simple. Are these variables hardcoded elsewhere when not defined here? Does anyone know how many knob encoder pulses are generated per detent position? Maybe it even varies depending on controller mfg.

The other thing I noticed is that while most menus are very responsive, the SD card menu is quite laggy. Does anyone else have that issue?

Sweet, up and running! @amedee, would you mind pointing me to the section of code in your firmware branch to get the robot logo? Maybe the new forum took it out from post #5. I like the mapping of one knob click, per menu item, but the value changing isn't so great. Is there a section of the firmware that governs the steps / unit? Thanks!

Does anyone have / know of a list of the customizations which differentiate the Ultimaker (original) branches from the vanilla Marlin master? I'm interested in testing out their new RC build, but the structure has changed enough to make comparing files tricky. I could compare (file by file) the master Marlin release to one of the UM branches, but it would take a while. I'm hoping somebody has catalogued the changes. Thanks!

Thanks Amadee! I downloaded your branch and compared the dogm_lcd_implementation.h files to find the needed code.

Hi guys, trying to install my full graphic controller. I'm using the UMO official HBK marlin build, with a few tweaks. I already recommented the Ulticontroller definition and uncommented the one for full graphic controller. I have installed this into the Arduino libraries: https://bintray.com/olikraus/u8glib/Arduino/1.18.1/view I also installed the Arduino Liquid Crystal library. When I try to compile, I get this error. Any ideas? ultralcd.cpp: In function 'void lcd_control_version_menu()':ultralcd.cpp:961: error: 'lcd_implementation_draw_line' was not declared in this scope lcd_implementation_draw_line(0, PSTR(MSG_VERSION)); ^'lcd_implementation_draw_line' was not declared in this scope

Thanks gr5, good to know! I am not 100% on the error message, because it was very hard to read. The LCD was doing it's best impression of melting down. Not sure why that happens.

There is definitely some development going on in the main Marlin branch on Github.I think they are getting close to a release, though I'm not sure how extensive the port to UM specific firmware is. Their response to this issue was that they have rewritten much of the code that governs this, so it would need to be tested to see if it was fixed.

Interesting, I'll have to dig around in there! I've taken a little break from this project as I've been busy with other stuff. I actually had another issue, where molten filament started to leak out from a press fit between the thermal brake and heater block! I did not expect that one.

You know, I should have done that right away! hahaha I checked the heaters and they measured 8.2 ohms in parallel. After switching back to the stock heater, everything seemed fine. But a few days ago, I got another heating failed error. I went underneath and reseated the heater wires in the terminal block. Since then, I have run a couple 7 hour prints without issue. I'm wondering if that error was just coincidence. The physical size / mass of the heater block isn't as important as the steady state characteristic of the whole thermal system. Basically, looking at all the heat flows (at the desired temp): into the filament, up into the heat sink, and radiative/convective loss. All that combined equals the steady state power consumption. Things like surface area can definitely have a big impact here. But mass / volume would just slightly slow the initial heating.

I have yet to see a compound that is rated for sustained temperatures like a hot end produces. If you have a suggestion, I'm all ears! Using aluminum like that is pretty common. We are not talking much, just a couple layers. Many people suggest that even if the heater is a slip fit to the block, that it expands enough during heating to form solid contact. Adding aluminum foil helps to fill any airspace voids which would not conduct heat well.

My heater block and the Ultimaker block are made from aluminum, so no substantial difference in thermal conductivity. UM makes their nozzles from brass, but that won't affect heater / thermocouple placement. I have done extensive thermal simulation on this hot end configuration.