Jump to content
Ultimaker Community of 3D Printing Experts

Z axis homing inconsistent on UM2: workaround and patch


Recommended Posts

  • Replies 116
  • Created
  • Last Reply

Top Posters In This Topic

Posted · Z axis homing inconsistent on UM2: workaround and patch

:mrgreen: Must have been lucky, i printed all day without issues today :) will install the new firmware tomorrow.

I checked the version this morning and i thought that it was just that the version didn't change ^^

 

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    By the way, for people just wandering in: I printed the robot just to try to help find any obvious regression in this next release. It's not a good way to check for the Z homing bug. The best way to check for the Z homing bug before and after upgrade is using one of the procedures above, such as #43.

    If you just want to print something shiny that stresses good Z homing, see leveling rings.

    Steve

     

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    I can also confirm my bed height lack-of-consistency problems are gone with 14.06 based firmware. I've done at least a dozen prints and every time the first layer height has been on-target. (previously, I would have to adjust the first layer height on the fly for just about every print, at least a little bit -- sometimes it would be off by nearly a mm)

     

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    Hey guys,

    Using the RC5 and Robert's feeder, the filament is ground down every time when a print starts. Sometime is it now enough to stop moving the filament but sometimes it is. I've catched it on video. Anybody else with this issue? I have already untightened the spring on the feeder to the point where it would soon fall off.

     

     

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    Nocolinux, I will check it this afternoon.

    BTW, I was happy with this new feature, because sometimes there was no filament in the nozzle at the beginning of the printing.

    More later....

     

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    Firstly - don't untighten the spring. Tighten it. You want to motor to skip before it grinds the filament. Generally speaking, higher tension will help with that.

    But then there are two things going on. It looks like during the 'raise buildplate' part, the filament is moving, which it shouldn't be - and quite fast. Then it's doing the 'advance 25mm at retraction speed' into an already primed head. Which is making it even worse.

    Not sure what is causing the first one - some sort of initial e-position error, I imagine. The second one I've already reported here. The filament ISN'T always retracted 20mm at the start of a print - especially when that weird first move is happening. And even if it is, jamming an extra 5mm in there at retraction speed is just going to make a mess.

     

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    Nicolinux, I have just checked that I do not have your problem

     

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    I just want to chime in and say that I'm also happy with the new filament push, and the higher bed height; I like the way it tends to make a nice big blob of anchor material on the front left corner and then stretches the filament over to the print. No more anxiously hanging around during heating just to grab the filament at print start.

    In my case (with a standard feeder) I haven't had any horrible filament grindage; I usually do hear about 3 skips during that push, but haven't noticed if it's the motor skipping or the filament itself. I'll check that tonight.

    So I think it's better than what we had before. The only modification I'd make, lacking a force sensor on the bowden tube, would be to slow that push even more. I haven't done any experimenting myself, so I don't have a better number, otherwise I'd have submitted a patch by now. (Daid already slowed it down some, at https://github.com/Ultimaker/Ultimaker2Marlin/commit/c760f0dd4e8976d5f3abf75751cbdbf5f3eec1c2.)

    I had a crazy idea about estimating actual extruded volume by getting inside the temperature PID loop, but that's much more of a science project.

    Steve

     

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    Yes, it's good that the bed is higher up, and it's good that there's priming going on. Ideally it would also pause a second or two to let you clean up the nozzle - or even do a wipe pass across the front of the bed. This is all something we used to be able to do properly using the Ultimaker Original, where we can set our own start gcodes.

    But even moving the extruder at 10mm/s, that's equivalent to trying to extrude 65mm³/s for several seconds. The speeds really should be a lot slower - especially since, with the new weaker extruder spring - it seems like the extruder is a lot more prone to grinding than skipping back.

     

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    my god!

    I was just loosing my mind while leveling the bed.

    It has been a week to have UM2 and i think i have to change it because of faulty z-axis . and luckily i saw this forum :)

    hope this upgrade solve my problem :)

     

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    I noticed the "grind out" at the start too.

    I moved the initial extrusion distance and feedrate to #defines in configuration.h -- I suggest maybe they should be a user pref or an M? G-Code adjustable EEPROM settings (like acceleration, jerk, maxspeed, steprate, etc).

    I found a feedrate of one fifth to one tenth the original value would give me a good prime without grinding or skipping.

    I also disabled raising the bed, as it causes problems with resuming an interrupted print or single-extruder dual-color prints (the firmware makes an incorrect assumption that all prints will start at Z=0, and therefore can smash the head into previously extruded material over 20mm)

     

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    where we can set our own start gcodes.

     

    Yah, I would like that feature in Cura/UM2 (without going so far as to raw g-code)

     

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    @Nicolux, i had the same issue too. You have to tighten the spring more to make the feeder skip.

    I reported this a while ago but didn't find a clear reason to why this happens. Since the new firmware it looks to be better i think

     

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    I moved the initial extrusion distance and feedrate to #defines in configuration.h -- I suggest maybe they should be a user pref or an M? G-Code adjustable EEPROM settings (like acceleration, jerk, maxspeed, steprate, etc).

     

    I've always thought Gcode is really the wrong language for controlling complex machines doing complex things. The language can't easily carry enough situational knowledge in regards to materials, shapes, tasks, jigs, machine specs... and the more one tries, the more unreadable and unmaintainable it becomes (old M codes die hard). I can see where the UM2 is trying to go with getting rid of start and end gcode blocks. I feel like what's missing is a richer "job control language".

    I'm seriously thinking about something that looks a lot like JCL -- if you've never had the pleasure or pain of working with it, go check the Wikipedia entry (and BTW note where '//' and the Unix 'dd' command came from): http://en.wikipedia.org/wiki/Job_Control_Language. The key features I'm thinking of are a key=value syntax, and the ability to be included as comments in-line with the lower-level executable gcode.

    The Ultigcode commented keywords like TIME and MATERIAL are the right idea, I think. Adding key=value named parameters on the right-hand side of the colon would need an additional parser function (unless Daid already has one tucked away somewhere in there). On the other hand, we might get by without the named parameters, if we don't mind a proliferation of left-hand-side keywords. Does anyone have any opinion about this one way or the other?

    EDIT: An example might help:

    ;FLAVOR:UltiGcode

    ;TIME:17335

    ;MATERIAL:62497

    ;MATERIAL2:0

    ;PRIME: Z=50 PAUSE=5 F=10 E=20

     

    ...meaning prime with Z at 50, pausing for 5 seconds for cleaning before feeding 20 cubic mm at a feedrate of 10. Any missing parameters would default to whatever's in the firmware.

    Steve

     

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    In my case (with a standard feeder) I haven't had any horrible filament grindage; I usually do hear about 3 skips during that push, but haven't noticed if it's the motor skipping or the filament itself. I'll check that tonight.

     

    Checked -- no grinding. Stepper is skipping about 3 times during prime.

     

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    The thing nicolux described is not happening during the priming.

    If it's the same thing as i have (or had) it happens when the bed is levelled up just before the priming. The feeder turns quite quickly during the whole time the bed is travelling up.

    It grinds the filament probably because of not enough tension in the spring. I didn't notice this again since the last firmware upgrade tough. It happened to me quite often but i didn't find a way to reproduce it

     

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    I've always thought Gcode is really the wrong language for controlling complex machines doing complex things.

    ....

    Does anyone have any opinion about this one way or the other?

     

    Of course.... (ad naseum). But we should start a new thread and not derail this one any further. :)

     

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    I had a crazy idea about estimating actual extruded volume by getting inside the temperature PID loop

     

    Um - okay - I think you are going to be a good contribution to the forum. I like this kind of thinking. :)

     

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    Hey Nico, it's exactly what i was having... i don't know why but since i'm using 14.06 version of Cura it seems to be gone (will have to confirm that because i didn't use the printer a lot since then).

    Is it possible that this is due to the gcode you print? (just a wild guess here because i'm now printing with Cura, and the latest Firmware).

     

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    it looks that priming got a lot more aggressive on my UM2. Would be nice if you could adjust these parameters in the menu, without changing the firmware manually. I get the stepper skipping and a lot more unnecessary wasted filament at the moment

     

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    I think the amount of primed filament has been doubled for this update. It isn't that much more (i think 6mm instead of 3mm)

     

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    I know it's not much, but it looks a bit messy, would be nice if you could adjust it to filament needs :wink:

     

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    Nicolinux and others, I can confirm that 14.06.1 firmware does indeed grind the filament at the start of a print.

    Changing filament works fine but starting a new print (tried with Illuminartis standard test cylinder "UM2-noret-ExtrusionTest-3-10mm3.gcode" as well as another gcode) grinds the filament at the start of every print, just like in your videos.

    I did the test twice with Colorfabb Blueish White filament (is a little bit softer so might grind even easier than pure PLA) and it grinded both time at start (I hade to re-load/clean).

    Then I downgraded to Cura 14.03 firmware (by starting Cura 14.03 and selecting Machine->install default firware) and then the same gcode printed without grinding.

    My recommendation would be NOT to upgrade (unless you want to verify the behaviour).

    /Daniel

     

  • Link to post
    Share on other sites
    Posted · Z axis homing inconsistent on UM2: workaround and patch

    By the way, we also got this reported yesterday from a customer after we recommended they would upgrade to 14.06.1 fw so I'm pretty certain there is a "bug" in that firmware.

     

  • Link to post
    Share on other sites

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

    ×
    ×
    • Create New...