tinkergnome

It's probably not motor current or steps, that would affect the standard firmware too. My suspicion is the "printing area". Can you take a look at this? If in doubt - take pictures of the relevant screens. The runtime statistics are preserved during a factory reset, but i would make a backup of the material profiles, if you've made customizations...

Dieses (manuelle) Einfügen von G10/G11 - ist das nicht genau das, was das Retract While Combing plugin automatisch macht?

I second this. For dual extrusion prints the possible build volume is reduced by the amount of the nozzle offsets. Looking at the first picture - it is pretty obvious that the shift always starts at the height where the "blue" nozzle starts to print the crossbeam of the letter "T". Probably the printhead is hitting a limiting wall (or something similar) at that height:

For a three digit float with 2 decimals it would be "float32" IMHO... ..but that's not sufficient, because extrudemultiply is declared as int (in Marlin.h) If i were you... i would change the declaration (and the definition) to float and give it a try. Probably some rounding is useful for the e-steps calculation. And that's it. If in doubt, just search the Marlin folder for the term "extrudemultiply". There are only a few places where this is used.

Es wurden nur die "überflüssigen Zweit-Löcher" in der Rückwand und im oberen Teil vom Druckkopf-Gehäuse geschlossen. Alles andere ist noch da.

Nö, bei den "plus"-Modellen nicht mehr. Das Produkt-Video ist ein bisschen "zappelig", aber man kann es trotzdem ganz gut sehen (ungefähr bei 0:09 und 0:19)

Are you talking about your tests with the acta400? that's here: https://ultimaker.com/en/community/8689-custom-heater-block-to-fit-e3d-nozzle-on-ultimaker-2-the-olsson-block?amp%3Bsort=&page=4#reply-90772

Selector wheel stopped "clicking" Ultimaker 2 Knob does not click

You're talking about the retraction length that is specified on the printer? That's in mm. The conversion in cubic mm is only needed for those "manual" UltiGCode that is inserted during postprocessing by the slicer.

You're a brave guy!

D..n, you're a victim of my lack of sleep... But great, that you've tested it - i highly appreciate this. published V16.08.1 right now - end of print retraction is back to normal.

Is so much science really needed? I assume that the top and bottom plate should be as parallel as possible. And the cooling rib between the plates is 17.00mm high (part no. 1308). That should be the objective for all four corners, shouldn't it?

I'm afraid that i don't understood what kind of "anomaly" you noticed, but i have an explanation for this "0.01-behavior". It's probably the planner: Everything with less than 5 steps will be ignored as move and joined with the next movement. Actually (on z-only moves) this are 0.025mm. The UM2 has also 200 steps per mm for the z-axis and the firmware uses a move of 0.05mm for every encoder step during the bed leveling wizard. It seems to be not necessary to adjust the nozzle distance more accurate than this... (yes - i know- the 0.01 was a suggestion from me... i take it back )

On the UM2 you have to compensate the 20mm retract of the material change wizard. Make some calculations and increase the "Retraction amount" for the pause at height plugin (it's in cubic mm if you use the UltiGCode flavor). Re-sclice and you'll see the difference.... Good luck!

Swap Y-Axis with E2-Axis

I'm confident!

I see, you're becoming a programmer at heart... are you ever sleeping? There's no "lcd_prepare_move_z" at the sources from Ultimaker. What firmware sources are your basis? Anyway - i can make an educated guess... Edit: found it - i was on the wrong branch... (rookie mistake... ) If it is used like all the other menu functions, the whole function "lcd_prepare_move_z" is called from the main loop many times a second.... Or shorter: yes: the preparation has to be done as a separate step. I assume, that "lcd_prepare_move_z" is called somewhere from "lcd_prepare_menu()" with a line like that? MENU_ITEM(submenu, MSG_..., lcd_prepare_move_z); I would make an additional function like this: static void lcd_init_z_adjustment(){ // reset to the stored settings Config_RetrieveSettings(); // reset the z-offset add_homeing[Z_AXIS] = 0; // home z enquecommand_P(PSTR("G28 Z0")); // immediately switch to the next menu menu_action_submenu(lcd_prepare_move_z);} and replace the call of lcd_prepare_move_z with the name of the new function: MENU_ITEM(submenu, MSG_..., lcd_init_z_adjustment); This way the new function "lcd_init_z_adjustment" is called only once as an initialization step and the control is passed down to the former menu function afterwards. Nearly..., but the sequence of the steps is important. In my opinion the function should look like that: static void lcd_prepare_move_z(){ if (encoderPosition != 0) { refresh_cmd_timeout(); current_position[Z_AXIS] += float((int)encoderPosition) * 0.01; encoderPosition = 0;#ifdef DELTA calculate_delta(current_position); plan_buffer_line(delta[X_AXIS], delta[Y_AXIS], delta[Z_AXIS], current_position[E_AXIS], manual_feedrate[Z_AXIS]/60, active_extruder);#else plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], manual_feedrate[Z_AXIS]/60, active_extruder);#endif lcdDrawUpdate = 1; } if (lcdDrawUpdate) { lcd_implementation_drawedit(PSTR("Z"), ftostr31(current_position[Z_AXIS])); } if (LCD_CLICKED) { // store all settings (including the new z-offset) add_homeing[Z_AXIS] -= current_position[Z_AXIS]; Config_StoreSettings(); // important: tell the printer that we are at z=0 now current_position[Z_AXIS] = 0; plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]); // move z down a few mm plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], 5.0f, current_position[E_AXIS], homing_feedrate[Z_AXIS]/60, active_extruder); // important: inform the printer about the new position current_position[Z_AXIS] = 5.0f; // return to the previous menu lcd_quick_feedback(); currentMenu = lcd_prepare_menu; encoderPosition = 0; }} That's also quick and dirty and not tested in any way...

Just to be sure... if i understood you right, you want to implement a simple z-adjustment function using the add_homeing offset. To be honest - i have no clue how this is done on an unmodified UMO... physically moving the endstop, if i'm right? You should make a copy of the "lcd_prepare_move_z" function and add your stuff as a separate menu entry. I assume that you want to use the unmodified "move_z" at some point in time... And i think you need some more steps before you switch to your new menu entry (i'm not sure if you've already done this): - set add_homeing[Z_AXIS] to zero - home all axis, the z-axis should stop at the endstop and current z-position is at zero now (that's important!) - move the printhead to a proper position (X/Y center) - and/or disable the x/y steppers and you can move the printhead manually After that: move the z-axis further upwards until the nozzle (nearly) touches the buildplate. After pushing the encoder knob, set the add_homing offset and go back to the "Prepare" menu. That's what "lcd_prepare_move_z" does now. And finally: - store the settings to eeprom if you're satisfied - move the z-axis down a bit? You can put this also in the LCD_CLICKED part, if you want. Is this (sort of) a workflow that you have in mind? Edit: This line moves the axis by 0.05 on every encoder step: current_position[Z_AXIS] += float((int)encoderPosition) * 0.05; I would try to reduce this value, this will lead to a slower movement but a more precise offset adjustment possible.

Well... or a custom firmware where you can adjust the screen contrast and where you can define a sleep timer that switches off the led lights and/or the screen after a certain amount of time without user interaction... You're right, it's too late for you, but it's there (since a year or so...)

Well, i see an analogy to the method that is used on the UM2, it should work. If i were you... - i would move the final assignment into the LCD_CLICKED part and reset the current position - just in case you want to move the z-axis without re-homing afterwards. Something like this: ...if (lcdDrawUpdate){ lcd_implementation_drawedit(PSTR("Z"), ftostr31(current_position[Z_AXIS]));}if (LCD_CLICKED){ lcd_quick_feedback(); add_homeing[Z_AXIS] -= current_position[Z_AXIS]; current_position[Z_AXIS] = 0; plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]); currentMenu = lcd_prepare_menu; encoderPosition = 0;}... BTW: Are you not concerned about the homing precision, if you hit the endstop lever at this steep angle? Does it actually work (precisely enough)? Why not going the complete way and place the endstop on the bottom (like on the UM2). Are there mechanical factors that cannot be solved?

Hi Rick, i'm pretty sure that you asked this before... ...and here you have a short explanation of the idea (and the naming) from the inventor Bernhard Kubicek I use it sometimes to fine tune the z-position while the skirt is printed, or if i want to print a single piece on bluetape and don't want to re-level the buildplate. x and y corrections are perhaps useful if you want to recover an aborted print, but i think usually there's no need for that on the UM2... in short: babystepping == lazy z-height fixing during printing

@korneel Do you have replaced the bowden tube ever before? Is it possible that this was the most important point...?

exactement. If nothing is defined in the UltiGCode comments (or an "unsupported" value), the firmware always falls back to the temperature value of nozzle index zero (0.4mm). This way it is backwards compatible with gcode files from older Cura versions. And don't forget that the material profiles on the printer are only used in conjunction with Cura / UltiGCode. (...and to be honest: i haven't used Cura / UltiGcode for a while...)

Oui: ;FLAVOR:UltiGCode;TIME:1378;MATERIAL:800;MATERIAL2:804;NOZZLE_DIAMETER:0.400000;NOZZLE_DIAMETER2:0.400000 The five usable nozzle sizes are hardcoded at the moment, see here.

Well, you could check this easily, if you have access to an infrared thermometer... More likely the buildplate is a tiny bit tilted and therefore the nozzle distance on this corner is a tiny bit too big. Or one of the 6mm rods is bended a tiny bit in this area. As a test: you can make the "paper" test on all 4 corners, if you move the axis by hand (printer switched off). A helping "third hand" makes it more convenient. And in general: i suggest to use at least 0.2mm as first layer height and bring the nozzle a bit closer to the buildplate. For example: don't use the paper during the buildplate leveling, let the nozzle directly touch the glass instead. To be honest: usually i don't level the buildplate that exactly.... I have no interest to promote special products, but proper adhesion became a no brainer for me since i use DimaFix (or 3DLac - if you prefer). I printed parts from PLA that are 220x150mm without a brim and without any adhesion problems. It just works - point.