antiklesys

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

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?

Awesome thanks! Fixed it now, but I do have additional questions for you

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:

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

Would you also sell the hot bed itself alone?

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. Is this design published anywhere???

The github gives a 404. Any available link to the files?

I've tweaked the current UMO electronics to run at 24V by replacing the LM7812 with a DC-DC converter. I now wonder how far I can push those. Trying to limit my expenses. A hot bed upgrade is on the horizon, but not my immediate requirement (still printing pla)

Hey tommy, thanks for your reply. What about the Rumba: was it an improvement over the UMO electronics in your opinion?

Yes, I saw that post, yet I was asking for recommendations for it to work on an UMO (aka: has anyone tested this yet?)

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

Any chance to have the link to the files you used for those red houses?

Use the Knurled Bolt of this design: http://www.thingiverse.com/thing:15897 With this design: https://www.youmagine.com/designs/modified-geo-hangen-ultimaker-extruder-by-antiklesys--2 And I suggest buying one of these to use with it: http://e3d-online.com/Mechanical/Bowden/Bowden-Adaptor-3mm-Filament

Check out the one used by the Geo-Hangen extruder. Which is the same one used in my modification of that extruder.

I can recommend you a good extruder to print, but you'll need someone to machine you a knurled bolt as it's using a custom one.

The stock extruder feeder sucks in my opinion, I had a LOT of issues with it even with the stock hot end. I would recommend printing a better one to rule out extrusion issues.

Ciao, quando pensate di ri-avere in stock l'upgrade per il piano riscaldato dell'UM Original?

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 Would love to follow up on Skype tho or whatsapp if you fancy. PM me

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

I have my laser already hooked up to my UM, will check out this GCode and see how it goes

I tried with pointers as a viable solution, but I'm still getting loads of errors.

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?

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

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.