Jump to content

antiklesys

Dormant
 View Profile  See their activity

  • Posts

    215

  • Joined

  • Last visited

 Content Type 

Posts posted by antiklesys

    Weird Z height issue with UMO Marlin

    in UltiMaker Cura

    Posted

    So it should allow me to go in the other direction by changing this?

     

    static void lcd_control_motion_menu(){   START_MENU();   MENU_ITEM(back, MSG_CONTROL, lcd_control_menu);#ifdef ENABLE_AUTO_BED_LEVELING   MENU_ITEM_EDIT(float32, MSG_ZPROBE_ZOFFSET, &zprobe_zoffset, 0.5, 50);#endif

     

    into this?

     

    static void lcd_control_motion_menu(){   START_MENU();   MENU_ITEM(back, MSG_CONTROL, lcd_control_menu);#ifdef ENABLE_AUTO_BED_LEVELING   MENU_ITEM_EDIT(float32, MSG_ZPROBE_ZOFFSET, &zprobe_zoffset, -10, 50);#endif

     

    Weird Z height issue with UMO Marlin

    in UltiMaker Cura

    Posted

    The next question would be related to a similar behavior happening with

    zprobe_zoffset item in Marlin

    In ultralcd.cpp I have:

     

    #ifdef ENABLE_AUTO_BED_LEVELING   MENU_ITEM_EDIT(float32, MSG_ZPROBE_ZOFFSET, &zprobe_zoffset, 0.5, 50);#endif

     

    Now it seems this distance is negative as per Marlin_main.cpp

     

         #ifdef ENABLE_AUTO_BED_LEVELING       if((home_all_axis) || (code_seen(axis_codes[Z_AXIS]))) {         current_position[Z_AXIS] += zprobe_zoffset;  //Add Z_Probe offset (the distance is negative)       }     #endif

     

    This means that whatever I set in this variable will cause the head to go below Z 0 is this correct?

    Meaning if I home at Z0 and i have an offset of 3, the head will go at Z-3 and consider that Z0?

    If so I would need a way to use a signed Z offset rather than a negative one, this would allow me to choose wether to have a positive or negative distance based on the situation / head mounted.

    Any help to point me in the right direction to fix this too? :)

    Cura Feature request: Infill Height ?

    in UltiMaker Cura

    Posted

    Hi,

    I was thinking the following:

    Say I have a 0.4mm nozzle and I want to print layers at 0.1mm because I want to give my print a "nice look".

    This however comes at the price of print strenght, as 0.3mm layers are stronger.

    So what about having an "Infill Height" value that could be set "indipendently" from the layer height?

    "Indipendently" in this case would mean that it could be different from the layer height, but it would still have to be tied to it and could only be a multiple of a layer height.

    So, if I decide to print at 0.1mm layer height, I could theoretically set an infill height of 0.2mm and 0.3mm and the printer would then perform the following in order:

    (in case of a 0.3mm infill height)

    1-print contour/walls layer at 0.1mm

    2-print contour/walls layer at 0.1mm

    3-print contour/walls layer at 0.1mm

    4-print infill at 0.3mm

    In case of a 0.2mm infill height it would be just the same with one less contour/walls layer printed.

    This way the outside of the print would have the look of a 0.1mm layer print, but the inside would have the acquired strenght of a 0.3mm print.

    Your thoughts? Or is this complete blasphemy? :oops:

    Weird Z height issue with UMO Marlin

    in UltiMaker Cura

    Posted

    have this function to home the printer and set the bed at a specific height for laser cutting.

    This is in ultralcd.cpp

     

    static void laser_home(){   enquecommand_P(PSTR("G28 X0 Y0"));   enquecommand_P(PSTR("G28 Z0"));   enquecommand_P(PSTR("G1 Z85 F12000"));}

     

    So far all works well, but I wanted to change it, so I could set the Z height manually from the screen and adjust it to different values.

    I changed this function in:

     

    static void laser_home(){   enquecommand_P(PSTR("G28 X0 Y0"));   enquecommand_P(PSTR("G28 Z0"));  char buffer[32];  float laser_offset = 80;  sprintf_P(buffer,PSTR("G1 Z%i F12000"), laser_offset);  enquecommand(buffer);}

     

    As you can see, laser offset is a float that for testing has been set to a fixed value of 80.

    Additional note: my printer homes at the bottom.

    Now what is weird to me, is that when I run the first code (the old one at the top), the printer homes and then puts the bed at Z85. This is good.

    When I run the second function instead (the newer one), the printer homes and then surpasses Z85 and crushes the bed in the head (attempts to do it, as I switch it off before this happens).

    Any clue on what I'm doing wrong here?

    All help is welcome

    Official Heated Bed Upgrade Kit: Ultimaker Original

    in Third party products & modifications

    Posted

     

    Some questions:

     

     

     

    Yes, I used the exact anti-backlash nut on my UM2 which has the same heated bed. But I had to dismount the black part of the nut and mount the UM2 nut instead. And a printed adapter piece was needed.

    UM2_Backlash_nut.jpg.1b990321935fa0645dc1c69f945f685a.jpg

     

    Is this design published anywhere???

    PT100 on UMO with E3D

    in Third party products & modifications

    Posted

    So I'm in the process of switching my UMO print head to an E3D V6 and the filament size has also switched from 3mm to 1.75 mm.

    I'm currently still using the UMO aluminum heater block, as it's compatible with the E3D hot end, however I have future plans of switching the printer from 19v to 24v and I wanted to also replace the stock parts with the ones provided by E3D and use a PT100 temperature sensor.

    Anyone has any recommendations on how to have this working with an UMO? (not UMO+)

    Hacking UM to cut stuff...

    in Third party products & modifications

    Posted

    Hi Antiklesys!

    Great to hear from you - good to have you back here.

    In the meantime I figured out how to mount and connect the laser as well as a (more or less) useable toolchain.

    @ mount: I designed two brackets to simply snap it below the print head. For zeroing Z I simply made a spacer with app. 160mm to get the platform in the right distance.

    @ connection: I soldered a pinheads at EXP3, GND and Pin 13 to the UMO board and used a simple relais for switching the laser on and off - unfortunately 100% on or 0% off, so no power control... The pin is adresses via a M42 P13 Sxxx command - S0 for off, S255 for on.

    @ toolchain: I got Cut2D running and managed to get the postprocessor doing the "right" things to get the UMO up and laser cutting. Good thing at Cut2D: simple and intuitive, bad thing: no "lines" cuttable, it has to be something like an "area". I set up different tools to addess different materials/speeds - here I´m still in tweaking and testing. Further I worte a little gcode to prepare the UMO for laser cutting (zero, then down 180mm to allow spacer input, then zero again, move to mid/front to snap on the laser head).

    So, this was a lot of writing :-)

    Hope it helps you a bit - otherwhise just ask :-)

     

    I'm currently in the process of trying to figure out what I was doing at the time I was messing up with the laser and document it, so I know where to continue from :p

    Would love to follow up on Skype tho or whatsapp if you fancy. PM me :)

    Hacking UM to cut stuff...

    in Third party products & modifications

    Posted

    Hi Drayson,

    I just noticed you asked for my input on this thread but I've been away for a while and couldn't dedicate much time to my laser attachment for the UM.

    Now that I have a bit more time however, I'm curious to know how you ended up wiring the laser and your details for the g-code creation to run it.

    Hoping to duplicate your efforts and get the laser up my UM Original :)

    Marlin fork questions

    in UltiMaker Cura

    Posted

    Hi Daid,

    Why would be there a performance loss?

    For instance, X & Y default steps are defined in configuration.h, but then Marlin stores them in the eeprom and allows you to change them from the lcd menu. You actually go only back to the default values if you need to do a restore of the settings.

    Shouldn't it be possible to achieve a similar behavior for the Z_HOME_DIR without having a performace loss?

     

    Marlin fork questions

    in UltiMaker Cura

    Posted

    Hi,

    I'm working on a fork for Marlin and I'm currently in need to make major changes to the configuration.h file.

    The issue I'm running into is that i need to remove some of the defined constants in configuration.h and have the system use them as variables.

    Of course if I even try to change:

    #define Z_HOME_DIR -1

    into:

    int Z_HOME_DIR = -1;

    I will get loads of compilation erros.

    Any hints on how to proceed further?

    My programming skills are a bit rusty, but I'm working on removing some dust from them :)

     

    Cura's Marlin is different than the one on GitHub

    in UltiMaker Cura

    Posted

    Hi Illuminarti,

    I apparently had an issue while browsing Github pages and it seems something went wrong on there.

    I ended up downloading three different versions of Marlin which were exactly the same one in the end.

    I then went back again to the link you provided and noticed a few discrepancies with the downloaded one i had, so i now downloaded it again and it seems working. I wonder if there was an issue on Github itself.

    Feel free to delete this thread.

     

×
×
  • Create New...