Jump to content

tinkergnome

Ambassador
  • Posts

    2,774
  • Joined

  • Last visited

  • Days Won

    61

Posts posted by tinkergnome

  1. Das hintere rechte Loch das beim UM2 für den zweiten Feeder bestimmt war, gibt es das noch?

     

    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)

     

  2. just installed 16.08 it seems the retraction (after print and after print abort) is set to the wrong value.

    It's retracting 10 CM (!)

     

    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.

    • Like 2
  3. Probably the new tfm can be installed without that black part, or with a printed part, but for that we need @sandervg info of how to get it or a 3D model to print with the real measures (so we could use a caliper to check the 3d printed part before using it).

     

    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?

  4. Because when doing the Z adjustment some points the Z doesn't move at all, probably related to decimal points being dismissed on the process. UMO+ Z motor just doesn't move after each 0.01 change, but it does each 0.02, that makes sense since that's supposed it's minimum resolution.

     

    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 :))

  5. If I set the homing Z just before the first IF, it should only be executed once? Or should I make an external 'thingy' ?

     

    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.

     

    I suppose I could do something like this (dirty coding sorry in advance)

     

    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...

  6. I pushed this mod forward because one endstop died, but the ability to change z so fast it's quite nice.

     

    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.

    • Like 1
  7. A screensaver would be great, but I don't think it would be possible with the electronics. Maybe a custom firmware where you can hide the "time left" message and just put a progress bar in one tiny corner to avoid ghost images.

    Well, it's too late for me, but it could implemented for future users!

     

    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...) :)

    sml_gallery_38374_1618_3285.png

    • Like 2
  8. Would as easy as making a sequence, first the bed goes touch the endstop, then I do a simple add_homeing[2] = -current_position[Z_AXIS];

    Should that work to convert the negative into positive?

     

    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?

    • Like 1
  9. What is "babystepping"?

    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

  10. But if the nozzles size isn't in the list, how he determine the value to use ? He  use the 0.4 nozzle in standard  value ?

     

    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...)

  11. D'ailleurs je me demande comment c'est géré le switch de ces températures. Est ce que l'information de la buse est intégré au début du Gcode d'un print ?

     

    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.

  12. Is it possible that the heat-plate does not work there properly?

     

    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.

    • Like 1
  13. Benötige ich Tape (Multec empfiehlt '3M Scotch blue Tape 2090') oder eine BuildTak Dauerdruckplatte?

     

    Hallo Sebastian,

    was empfiehlt denn der Hersteller als Temperatur für das Heizbett, und wieviel Lüfter? Erstere vermutlich so hoch wie möglich (>= 100°C), letzteres so wenig wie möglich?

    Die PLA-Einstellungen sind da definitiv ungeeignet.

    Wenn Blue-Tape explizit empfohlen wird, geht es möglicherweise ohne spezielle "Klebehilfe" trotzdem nicht.

    Wenn es sich mit dem Klebestift schon ein wenig in die richtige Richtung entwickelt hat, könntest Du 3DLac oder DimaFix versuchen.

    Für Colorfabb HT funktioniert das gut, ich weiß aber nicht, ob das Material vergleichbar ist.

  14. warping problems on the back side of the object (on the front where the printer is open the result is ok)

     

    That's suspicious. Perhaps it "warps" because the bottom part of the printed object stays too soft. What's the height of the first layer? Do you use any glue?

    It's probably better to reduce the temperature of the heated bed after a few layers.

    You can start with 65°C (for a good first layer adhesion) and reduce it to 55° (or even lower) from layer 3 or 4 upwards.

    If this makes a difference...? You will know it in - let's say - 7 hours... :)

    • Like 1
  15. Umm it's this correct @anyone?

     

    Yep. 69_EmoticonsHDcom.png

    @Shane: How familiar are you with git?

    In short: clone the repository and switch to the correct branch (as @neotko said).

    You can download the zip-file from Github instead, but then you also have to choose the correct branch first.

    The "uncompiled" version for the UM2 extended+ is here:

    https://github.com/Ultimaker/UM2.1-Firmware/tree/UM2.1_JarJarExtended

    The most important difference is the build volume in Configuration.h

    Have fun!

    • Like 1
  16. wenn die Firmware auf 100° begrenzt ist, dann kannst du leider nichts machen - auch nicht über gcode.

     

    Es sieht so aus, als würde der Maximalwert auch in der Standard-Firmware demnächst wieder auf 115°C angehoben.

    Bei der nächsten Cura-Version ist dann vermutlich auch wieder eine aktualisierte Firmware dabei, es gibt also noch Hoffnung für alle ABS-Junkies... :)

    Das hier ist der zugehörige Git-Commit

×
×
  • Create New...