Jump to content
Sign in to follow this  
stevegt

Z axis homing inconsistent on UM2: workaround and patch

Recommended Posts

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

Robot prints fine with 14.06-RC6.

Steve

 

Share this post


Link to post
Share on other sites
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 ^^

 

Share this post


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

 

Share this post


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)

 

Share this post


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.

 

 

Share this post


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

 

Share this post


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.

 

Share this post


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

 

Share this post


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

 

Share this post


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.

 

Share this post


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

 

Share this post


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)

 

Share this post


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)

 

Share this post


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

 

Share this post


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

 

Share this post


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.

 

Share this post


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

 

Share this post


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

 

Share this post


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

 

Share this post


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

 

Share this post


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

 

Share this post


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)

 

Share this post


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:

 

Share this post


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

 

Share this post


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.

 

Share this post


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
Sign in to follow this  

×
×
  • Create New...

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!