And this is the topic i started a couple of weeks ago with the same behaviour.
It's odd i don't understand why it looks like it's solved for me with the latest firmware but shows up to others...
I have to confirm that it doesn't happen to me anymore for me
I can confirm the grinding. I have had this yesterday, too (more than once).
- Robert's feeder (tried different spring pressures).
- Faberdashery - Architect's Stone PLA
- Cura and Firmware 14.06.1
- Room temperature close to 30°C
It's happening always on the start. The new start procedure seems a little bit too aggressive.
(Text copied from other thread)
I thought I had no grinding but now I confirm that I have it.
yes, too aggressive configuration in Cura 14.06.
the amount of filament extruded is fine... but too fast
The issue is in the firmware and not Cura. Specifically, lines 87-89 of UltiLCD2_Menu_Print.cpp
Daid made a change on May 28 to reduce the speed (from 25 to 10) but I think it needs to go down even more. I use 5 -- which has fixed the grinding on most, but not all, filaments. To be really safe, it might need to go down to something like 3 (but it will take a while longer to finish it's spew).
Also note any additional extruders will spew at double that rate (not sure why that is)
Here's his commit: https://github.com/Ultimaker/Ultimaker2Marlin/commit/c760f0dd4e8976d5f3abf75751cbdbf5f3eec1c2#diff-41dee0ad5d891d59fab5c856765b9c1e
There is an open issue, started by illuminarti, on github, so hopefully Daid will be able to change it soon.
https://github.com/Ultimaker/Ultimaker2Marlin/issues/25
Has anyone noticed if the behavior is different when using raw g-code files vs ultigcode?
Yes, the priming doesn't happening using raw gcodes, so it's less of an issue. However, there is another bug which causes random harmful extrusion during the bed raising part, which also causes grinding.
I've fixed up the bugs and am testing a fix this evening. I'll post a hex file here later for anyone who wants to try it out. I was having repeated problems with grinding across several different printers, and they're all behaving much better with the new firmware.
Yes, the priming doesn't happening using raw gcodes, so it's less of an issue.
Hrm. That's related to something suspicious I saw in doStartPrint()....which is why I asked about raw vs Ulti...
From what I see, doStartPrint() is called in both UltiGCode and raw gcode printing, so the priming in lines 85-87 gets called for either filetype (right after raising the bed). But the difference is
plan_set_e_position(-30.0 / volume_to_filament_length[e]);
gives different priming amounts depending on if it's ulti-gcode vs raw gcode... Looking at where volume_to_filament_length is set, it's 1.0 for raw g-code and 1/(PI * R^2 ) for Ulticode.... which results in roughly x7 the prime length for Ulticode vs raw gcode....
So raw gcode does prime, just by 1/7th the amount.... I'm not sure that's difference in behavior is 100% intentional...
I changed the feedrate (2 lines down) from 10 to 5 and no longer have grinding. Unless you're talking about some priming that's happening elsewhere?
No, the 1/7th factor is because normal gcode expresses e coords in linear mm, whereas UltiGcode expresses it in cubic mm.
The priming code is in a conditional which only gets called if there are 'material' headers in the gcode file. I don't know if Cura adds those to regular gcode, but normally one wouldn't.
Ah, I didn't realize that's what that conditional was for. I misinterpreted it to be a sanity check on the materials list. Checking the LCD display cache for the estimated material length !=0 to determine if it's UltiGCode or raw gcode... well... yah... I'll just say that macro manual struct construct in LCD display cache isn't the most lucid piece of code.
Interesting ... that conditional is not applied to the AbortPrint() that does the end-of-print retraction. It uses card.sdprinting (not the same condition). Similarly, the AbortPrint retraction only retracts the active extruder but doStartPrint primes all extruders (I saw no retraction during a tool change). Seems like the end-of-print retraction is not balanced against the start-of-print prime in all cases.
Printing raw gcode could come from any slicer, and therefore the material length header would not be there. Cura does not use the same header format as in UltiGCode, but instead puts this header in raw gcode:
;Sliced at: Wed 11-06-2014 21:40:22
;Basic settings: Layer height: 0.1 Walls: 0.5 Fill: 20
;Print time: #P_TIME#
;Filament used: #F_AMNT#m #F_WGHT#g
;Filament cost: #F_COST#
which is in a different format, different units, and is not properly filled in....so the conditional would skip the prime (as you said)
Ok, my initial testing seems to be working ok, so I'll post the hex file if anyone else wants to take a look. This is the current 14.06.1 Ultimaker² firmware with some fixes:
1) The e-coordinate wasn't fully reset to zero at the start of prints. As a result, during the bed raising at the start, the extruder could be advanced very rapidly, causing grinding.
2) The extruder was then primed for 30mm at 10mm/s. That's too fast, especially if the head is already primed. So I put in a slower recovery of 20mm (to make up for the retraction that should be happening at the end of the print), followed by an even slower 'true priming'. The speeds are configurable in configuration.h
3) The '20mm at the end' retraction actually wasn't happening when prints finished normally. Only when aborted, or when filament was loaded. (I held on to the filament during a bunch of back-to-back quick prints to check whether it happened - it never did). So I changed that so that the 20mm at the end did happen.
4) The G10/G11 'retracted' state wasn't getting reset at the start of a print. As a result, if you already finished one print with a retraction, then the first retraction of the next print (e.g., at the end of the skirt) didn't happen, because the machine thinks it's already retracted. And then at the start of the object proper, the corresponding de-retraction fires, dumping plastic out of the already primed nozzle.
5) I changed the default bed temp for PLA to 60º, because that's well overdue to be changed.
You can see the details of what was changed here:
https://github.com/illuminarti/SecretMarlin/commit/24a692b02157e1ebae00d773d6c39c8eaebbdbb2
The hex file is available here:
https://www.dropbox.com/s/1i6ha8em51h61bo/Marlin_grind_fix_test.hex
Let me know how it works for you.
I hunted around and I saw some references to retractions at tool change, but not actually in the T-code handler. I agree that it's not symmetric right now, and needs some work. But for the simple single extruder case, the changes I made should help - and for multi-extruder, they shouldn't make things any worse :-)
@illuminarti: Thanks for the fix. Will test it tonight.
Just one question, can you confirm that the grinding during the levelling of the bed was also present in the previous firmware version (14.03 i think)?
Yes, but for different reasons. The worst offender was a bug that was introduced on April 23, when code was added to raise the print bed before starting to extrude, but without properly reseting the E coordinate. But even prior to that it was trying to extrude too much, too fast during the start up. Back then, the extruding and the raising of the bed all happened in one movement anyway, but still too fast.
I was wrong on the multi-extruder thing -- it retracts, not primes, additional extruders in doStartPrint();
BTW, I think that sometimes the filament is not retracted when the printed is finished.
In such cases, the grinding is large, because the filament cannot be pushed!!
That's #3 on Illuminarti's list of fixes. ^^^
Hi Simon,
Many thanks for the fix. It works perfectly now - no more grinding!
Yay! I'm glad it's working well for you. I really need to try that extruder design. Which one is that?
https://www.youmagine.com/designs/alternative-um2-feeder-version-two
The Famous Robert UM2 feeder :mrgreen:
Still need to finish mine :oops:
DOH!
The grinding at the beginning is gone, but the grinding while printing persists. With the first 14.06.1 firmware all my prints failed due to grinding (model sliced with Cura 14.06).
Same with the fixed firmware. Maybe the gcode is faulty?
I have attached the gcode file.
Grinding during the print is probably down to the tension on the extruder being not quite right; either too much or too little.
Once the print is underway, the firmware should just do whatever the gcode asks of it. It's probably the combination/spacing of retractions that's causing issues; you need to get to the point that once too much is asked of it, the motor slips backwards (avoiding damaging the filament), rather than being able to keep moving forwards against stationary filament, and grinding it away.
Well before the 14.06.1 firmware I never experienced grinding with Robert's feeder. Now that I fiddled with the spring tension I might have b0rked the optimal setting/tension.
I'll keep on testing - thx.
I have the feeling too that now it is working better.... this is very strange...
ArunC posted a topic in UltiMaker Cura,
.thumb.jpeg.0b7a05eafc09add17b8338efde5852e9.jpeg)
Dustin posted a topic in Firmware,
Recommended Posts
Top Posters In This Topic
20
6
6
5
Popular Days
Jun 12
23
Jun 16
9
Jun 18
8
Jun 13
8
Top Posters In This Topic
illuminarti 20 posts
Nicolinux 6 posts
selmo 6 posts
profepaco 5 posts
Popular Days
Jun 12 2014
23 posts
Jun 16 2014
9 posts
Jun 18 2014
8 posts
Jun 13 2014
8 posts
Nicolinux 288
It seems that with the latest firmware (14.06.1) the filament priming procedure is too aggressive and inconsistent which leads to filament grinding for some users.
The discussion started in the following thread and I hope one of the admins will move the relevant posts here to keep the discussion clean.
Link to post
Share on other sites