Cura: G10 and G11 problem using Cura 2.5 release and One at A Time (Ultimaker 2+)

[emtemt]

Hi

I have just used multiply and one at a time to print a number of small parts on an Ultimaker 2+.

Unfortunately the first part printed fine but there was no filament extruded on the second part for ages so no skirt and no bottom layers. Looking at the code I see a G10 at the end of the first part which I understand is retraction and then a G11 at the beginning of the 2nd part which I understand should reverse the G10.

I commented out the G10 and the parts all printed OK but with a little stringing. I am therefore sure the problem is caused by the G11 not working. Is this a Cura issue or a Firmware issue (Or even a materials setup)?

Regards

Ian

[Ghostkeeper]

Well, Cura should put the G11 there since the retractions and unretractions on the UM2+ are parametrised by the firmware. That is, the firmware decides how long they should be and how fast to retract. By the looks of it, Cura is behaving as it should.

A workaround for now is to go into Manage Printers, select your UM2+ and go into Machine Settings. There you can set the G-code Flavour to Reprap (Volumetric). This replaces the G10s and G11s with G1s with an E parameter, like normal extrusion. If that works, then perhaps we have a firmware bug on our hands here.

@daid Do you know of G11 not working on the UM2+? It seems to me that this should've been found by system testing but given their recent track record...

[daid]

As far as I know G11 worked fine. It stores the distance that it needs to push forward at the G10. So I'm not sure if everything is going fine if you have a G92 E0 between a G10 and G11?

[BagelOrb]

Please attach your gcode. There could be something wrong with one-at-a-time mode.

Perhaps there's a double G11 in the gcode or maybe it is the G92 E0 problem. Let's see the gcode.

[daid]

I think the firmware ignores a double G11. As the amount of retraction is set to 0 at the end of a G11. But a double G10 could be problematic.

[emtemt]

OK G Code attached
UM2_SolarWireClip.zip

[emtemt]

Hi
I have investigated this further. G10 and G11 work perfectly elsewhere in my g code.
The problem is caused by an interaction between G92 E0 and the G10/G11
One at a time generates this code between the 2 parts.
G1 F1200 X116.166 Y114.986 E300.45617
G1 X116.227 Y114.925
;TIME_ELAPSED:352.447647
G10
G92 E0
G0 F7200 X116.227 Y114.925 Z7
G0 X102.807 Y46.203
;LAYER_COUNT:18
;LAYER:0
G0 F4800 X99.765 Y48.131 Z0.27
;TYPE:SKIRT
G11

If you move the G10 so it is AFTER the G92 E0 I see no problems on my job.

I have no idea why the G92 E0 has any effect on the retract so I still don't know if this is a Cura problem or a firmware problem.

Regards

Ian

[daid]

It's because G10 stores the E value to return to with G11. As G92 resets the E value, G11 no longer knows which E value to return to, or goes to the wrong value.

[Ghostkeeper]

Seems to be a bug in CuraEngine then. Thanks for the analysis.

[daid]

Well, you could argue that the firmware behavior is also wrong. But I think it's easier to fix in Cura?

[Ghostkeeper]

I think so too, yeah :P In any case I've made a ticket.

[fieldOfView]

As long as we can agree it is not my fault, I'm happy

[daid]

Blaming @fieldOfView would be the best way. Yes. It's your fault. Always.

[BagelOrb]

I'm gone for a couple of hours and I get the blame? Typical!

I'll see if it's easy to solve in the engine.

[BagelOrb]

Errr. I can remove the G92 E0 altogether there. I don't know whether that would be safe, though.

[BagelOrb]

I think there's no problem in just removing it.

The firmware bug does mean that dual extrusion will fail on the UM2, though. Every time we switch extruder we reset the extrusion value before we unretract. That cannot be changed.

[emtemt]

If you remove the G92 E0 does that mean the second part will be coded with an E values carrying on from the first part. At the moment presumably it codes from zero:-
(This is my edited version that works OK)
G1 F1200 X116.166 Y114.986 _E300.45617_
G1 X116.227 Y114.925
;TIME_ELAPSED:352.447647
G92 E0
G10
G0 F7200 X116.227 Y114.925 Z7
G0 X102.807 Y46.203
;LAYER_COUNT:18
;LAYER:0
G0 F4800 X99.765 Y48.131 Z0.27
;TYPE:SKIRT
G11
G1 F1800 X100.213 Y47.317 _E0.0878_

[BagelOrb]

The E value now continues to move forward on the second print..

[tcm0116]

There appears to be a similar issue with tool changes. Below is a snippet of a GCode that was generated by printing two 5cm cubes with one being assigned extruder 0 and the other extruder 1. The printer is issued a G10 S1 command to perform a tool change retraction, but then immediately issued a G92 E0. The T1 tool change command is issued followed by another G92 E0. Finally, another G10 is sent to retract the new tool, but that's an error since the last retraction command received by that tool would have been a G10 S1 with no corresponding G11. The net result is that the filament is never re-loaded into the newly selected tool after a tool change.

The G10 that is issued next is ignored because the extruder is already extracted. The G11 then would try to re-load the filament, but since the extruder position has been reset to 0, the extruder will be advanced to the re-load length (say +16 for example), but then the next G1 call will retract it back instead of actually extruding.

(Note that retract_length_swap is the value passed to the W parameter of M207).

G1 F1800 X48.89 Y51.719 E38.18895
G1 X48.96 Y51.789
G0 F3600 X48.96 Y51.5
G10 S1 ; E[0] -= retract_length_swap
G92 E0 ; E[0] = 0

T1
G92 E0 ; E[1] = 0

M109 S200
M104 T0 S190
G0 X48.96 Y51.5 Z0.3
G10 ; ignored because E[1] is already retracted
G0 X48.96 Y61.5
G0 X47.509 Y58.491
;TYPE:SKIRT
G11 ; E[1] = retract_length_swap (+16 for example)
G1 F1800 X46.818 Y58.451 E0.08306 ; E[1] retracted back to 0.08306 instead of being advanced

I think the easiest solution would be to remove the G92 E0 commands from after the G10 S1 and TX commands, and place a G11 followed by a G92 E0 after the M109 command, which would allow the firmware to re-load the extruder after it's reached the proper temperature and reset the extruder position to 0 in preparation for the next G1 E command (as a side note, I think it would make more sense to place the M104 command before the M109 command so that the inactive extruder doesn't sit there oozing while the active one heats up). Here's how it would look (annotated with the removals and additions):

G1 F1800 X48.89 Y51.719 E38.18895
G1 X48.96 Y51.789
G0 F3600 X48.96 Y51.5
G10 S1 ; E[0] -= retract_length_swap
; G92 E0 ; deleted

T1
; G92 E0 ; deleted

M104 T0 S190 ; new
M109 S200
G11 ; new - E[1] += retract_length_swap
G92 E0 ; new - E[1] = 0
; M104 T0 S190 ; deleted
G0 X48.96 Y51.5 Z0.3
G10
G0 X48.96 Y61.5
G0 X47.509 Y58.491
;TYPE:SKIRT
G11
G1 F1800 X46.818 Y58.451 E0.08306

[BagelOrb]

Dual extrusion is a whole nother issue.
Do you have an Ultimaker 2 dual extrusion??

[tcm0116]

Do you have an Ultimaker 2 dual extrusion??

No.

Dual extrusion is a whole nother issue.

Should I create a separate issue, then?

[Ghostkeeper]

As far as I know, we only generate G10 and G11 commands in the UltiGCode flavour. And the UltiGCode flavour is only used for the Ultimaker 2 family.

I don't think it's necessary to create another issue. It looks like it's the same bug but in a different place.

[tcm0116]

It's available by selecting the "RepRap (Volumetric)" selection for the
"GCode Flavor" option in the machine settings for any Custom FDM Printer.
As far as I can tell, that option has been there for a number of years.

[jackha]

Deferred because of inactivity