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
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)
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.
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....
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.
Nicolinux, I have just checked that I do not have your problem
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
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.
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
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)
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)
@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
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
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.
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
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.
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.
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).
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
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)
I know it's not much, but it looks a bit messy, would be nice if you could adjust it to filament needs :wink:
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
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.
ArunC posted a topic in UltiMaker Cura,
.thumb.jpeg.0b7a05eafc09add17b8338efde5852e9.jpeg)
Dustin posted a topic in Firmware,
Recommended Posts
Top Posters In This Topic
32
16
11
10
Popular Days
Jun 3
21
Jun 11
14
Jun 6
10
Jun 5
9
Top Posters In This Topic
stevegt 32 posts
illuminarti 16 posts
DidierKlein 11 posts
Anders Olsson 10 posts
Popular Days
Jun 3 2014
21 posts
Jun 11 2014
14 posts
Jun 6 2014
10 posts
Jun 5 2014
9 posts
DidierKlein 729
: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