Prime blob knocked down (Cura/UM3)

[ghostkeeper 105]

Cura has the ability to prime or not prime with the setting "Enable Prime Blob" under platform adhesion. It's enabled by default.

Cura always writes a command "G280" to the output g-code to indicate that it should prime, but when the prime blob is disabled, this command becomes "G280 S1", which is a signal that the printer should not prime. I don't know why this strange structure was chosen but that's how it works now.

 

The G280 command is implemented by the firmware such that it extrudes a lot of material while slowly moving the build plate down, then tapping the nozzle off on the build plate a few millimetres further. This distance is not encoded in the g-code so Cura can't tweak how many millimetres away from the prime blob the tap happens. It can only enable or disable the prime blob entirely.

[gr5 2,167]

7 hours ago, ghostkeeper said:

I'll be in the office, and would be glad to meet you.

 

The last time I visited Ultimaker (1.5 years ago) some key people unfortunately took vacation that day.  Well I look just like my icon and assuming you do also we should have no problem noticing each other.  lol.

[Brulti 177]

Soooo... who do we need to bribe to get invited to visit UM HQ? 

[cjs 34]

Someone from the Cura Team once said that they can be convinced to implement features if you send cookies to UM HQ

May the same apply for the UM firmware team?   

 

[upatamby 9]

@Brulti, @gr5, @ghostkeeper, @ahoeben

As you are using 'my' thread to arrange meeting I hope that meeting will be about the prime blob. Good luck to all of you, I expect a great solution.

[ctbeke 133]

The community event is 23, 24 and 25 February indeed. Both @ghostkeeper and I will be doing a Cura session on the 24th (one about post-processing scripts and one about writing Python plugins). So I guess I'll see all of you there as well

[cjs 34]

@upatamby have you tried printing with prime blob disabled? I didn't work for me on earlier um3 firmware version, but seems to be as @Daid said quite good now. 

 

Another solution would be to change the priming strategy on your um3. I did find primeNozzleStep.py, which seems to be responsible for the priming sequence. 

You can find it on your ultimaker by going to /usr/share/griffin/griffin/printer/procedures/pre_and_post_print/ . 

The important bit, I think, is the following: 

# TODO: remove the turd priming strategy with EM-1161
        if self._prime_strategy == "turd":
            # when PVA is retracted it seems to form a thick string which then hardens and is not in contact with the heated part of the nozzle.
            # to compensate for this prime a bit slower, this hack can be removed when CURA takes over the priming move completely with the "none" strategy.
            if material_type == "PVA":
                prime_speed /= 4

            # Set E position to 0
            controller.queueGCode("G92 E0")
            # extrude the configured amount and undo the presumed de-priming done at the end of the last print
            controller.queueGCode("G1 Z2")
            e = retracted_amount
            controller.queueGCode("G1 E%f F%f" % (e, prime_speed))
            log.info("unretracting %0.2f mm", e)
            e +=  prime_amount * 0.5
            controller.queueGCode("G1 E%f F%f" % (e, prime_speed / 4))
            # move up while priming so you attach your noodles to the buildplate

            e +=  prime_amount * ((2 / 3) - 0.5)
            controller.queueGCode("G1 E%f Z6 F%f" % (e, prime_speed / 2))

            e += prime_amount * (1 / 3)
            controller.queueGCode("G1 E%f F%f" % (e, prime_speed / 4))
            log.info("priming %0.2f mm (a total including unretract of %0.2f mm)", prime_amount, e)
            controller.waitForQueueToBeEmpty()
            time.sleep(self.RELIEVE_PRESSURE_WAIT_TIME_1) # replaced marlin dwell with sleep here.
            controller.queueGCode("G92 E0")

            controller.setRetractedLength(0) # zero extruded length

            if retract:
                controller.queueGCode("G1 E%f F%f" % (-deprime_amount, prime_speed * 2)) # retract for old style prime/print
            controller.waitForQueueToBeEmpty()
            time.sleep(self.RELIEVE_PRESSURE_WAIT_TIME_2) # replaced marlin dwell with sleep here.

            # Z or E moves do not need to be speed compensated, this is the only here that has a XY component.
            speed = 20.0 * (1 / (controller.getPropertyValue("movement_speed_modifier") / 100))
            controller.queueGCode("G1 Y%f Z2 F%d" % (y + 10, speed * 60.0))    # wipe nozzle down and to the center of the machine.

        elif self._prime_strategy == "none":
            controller.queueGCode("G92 E%f" % -retracted_amount)

The current priming strategy is called turd and seems to be being replaced by EM-1161 in the future. 

To increase adhesion it may be beneficial to reduce the Z distance from 2 to 1 mm. To avoid running in your blob you could also increase the tapping off distance to be further away then the currently set 10mm. 

Or you can change it to something you think is the best priming strategy.

Please be aware that changing files on your ultimaker can brick your machine. 

 

17 hours ago, ghostkeeper said:

The G280 command is implemented by the firmware such that it extrudes a lot of material while slowly moving the build plate down, then tapping the nozzle off on the build plate a few millimetres further. This distance is not encoded in the g-code so Cura can't tweak how many millimetres away from the prime blob the tap happens. It can only enable or disable the prime blob entirely.

I think it would be quite nice if Cura would support some kind of priming sequence, which can be easily edited. 

For this I would probably remove the current prime blob option and replace it with something like this: 

Prime nozzle: Yes/no

          Prime strategy: Machine/Cura

 

[ghostkeeper 105]

4 hours ago, cjs said:

The current priming strategy is called turd and seems to be being replaced by EM-1161 in the future.

The EM-1161 ticket is marked as "Won't fix" so I think that is outdated.

[upatamby 9]

17 hours ago, cjs said:

@upatamby have you tried printing with prime blob disabled? I didn't work for me on earlier um3 firmware version, but seems to be as @Daid said quite good now. 

 

Another solution would be to change the priming strategy on your um3.

 

Thanks @cjs for your detailed answer. 

Yes, I did print with the prime blob disabled. PLA works fine, but PVA doesn't. Even with the prime blob enabled the extrusion of the PVA sometimes starts too late. This  usually happens when I have the PVA loaded but not used for a while. In such cases, before starting a new print with PVA, I move the PVA manually until it starts to extrude (you could call it a manual prime blob). As an extra assurance I also keep the normal prime blob enabled. If necessary I use tweezers to rescue my print from being hit by the PVA-blob. It's not ideal, but I'll deal with it. It's better then an unsuccessful print.

 

I'm not confident to change the firmware code (at least not in the near future). And besides, that would be a task for the Ultimaker team.

 

 

[cjs 34]

On 25.1.2018 at 8:39 AM, ghostkeeper said:

The EM-1161 ticket is marked as "Won't fix" so I think that is outdated.

May I ask what this means? Does it mean that the new strategy doesn't work or that there maybe is something else planned rework wise or nothing at all ?

This problem has already been reported in April 2017 ( Issues with initial knead pulled into the print ). I think it is time to solve it 

 

I can try to change it slightly or turn it into a purge line, but it's not ideal as Cura needs to know how the machine purges in order to block the space on the build plate. 

Therefore I think it is best solved on the Cura side. 

Cura can send "G280 S1" to forward the material and then add the prime before starting the real print.

 

16 hours ago, upatamby said:

And besides, that would be a task for the Ultimaker team.

I agree. 

[yellowshark 153]

Not having a UM3 I am not sure what this prime blob is but I would think that printing a skirt would resolve the problem of it getting dragged in the build area.

[yellowshark 153]

.... of course Cura 3 may have disposed of skirts out of fear of sexual harassment charges but it is good discipline for all the obvious reasons. I do admit I do not print one if I am using a brim but if the brim is big enough it serves the same purpose. 

[ghostkeeper 105]

On 26/01/2018 at 3:22 PM, cjs said:

May I ask what this means? Does it mean that the new strategy doesn't work or that there maybe is something else planned rework wise or nothing at all ?

It means that the feature was rejected.

 

I believe it was rejected because other slicers than Cura might still need a turd.

 

Brim is the default in most of the UM3 profiles, I think. Skirt is still an option though.

Edited January 29, 2018 by ghostkeeper

[kmanstudios 1,120]

ooops...misread post......no comment...move along, move along....nothing to see here........

Edited January 29, 2018 by kmanstudios

[hoegge 6]

But why does the print head absolutely HAVE to collide with the prime blob. Pull further up before moving towards center for printing and continue to extrude a little bit to make a string instead of pulling it in. Furthermore are line on the bed works better.

[cjs 34]

18 hours ago, hoegge said:

But why does the print head absolutely HAVE to collide with the prime blob. Pull further up before moving towards center for printing and continue to extrude a little bit to make a string instead of pulling it in. Furthermore are line on the bed works better.

There is nor reason for it, but as you might have noticed the Ultimaker team does not seem to be interested in changing it. 

Did you try to turn the prime blob off and add a brim/skirt. This should work for now even though it might not be desired in some edge case.   

[cjs 34]

On 29.1.2018 at 10:20 AM, ghostkeeper said:

I believe it was rejected because other slicers than Cura might still need a turd.

Well I don't know how the strategy was going to look like, but I don't think other slicers have a problem with a different strategy. In fact the simplify 3d profile I once used for the UM3 didn't use the blob at all. Instead it did a prime line. 

[ghostkeeper 105]

20 hours ago, hoegge said:

But why does the print head absolutely HAVE to collide with the prime blob. Pull further up before moving towards center for printing and continue to extrude a little bit to make a string instead of pulling it in. Furthermore are line on the bed works better.

It shouldn't collide. It should extrude some material and then tap the nozzle off on the bed (without hitting the blob itself).

That really sounds like a bug to me so I've added a ticket for the firmware team to see if they get this too, with a reference to this topic.

 

Because Simplify3D outputs its own priming anyway then I'd think they want to reconsider the prime line for Cura. Maybe they looked at some other slicers? I don't know.

[ctbeke 133]

My experience with prime lines on other printers is quite successful, maybe it'll work well on UM3 as well?

[hoegge 6]

@cjs Yes I have turned the blob off. I nearly always use a brim or a skirt

[cjs 34]

9 hours ago, ctbeke said:

My experience with prime lines on other printers is quite successful, maybe it'll work well on UM3 as well?

Same here. That's the reason why we are all a bit confused that Ultimaker chose this blob/turd, which seems to regularly not work.  

As said I think it would be best to implement the prime line in Cura. Different Materials may benefit from different speeds and Cura has all the materials and settings. The UM3 has a small portion of it I believe. 

 

10 hours ago, ghostkeeper said:

It shouldn't collide. It should extrude some material and then tap the nozzle off on the bed (without hitting the blob itself).

That really sounds like a bug to me so I've added a ticket for the firmware team to see if they get this too, with a reference to this topic.

Thanks. I think the knock down may be related to a bug in the filament tracking like described here: 

 

10 hours ago, ghostkeeper said:

Because Simplify3D outputs its own priming anyway then I'd think they want to reconsider the prime line for Cura. Maybe they looked at some other slicers? I don't know

Maybe. I haven't heard of any other slicer supporting UM3 as it isn't as easy. 

[robinmdh 100]

On 1/24/2018 at 10:44 AM, ghostkeeper said:

Cura has the ability to prime or not prime with the setting "Enable Prime Blob" under platform adhesion. It's enabled by default.

Cura always writes a command "G280" to the output g-code to indicate that it should prime, but when the prime blob is disabled, this command becomes "G280 S1", which is a signal that the printer should not prime. I don't know why this strange structure was chosen but that's how it works now.

 

The G280 command is implemented by the firmware such that it extrudes a lot of material while slowly moving the build plate down, then tapping the nozzle off on the build plate a few millimetres further. This distance is not encoded in the g-code so Cura can't tweak how many millimetres away from the prime blob the tap happens. It can only enable or disable the prime blob entirely.

Yes Cura can use the G280 S1 as @daid said.

EM-1161 was rejected when we implemented  that command and created an issue to be solved by cura/curaEnigne (@bagelorb (aka Tim) was once upon a time working on this).

Which then didn't happen. after they introduced the option to turn it off.

 

P.S: super late reply because I couldn't find my password when the site changed and my browser didn't remember it for me anymore

[Remote-Pizza 0]

Hey all!

Just wanted to chime in I'm having the same issue. Using a UM3, Cura 4.4.1, PLA on either extruder (single extrusion prints).

 

The prime blob gets hit by the print head every time, resulting in a print blob somewhere on the bed where it shouldn't be. Sometimes a brim or skirt helps, but sometimes it just ends up hitting the hot end (not fun) or it ends up sticking to the print head, together with a little 'hair' of PLA that brushes over the print (not fun either).

 

The fix seems fairly simple to me (and has been outlined above), is this something that has been looked into at all in the meantime @ghostkeeper? Thanks a bunch!

[ghostkeeper 105]

I'm not part of any firmware team so not the best person to ask. I haven't heard of the prime blob being modified recently. I suppose they'd have to tweak things for the S3 but I think they would try to keep the prime blob exactly the same for other printers so that they wouldn't need to re-test that for all materials and nozzle sizes.

 

The UM3 firmware hasn't had an update in almost a year anyway.

[robinmdh 100]

@Remote-Pizza I would simply advise you to turn off the prime blob, this is currently the default in Cura AFAIK.

Or in the case of a 3d party slicer modify the G280 line to read G280 S1 making sure that no G92 is following this.
G280 S1 sets the retracted length away from the nozzle as the negative e position so that G1 E0 meant the filament is at the tip of the nozzle (assuming no oozing or expansion).