UM not properly performing retraction between prints during "one at a time"

[aviphysics 9]

It seems like Cura could really use an option to do retractions between prints during "one at a time". Currently it leaves a trail of filament between prints.

Also, it seems like Cura primes the print head before each print during "one at a time", which seems unnecessary and can create a blob that interferes with the print.

 

[aviphysics 9]

Actually, I am now really confused, because it seems like this actually is written in the G-Code

 

G92 E0
G1 F2400 E-4.50000
G0 F9000 X100.40 Y130.60 Z11.00
;Layer count: 98
;LAYER:0
G0 F3600 X98.63 Y129.06 Z0.30
;TYPE:SKIRT
G1 F2400 E0.00000

So, I would guess from this that the problem is somehow happening on the ultimaker. Any ideas?

 

[gr5 2,172]

I'm confused too. I usually do all-at-once. The 2 or 3 times I didn't it "primed" right over part of my second print and made a bit of a scary mess and dragged it around while I tried to grab it with my fingers.

The gcode shows retract only. Maybe look at some more gcode before and after this bit?

Other (competing) printers/slicers do the start of the "skirt" near the front edge of the printer - a line maybe 50mm long to clean the nozzle before starting the skirt.

I don't want to always have to grab the initial prime with my fingers. Especially yesterday when I was trying to talk to people at a show at the same time.

 

[aviphysics 9]

Look at the G-code again.

The relevant bits are

Line 1: G92 E0 ;resets extrusion coordinate to 0

Line 2: G1 F2400 E-4.50000 ;supposed to perform retraction

...

Line 8: G1 F2400 E0 ;supposed to reset filament.

My suspicion is that something in Merlin is blocking the move to a negative number using the G1 command, but somehow takes -4.50000 as the new coordinate.

I think the easiest fix would be to reword the code to prevent the negative retraction. Perhaps a find/replace on Line1/2 with

 

G92 E4.5
G1 F2400 E0
G92 E-4.5

 

[gr5 2,172]

Oh! Yes! Genius. It's probably a software endstop. What a stupid feature for the E axis. There are other solutions such as put it in "relative" mode.

Can you verify this fix? I'm away from home until late tonight. If you verify it we should alert Daid. This bug has been around for a long time but "one-at-a-time" is not done all that often - probably because of this bug!

 

[Dim3nsioneer 557]

It's just a very quick thought: Can you exclude that you are in relative positioning mode (G91)? Because then it would make sense that only the retract but not the priming command is executed...

[aviphysics 9]

Finished trying what I suggested and it still didn't do the retraction. My only thought now is that it is ignoring the line immediately after the G92 command for some reason.

I feel kind of stumped.

Going try to put a pause command or something between the G92 command and the retraction.

@Dim3

The problem is that the retract isn't being executed. Only the priming step is being executed.

 

[aviphysics 9]

Inserting a 100 ms G4 command didn't work.

I also tried inserting an extra G1 command with no effect. edit: I probably should have made the first G1 command "G1 F2400 E0" and the second "G1 F2400 E-4.5" edit: still didn't work. (BTW, based on the results of my last trial, I don't think it is a soft stop issue.)

IIRC correctly, there is a command console in Cura for manually entering G-Code. I think I need to spend some time playing with that to see if I can figure out what the problem might be. However, right now I have some other tasks I need to do.

 

[aviphysics 9]

I manually wrote the following code to try to trouble shoot the problem. It ran correctly, which kind of leaves me stumped as to what the problem is.

 

M109 T0 S225.000000
T0
G21        
G90        
M107       
G28 X0 Y0
G28 Z0     
G1 F9000
M117 Printing...
G1 Z10
G92 E0
G1 F500 E1
G92 E0
G0 F500 X20 Y20 E1 ;move and extrude as if printing
G92 E0           ;set E to 0
G1 F2400 E-5     ;retract 5mm
G0 F9000 X10 Y10 ;perform rapid movement
G1 F2400 E0      ;put filament back
G28 X0 Y0
M84

[Dim3nsioneer 557]

It's really a strange kind of behavior.

I just made a quick test with my UM1 with two simple objects 'one at a time'. The GCODE (sliced with Cura 14.01) included the retract and priming command as posted above. The UM performed both retract and priming when changing from one object to the other. It's the same directly via USB and via SDCard/Ulticontroller.

Do you use the standard Marlin or a personalized version?

 

[aviphysics 9]

It's really a strange kind of behavior.

I just made a quick test with my UM1 with two simple objects 'one at a time'. The GCODE (sliced with Cura 14.01) included the retract and priming command as posted above. The UM performed both retract and priming when changing from one object to the other. It's the same directly via USB and via SDCard/Ulticontroller.

Do you use the standard Marlin or a personalized version?

 

I use the standard Marlin.

I patched it when I first got the UM sometime in late Nov or early Dec.

However, it did just occur to me that I had to install Cura on a new computer to try printing directly and when I did that, I went ahead and updated the firmware again. It seems possible that may have solved the problem. Perhaps it wasn't flashed correctly the first time, or there was an update between then and now. That might explain why the last bit of code ran without issue.

Edit: I ran the original code again this morning and it now seems to be doing retractions between parts. I guess I will never know for sure what the problem was, but I am guessing the firmware flash fixed it.

 

[gr5 2,172]

strange.