Jump to content
Ultimaker Community of 3D Printing Experts
Sign in to follow this  
Nicolinux

Cura 14.06 filament grinding

Recommended Posts

Hey guys,

I tested a bit more but this filament grinding issue isn't consistent at all. Before I hijack the thread - tell me if I should open a new one.

Before the 14.06.1 firmware (just updated to the stable one) I never had problems with filament grinding. Not once. But now I have them on every single print (power cycling doesn't help). I have also tested with the spring thightened at various levels (untightened, tightened very tight and something in between). But there is always grinding.

Worst case looks like this:

grinding Bad

 

A more civilized case looks like this:

 

And these grinding scenarios are completely random. I'll check it again tomorrow with an old firmware version.

 

Share this post


Link to post
Share on other sites

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.

 

 

Share this post


Link to post
Share on other sites

And this is the topic i started a couple of weeks ago with the same behaviour.

http://umforum.ultimaker.com/index.php?/topic/5637-feeder-grinding-on-startup-while-plate-is-leveled-up/

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

 

Share this post


Link to post
Share on other sites

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)

 

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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)

 

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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?

 

grind flat

I have attached the gcode file.

 

 

Share this post


Link to post
Share on other sites

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.

 

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  

  • Our picks

    • Taking Advantage of DfAM
      This is a statement that’s often made about AM/3DP. I'll focus on the way DfAM can take advantage of some of the unique capabilities that AM and 3DP have to offer. I personally think that the use of AM/3DP for light-weighting is one of it’s most exciting possibilities and one that could play a key part in the sustainability of design and manufacturing in the future.
        • Like
      • 3 replies
×

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!