Dual Extruder Nozzle Change Motion Sequence Problem

[jonwienke]

Cura Version

5.8.0

Operating System

Windows 10

Printer

Any

Reproduction steps

Printing using dual extrusion.

Actual results

1. Nozzle lifts by retraction_hop_after_extruder_switch amount
2. Current extruder retracts by switch_extruder_retraction_amount
3. Extruder switches
4. New extruder primes by (switch_extruder_retraction_amount + switch_extruder_extra_prime_amount)
5. Move to Prime Tower
6. Lower nozzle by retraction_hop_after_extruder_switch amount
7. Print a layer of Prime Tower

This sucks, because even when switch_extruder_extra_prime_amount is -3mm³ or more, priming always drops some strings of crap into the print. This is especially bad when printing with dissolvable support, because now you have voids in your print where the support drool prevented layers from bonding. Best case is you have garbage strings sticking out from the print you have to trim off. In my use case, I'm printing custom sunshades for optics that have black infill and a second color on the outside, and the drool garbage makes the print unsalable unless I spend a bunch of time trimming the strings out of the honeycomb, which is a huge PITA.

Expected results

The extruder switch sequence should be as follows:

1. Nozzle lifts by retraction_hop_after_extruder_switch amount
2. Move to center of Prime Tower
3. Lower nozzle by retraction_hop_after_extruder_switch amount
4. Current extruder retracts by switch_extruder_retraction_amount
5. Extruder switches
6. New extruder primes by (switch_extruder_retraction_amount + switch_extruder_extra_prime_amount)
7. Print a layer of Prime Tower

Doing this will dump all of the garbage string drool crap into the interior of the Prime Tower, where it won't contaminate the print.

Add your .zip and screenshots here ⬇️

Thank you for coming to my TED talk. sunshade.zip

[GregValiant]

Thanks for the report. There are a couple of things here. The first is that Cura does not directly support IDEX printers and the second is that (from what I've read) it appears that Flash Forge Creator IDEX printers really want you to use Flash Print.

There are machines like the Raise3D IDEX machines and the SOVOL sv04 that can be made to work with Cura pretty easily. The Creator "2 Pro" and "Pro 3" appear to be different. It might also depend on the age of the printer and the firmware version. Some "Creator" IDEX machines don't understand "G0", only use "relative" Z moves, and require extensive post processing to get Cura to work with them.

In addition, Ultimaker does the heavy lifting when it comes to the code in Cura. Cura is necessarily optimized for UM printers like the S5 and S7. UM cannot be expected to go out and buy one of every printer on the planet in order to see what might be required by each model. Your comment that this "bug" applies to "Any" printer would seem to be off the mark. Those of us with one of those "other printers" must adapt.

All that being said, when I slice your project, after completing the purge at the prime tower there is a retraction before the nozzle moves back to the model. This happens to be a switch from T0 to T1 but switching from T1 to T0 appears to be the same sequence. (I've switched to "relative extrusion" so it's easier to read.) G1 F1500 E-20 > Retract by extruder switch amount G1 F900 Z7.4 > Z-hop of 5.0 M135 T1 > Switch to T1 ........... > Temperature lines (removed by me) G1 F750 E19 > Unretract by Switch amount (20.0) minus Retract Distance (1.0) G1 F900 Z7.4 > Z-hop move to the same 5.0 as previous ;MESH:NONMESH G0 F15000 X-5.4 Y-45.647 Z7.4 > Move up 1 layer height G0 X-5.417 Y-46.893 > Travel to prime tower ;TYPE:PRIME-TOWER G1 F900 Z2.4 > Drop down to working height G1 F1500 E-0.24726 > Unretract 1.0 plus the Extra Prime of -3.0mm³ (1.0 -1.24726 mm of filament = -0.24726 retraction) When the prime tower has finished there is this: G1 F1500 E-1 > Retract G1 F900 Z2.8 > Regular Z-hop 0f 0.40 ;MESH:Sunshade OD 63_075_Nightforce.stl G0 F15000 X-24.727 Y-16.242 Z2.8 > Travel to the start of the infill ;TYPE:FILL G1 F900 Z2.4 > Drop down to working height G1 F1500 E1 > Unretract

That all looks to be correct. There is a retraction at every instance where a tool finishes at the prime tower and before it returns to the print. When either tool starts back on the prime tower, there is an additional retraction since your "Extra Prime Amount" is a negative value.

Your description of "Actual Results" appears to be different than the sequence of events I see in the gcode I generated.

Retract by extruder switch amount (20.0) Z-hop of 5.0 Switch to T1 Unretract by Switch amount (20.0) minus Retract Distance (1.0) = +19.0 Travel to prime tower Drop down to working height Unretract 1.0 plus the Extra Prime of -3.0mm³ (1.0 -1.24726 mm of filament = -0.24726 retraction)

Are you confident that the retractions and primes are happening as they should? Some Creator 2 and 3 machines want the parameters in a particular order. G1 F1500 Exx.xxxxx might not be understood if the printer needs to see G1 Exx.xxxxx F1500. That is probably dependent on the firmware version.

Right now I don't see a bug here because what I see in the gcode (that I generated) looks correct. Did you happen to have any special post processors running in your Cura installation? Have you tried enabling "Wipe inactive extruder on Prime Tower"? Some IDEX machines have a "Head Park" macro that runs at tool changes. Is your inactive nozzle moving to a park position?

[jonwienke]

You've completely missed the point here. The order of the gcode commands is 100% the problem here, not the brand of printer or the firmware version.

The M135 T0/T1 command should NEVER happen while the nozzle is over the print when a Prime Tower exists. It should ALWAYS happen while the nozzle is over the Prime Tower. The advance after the extruder switch always pushes some material out of the nozzle, even if switch_extruder_extra_prime_amount is set to -5mm³, because of air in the hotend being displaced during the advance, and the fact that Cura is advancing by switch_extruder_retraction_amount - retraction_amount distance (G1 F750 E19) and then doing a second move later on to advance by switch_extruder_extra_prime_amount (G1 F1500 E-0.24726). That guarantees that the new extruder is going to crap on your print, no matter how far negative you set switch_extruder_extra_prime_amount. It would be better to have only one extruder change advance/unretract command immediately prior to printing the Prime Tower layer, and it should be switch_extruder_retraction_amount + switch_extruder_extra_prime_amount.

Wiping the nozzle on the Prime Tower after the extruder switch doesn't do crap, because that doesn't happen until after the extruder switch advance/unretract has already crapped all over the print. The correct gcode is:

G1 F1500 E-20 > Retract by extruder switch amount G1 F900 Z7.4 > Z-hop of 5.0 ;MESH:NONMESH G0 F15000 X-5.4 Y-45.647 Z7.4 > Move up 1 layer height G0 X-5.417 Y-46.893 > Travel to center of prime tower before switching extruders so all the unretract drips, blobs, and strings get scraped off inside the prime tower before printing the actual print resumes ;TYPE:PRIME-TOWER G1 F900 Z2.4 > Drop down to working height M135 T1 > Switch to T1 ........... > Temperature lines (removed by me) G1 F750 E18.75274 >Advance by Switch amount (20.0 + (-1.24726) = 18.75274mm net advance )

Placing the M135 command and filament unretract commands immediately before printing the Prime Tower layer has several benefits:

1. The inactive nozzle gets wiped on the Prime Tower when it moves out of the Prime Tower during the execution of the M135 command.
2. All of the drip/drool strings and blobs that happen during the advance/unretract after switching extruders happen inside the Prime Tower, where they will get wiped off on the Prime Tower when the Prime Tower layer is printed.
3. Basically both nozzles get wiped for free without having to add any additional gcode commands or printing an ooze shield , and the wipes happen before either nozzle gets anywhere near the print.

[jonwienke]

Side note: It would be preferable for the Prime Tower to use the same coordinate system as models. It's confusing when the Y axis values are opposite everything else, and the coordinates don't reference the center of the tower.

[GregValiant]

It would be nice to be able to just drag and drop the prime tower as well. I don't think it's a mesh though, just a shadow that Cura sticks onto the build plate as a reference.

I dabble in post-processors and I just scribbled up "Move Tool Changes". It cuts the tool change code out and then pastes it back in after the travel moves to the prime tower. So your tool change will happen at the prime tower location. See if it works for you.

It changes this: G1 F1500 E-20 G1 F900 Z11.45 M135 T0 M104 S250 M116 M104 S250 M116 G1 F750 E19 G1 F900 Z11.45 ;MESH:NONMESH G0 F15000 X10.32 Y-58.183 Z11.45 G0 X9.008 Y-58.731 ;TYPE:PRIME-TOWER G1 F900 Z6.45 G1 F1500 E-0.24726

To this: G1 F1500 E-20 G1 F900 Z11.45 ;MESH:NONMESH G0 F15000 X10.32 Y-58.183 Z11.45 G0 X9.008 Y-58.731 ;TYPE:PRIME-TOWER M135 T0 M104 S250 M116 M104 S250 M116 G1 F750 E19 G1 F900 Z11.45 G1 F900 Z6.45 G1 F1500 E-0.24726

Unzip the file and put "Move Tool Changes.py" into your Configuration Folder and the "scripts" sub-folder. It will be available under "Extensions | Post Processing | Modify G-Code" and then "Add a Script". ("Prime Tower" must be enabled or it exits). MoveToolChanges.zip

Let me know if there are issues, and also if it works satisfactorily. This fix might also work for the Modix IDEX printers (although the problem they have is slightly different).

[jonwienke]

It would be nice to be able to just drag and drop the prime tower as well. I don't think it's a mesh though, just a shadow that Cura sticks onto the build plate as a reference.

It doesn't even need to be drag and drop, just make the coordinates work such that X75, Y50 centers the prime tower on the same build plate point that a model placed at X75, Y50 would go (not that you'd likely want to do that IRL unless the model had a big hole in the middle).

The gcode edit script result looks good, I'll give it a try. The only question I have is whether it will run before GPX is called to convert the file to x3g. I'll let you know how it goes. The only thing I would change further is to delete G1 F750 E19 and change G1 F1500 E-0.24726 to G1 F750 E18.75274 to prevent over-advancing when switch_extruder_extra_prime_amount is negative and simplify the output code a bit.

Moving the M135/M104/M116 block should improve print quality of all multi-extruder prints, regardless of printer brand or firmware version.

[jonwienke]

There appears to be one minor bug in your script results, a duplicate Z move:

G0 F15000 X10.32 Y-51.817 Z1.45 G0 X9.008 Y-51.269 ;TYPE:PRIME-TOWER M135 T0 G92 E0 M104 S250 M116 M104 S250 M116 G1 F750 E19 G1 F900 Z1.45 G1 F900 Z0.45 G1 F1500 E20

It looks to me like the G1 F900 Z1.45 is redundant and could be deleted. It's not going to hurt anything if the head is already at layer height + retraction_hop_after_extruder_switch, but couldn't it be omitted?

[GregValiant]

The stock code is: G1 F900 Z11.45 ;MESH:NONMESH G0 F15000 X10.32 Y-58.183 Z11.45 but I cut everything up to the "MESH:NONMESH" line so the Z-hop line went with the cut lines. It is the original "Z-hop at tool change" and that second line with the X Y in it is the regular "move up to the next layer height" line that is always there when Z-hops are enabled. So not a bug but rather an unexpected side effect of "quick and dirty". It was seven lines past the tool change and it's still seven lines past the tool change.

[GregValiant]

All this depends on your settings. If you disable z-hop on retraction the gcode is one way. With it enabled it's another way. Adding all the if-come-whens and what-ifs is beyond what I was doing. It is true that with your settings the line has no function but that wouldn't always be the case.

[jonwienke]

Gotcha. I'm waiting on a print to finish, but once it's done I'll test your script and let you know how it goes.

[jonwienke]

OK, there is some kind of glitch in the first layer. The first nozzle change is supposed to happen BEFORE the prime tower is printed. T0 (orange) prints the innermost 3 lines of the skirt and the outer walls of the models, then the printer is supposed to switch to T1 (green), print the outermost line of the skirt with T1, and then the base of the Prime Tower.

But instead of switching extruders to T1 when preparing to print the outer skirt line, the printer makes a rather scary-sounding banging noise and jerks the print head hard enough to skip steps, which causes everything printed afterward (including the base of the Prime Tower) to be offset about 3-4mm to the left.

The outermost skirt line prints with T0 instead of T1, but the base of the prime tower prints correctly with T1.

My best guess is that you need to add a condition to your script so that it doesn't try to relocate any M135 commands until after the first layer of the Prime Tower has printed. It doesn't matter if the skirt has blobs or other extruder change artifacts.

gcode file for reference if that helps: Sunshade OD 63_075_Nightforce.zip

[jonwienke]

Below is a photo of the print before I aborted it. You can see the black infill is not centered within the tan outer walls of the top center model, and the prime tower base is not centered between the two lower models as it should. I also circled the place the outer wall should have started printing in black (T1) and where it actually started printing with T0.

One correction: The loud bang and the step skipping didn't happen until the actual nozzle switch at the beginning of the Prime Tower base. The printhead normally moves about 20mm/s when changing extruders, either right or left to position the new nozzle where the old one left off. But for some reason it tried to do it full rapid (~300mm/s) like a G0 got swapped in for a G1 or something somewhere. Anyway, I hope this helps you make sense of things.

[jonwienke]

I think I have a solution to the bug, but I'm not a Python programmer so I don't know how to write it with the correct syntax.

    if self.getSettingValueByKey("move_tool_changes"):
        for num in range(2, len(data)-1):
            lines = data[num].split("\n")
            modified_data = ""

           #dummy loop that scans through the file until it finds the first instance of ";TYPE:PRIME-TOWER"
            for index, line in enumerate(lines):
                if line.startswith(";TYPE:PRIME-TOWER"): 
           #add whatever code goes here to skip ahead 10 lines, exit the dummy loop and continue scanning

            for index, line in enumerate(lines):
                if line.startswith("M135") or line.startswith("T"):
                    pull_lines = ""
                    p_index = index
                    # Pull out the lines before the travel moves to the prime tower
                    while not lines[p_index].startswith(";"):
                        pull_lines += "\n" + lines[p_index]
                        lines.pop(p_index)
                    modified_data += lines[p_index] + "\n"
                    continue
                # Add the pulled lines back in after travel to the prime tower
                if line.startswith(";TYPE:PRIME-TOWER") and pull_lines != "":
                    lines[index] += pull_lines
                    pull_lines = ""
                modified_data += lines[index] + "\n"
            data[num] = modified_data
    return data

Does that seem even remotely plausible?

[GregValiant]

I changed this a bit. There should be some improvement. The script doesn't change any lines, it just reorders them. The speeds seem to be fine so I'm not sure what was up with that. I changed the filename to "MoveIDEXToolChanges.py" and you can delete that first version. MoveIDEXToolChanges.zip I'm trying to make this "ambidextrous" so it will work with any IDEX printer that shares this problem. Let me know if it's getting closer.

[jonwienke]

OK, I made a smaller test file and let it run, and discovered that EVERY relocated extruder change is screwing up. Travel happens normally going to and from the Prime Tower and while printing the print, but the movement associated with the nozzle change instantly goes to 100% full speed rapid and then stops instantly. Basically the acceleration and jerk settings are being completely ignored for that one movement or are being set impossibly high, and it's causing the X motor to skip steps. Here's a video:

https://github.com/user-attachments/assets/a909a901-e0d5-43c5-b832-1e172f9b3070

My guess is that the script reordering the gcode is somehow munging the x3g conversion. Perhaps the x3g conversion plugin starts before the script runs, and changing the gcode breaks something in the conversion process? Anyway, here's the final result:

Blue is T0, white is T1.

[GregValiant]

Within a "virgin" gcode the travel speed is 250mm/sec (which you have set in Cura). Re-ordering the lines (as the script does) doesn't change that. M135 T0 G92 E0 M104 S250 M116 M104 S250 M116 G1 F750 E19 G1 F900 Z5.45 ;MESH:NONMESH G0 F15000 X10.32 Y-51.817 Z5.45 G0 X9.008 Y-51.269 ;TYPE:PRIME-TOWER G1 F900 Z0.45 G1 F1500 E18.75274 G1 F1200 X8.107 Y-49.583 E18.81533

Although the commands are re-ordered by the script, no values are changed. Losing steps on an axis is usually caused by one of two things:

• The Acceleration setting is too high for the machine.
• There is slippage in the drive train (a loose belt or coupling).

Makerbot firmware handles Accel and Jerk differently than Marlin and other firmware flavors. From what I've read; M201 (Max Accel), M204 (Print and Travel Accel) and M205 (Jerk) are not supported in Makerbot. The Accel and Jerk values must be set on the LCD, and enabling or disabling Accel/Jerk control must also be handled on the LCD. If you have Accel enabled on the printer, you can try lowering the value. An inspection of the X axis mechanicals might also be a good idea. You can try dropping the travel speed to see if it helps, but my guess would be that the problem is elsewhere.

[jonwienke]

I've checked all the mechanical stuff and it's fine.

The issue is that the normal speed, acceleration, and jerk limits that are applied everywhere else are totally ignored during the extruder change move. If you look at the video closely, you can see that speed, acceleration, and jerk settings are applied normally during printing and when the printhead travels to/from the Prime Tower. It's just the M135 travel move that makes the abnormal bang-bang noise and skips steps.

I agree that it's not a bug in your script; the altered gcode looks just fine. It's something either in the GPX / x3g converter plugin or possibly the machine firmware. I'm going to try setting up Octoprint; it has a plugin that dynamically converts gcode to Makerbot's format. that might bypass the issue.

[GregValiant]

Within the Cura Machine Settings, there is no "XY Offset" between the nozzles of your printer but there obviously is an offset.

That shuffle move that brings the next nozzle to the position where it needs to be (in order to align itself to the print) is being handled by the firmware. Maybe that distance is set wrong in the printer and rather than a layer shift, you have an improper index distance??? I don't know if that could be true though as it would seem to require that the distance going from T0 to T1 would need to be different than the distance when going from T1 to T0. That would be kinda dumb and isn't really likely.

Have you tried talking to MakerBot about it? Maybe it's something that has come up previously.

I think this is moving from a possible Cura bug to a probable firmware problem with the macro that M135 seems to run. Let me know what you think.

[jonwienke]

The nozzle switch XY offsets are parameters set in the printer that the M135 macro checks when it runs. THey aren't in the gcode or x3g file. When I calibrated the offsets, I printed the same x3g file with a calibration model a couple of times, and I didn't have to update the offsets in the x3g file, just in the printer settings.

I don't think issue is just a firmware bug, because if that was the case the extruder switch macro would be borked all the time regardless of what called it. I think it's some kind of unintentional interaction between the firmware and the X3GWriter plugin that somehow only bugs out when the normal Cura > plugin > x3g data flow gets disturbed. The extruder switch glitch never happens when using Makerbot Desktop, or Cura without the script.

I think it might be worthwhile to have the X3GWriter plugin dev @Ghostkeeper take a look at things, just to cover all the bases.

It's also possible that reordering the commands in Cura instead of after the fact with a script might solve the issue. Long term that's the preferred method IMO, because then the nozzle could be sent to the center of the prime tower before M135 to get the free wipe of both nozzles on the tower.

[jonwienke]

So it gets even weirder.

I set up Octoprint on an extra Pi I had, configured the GPX plugin, sent it my test gcode...and got the EXACT SAME RESULTS.

With the script enabled, bang-bang and skipped steps when M135 executes. With it disabled, motion is perfect, but I get dribbles on the print during extruder switches.

I'm at a loss.

[GregValiant]

Will the firmware accept a simple "T" line for the tool change (instead of M135), or are you stuck with the M135 line?

[jonwienke]

T0 and T1 work as solo commands, at least from Octoprint's console.

[jonwienke]

Another possible consideration: Look at the command that immediately precedes the M135. I had a similar extruder switch oddity in my startup gcode (abnormally fast movement, but it didn't skip steps), and it went away when I put the G92 commands in front of the M135s for unrelated reasons:

;Following code primes extruders without cluttering build plate G1 X-100 Y-60 F6000; move printhead to front left G0 Z0.3; Set plate height to knock strings off nozzles without crashing G1 B40 F300; prime left extruder G92 B{retraction_amount}; Reset left extruder position G1 F900 B0; retract left extruder G92 B0; redundant, but still necessary :( M135 T1; switch to left extruder to wipe left nozzle G1 X100 Y-60 F6000; move printhead to front right G1 A40 F300; prime right extruder G92 A{retraction_amount}; Reset right extruder position G1 F900 A0; retract right extruder G92 A0; redundant, but still necessary :( M135 T0; switch to right extruder to wipe right nozzle

Suggestion: don't insert immediately after the ";TYPE:PRIME-TOWER" line. Insert it after the G1 Z movement that always follows ";TYPE:PRIME-TOWER" That's the only difference I can see between your script output gcode that always fails and the original gcode that always works: G0 + M135 bad, G1 + M135 good.

Putting the M135 after the Z drop will also have the benefit of wiping the inactive nozzle on the prime tower as it moves away.

[jonwienke]

Also, inserting G1 F{speed_prime_tower} X{prime_tower_position_x} Y{prime_tower_position_y} between the Z drop and the M135 would reduce the amount of blobs on the Prime Tower and make the nozzle less likely to rip it loose. The excess extrusion of the nozzle change would be extruded as a string away from the tower wall, and get scraped loose while printing the tower instead of making a lump/blob on the tower.

[GregValiant]

This version moves the cut lines to below the Z-hop down line. G92 E0 ;MESH:NONMESH G0 F15000 X10.32 Y-51.817 Z5.45 G0 X9.008 Y-51.269 ;TYPE:PRIME-TOWER G1 F900 Z0.45 M135 T0 G92 E0 M104 S250 It doesn't "look" for the Z-hop line, just re-inserts the cut code 1 line lower. MoveIDEXToolChanges.zip

[jonwienke]

That should work, I'll try it out.

[jonwienke]

It worked!

100% correct function, no bang-bang or abnormal movement, and all of the extruder switch schmutz (say that 5 times fast) gets dumped on the prime tower instead of the print. The blobs on the tower don't seem to be a huge problem as long as the prime tower has at least 2 walls and the prime tower print speed is kept low.

[jonwienke]

Actually, the tower blobs are a potential problem when a few of them from consecutive layers get stacked on top of each other and they add together. Inserting G1 F{speed_prime_tower} X{prime_tower_position_x} Y{prime_tower_position_y} between the Z drop and the extruder switch is probably going to be necessary to keep the nozzle from getting snagged on a blob pileup and breaking the tower loose from the build plate.

[GregValiant]

I have absolutely no idea why that line would make a difference. It's gotta be something in the M135 macro in the firmware.
;TYPE:PRIME-TOWER G1 F900 Z1.5 G92 E0 G1 F3600 X10 Y-65.0 M135 T1 G92 E0 MoveIDEXToolChanges.zip

[jonwienke]

Could very well be; most likely a feed variable not getting cleared after a G0 that gets cleared after a G1 or G92. In this case the workaround also happens to be an improvement to the movement sequence. Win win. I'll let you know how the test goes.

[jonwienke]

I ran into several problems, and took the liberty of fixing them myself:

1. Adding the G92 command caused more trouble than it solved, so I deleted it. As long as the command preceding the extruder change is not a G0, the M135 macro respects travel speed, acceleration, and jerk limits, and the X motor won't skip steps.
2. The extra travel move added just before the extruder switch was going to the front right corner of the prime tower, not the center, so I added a bit of code to put in in the center of the prime tower.
3. For the first several mm of prime tower printing, it's preferable for the blobs to be spread out around the perimeter of the prime tower to prevent the formation of the megablob you get when the priming waste sticks to the build plate after the nozzle moves to the same place repeatedly. So I added a condition that prevents the travel to center move from being added until the prime tower is >= 20x the nozzle diameter. That's tall enough for the waste to stay a string that gets dragged to the inner wall of the prime tower vs a megablob that builds up in whatever location the nozzle moves to.

MoveIDEXToolChanges.zip