Dual Extruder Nozzle Change Motion Sequence Problem #19472
Comments
jonwienke
added
Status: Triage
GregValiant
added
Status: Needs Info
|
Thanks for the report. 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. 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. 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.
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. |
|
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 Placing the M135 command and filament unretract commands immediately before printing the Prime Tower layer has several benefits:
|
github-actions
bot
removed
the
Status: Needs Info
|
Side note: |
|
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. It changes this: To this: 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). 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). |
|
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. |
|
There appears to be one minor bug in your script results, a duplicate Z move: G0 F15000 X10.32 Y-51.817 Z1.45 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? |
|
The stock code is: |
|
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. |
|
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. |
|
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: |
|
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. |
|
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. Does that seem even remotely plausible? |
|
I changed this a bit. There should be some improvement. |
|
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: 20240806_220712.mp4My 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. |
|
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. Although the commands are re-ordered by the script, no values are changed.
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
Will the firmware accept a simple "T" line for the tool change (instead of M135), or are you stuck with the M135 line? |
|
T0 and T1 work as solo commands, at least from Octoprint's console. |
|
Another possible consideration: ;Following code primes extruders without cluttering build plate 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. |
|
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. |
|
This version moves the cut lines to below the Z-hop down line. |
|
That should work, I'll try it out. |
|
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. |
|
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. |
|
I have absolutely no idea why that line would make a difference. It's gotta be something in the M135 macro in the firmware. |
|
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. |
|
I ran into several problems, and took the liberty of fixing them myself:
|
|
I fixed one more issue. On taller prints, dumping everything in the center of the prime tower eventually creates a megablob that's a nozzle snag hazard, regardless of how much space is under the nozzle when you start. So I tweaked the extruder switch point to scan across the interior of the prime tower in a grid pattern intended to minimize the possibility of adjacent priming blobs adding together and creating a megablob. The pattern covers the interior of the tower evenly, but it doesn't ever let the extruder switch happen in the same XY location twice. |
|
There is one significant remaining bug I don't know how to fix: when you select a Normal prime tower instead of Interleaved and there are a series of layers that are all supposed to print with the same extruder, the prime tower extruder switch gets borked such that the print layers alternate T0 and T1 instead of being all T0 or all T1. The modified script and and example gcode file are attached. In the example gcode, all the bottom layers below the lettering are supposed to be T0 instead of alternating T0 and T1. |
|
It looks like both extruders are being used until the flat area finishes. Extruder 2 only: This is layer 15 with Extruder 1 only: And layer 15 showing Extruder 2 only: This is the exruder sequence: Is that the way you set it up? Alternating layers like it does at the beginning is odd, but the model could be designed for that to happen. I would have expected an M104 line to turn off Extruder 1 when it finishes at the end of layer 29 but there isn't one and it stays hot until the end of the print. That might be something in your settings. |
|
The alternating layers is the problem. The first 5 layers are all T0 (except for the prime tower) in the Cura project, and they all print T0 when I use an interleaved prime tower. The glitch is that extruder isn't switching back to extruder [x] when the only time extruder [!x] is used is in the prime tower. When both extruders are used to print models in a layer, the script works correctly. The unused extruder cools down as expected when using an interleaved prime tower, so that's part of the glitch. |
|
Here's a comparison between always switching in the center of the prime tower (left) vs staggering the location to spread the garbage evenly inside it: The big mass in the center of the left tower sticks out about 2mm above the rim. If the print had been much taller, it's likely a nozzle collision with the blob could have broken the tower loose. The tower on the right doesn't have anything protruding above the outer rim. |
|
On the left print - all the "extra prime" material is being deposited right in the middle at the same XY every time. That's making that lump in the center and it does keep getting taller. I have a script to convert the project to a single extruder and I did a test print. The "extra prime at tool change" causes the printer to lose steps because that blob is plugging the nozzle. |
|
On the left print - all the "extra prime" material is being deposited right in the middle at the same XY every time. That's making that lump in the center and it does keep getting taller. Correct. And for both prints, switch_extruder_extra_prime_amount was set to zero. My printer is just really basically a cognitively impaired toddler when it does long retractions and advances, which is the whole reason this thread was created in the first place. Most of the garbage inside the prime tower was ending up on or in the print and making a bloody mess of things. I've since set switch_extruder_extra_prime_amount to -2.381 and that helps, but setting it more negative than the volume associated with retraction_amount does nothing because Cura does two advance moves after an extruder change: the first is switch_extruder_retraction_amount - retraction_amount, and the second is retraction_amount + retraction_extra_prime_amount (denominated in millimeters, rather than mm³). I have retraction_amount set to 1mm, and -2.381 is the volume that corresponds to 0.99mm given a 1.75mm filament, so using that value comes very close to zeroing out the second extruder advance. But making retraction_extra_prime_amount more negative than that is pointless, because the first advance move is always the same and retracting after the filament has already advanced does nothing to prevent drool.
The tower on the right was printed with retraction_extra_prime_amount set to -2.381. You can see that there's less crap inside the right tower than the left, but there's still a lot of crap that needs to go somewhere other than on the print.
The base of this prime tower was printed with the extruder switch happening over the tower wall, and switch_extruder_extra_prime_amount set to zero. The blobs are 2-3mm in diameter, and I had several prints fail when a nozzle caught on a blob and either ripped something loose from the build plate or snagged hard enough to make the axis stepppers lose some steps. Before creating this thread, those blobs were happening on the print in the form of strings. At any rate, a lot of progress has been made. Compare this print to the photo in the first post: There are a couple of really fine stray hairs in the bottom right, but they are at the top of the print and easily removed, vs being embedded down in the grid where removal is a huge PITA.
I appreciate your help so far. |
|
This intrigued me enough to write another little script for myself. I already had one to create "practice files" that are movement only with no extrusions. That saves some filament when I'm fooling around comparing toolpaths. I took that another step and now can convert a dual extruder print into a single extruder print with no extrusions. Instead of actual tool changes it beeps once for T0 and twice to indicate T1. I like it. Much of what I've seen here so far did start pointing to the printer. I've never had a hobby before that required the number of workarounds that 3d printing requires. Everything is a friggin' head scratcher. I don't like the M109 commands at the tool changes. The print head just sits there waiting. If I actually had a multi-extruder machine I'd certainly be tempted to make all the temperatures the same and use Search and Replace to change any M109's into M104's and see it that's workable. Having the tool change occur over the print and then have the nozzle wait for a minimum of 10 seconds must leave divots in the print. |
|
The purpose of the grid algorithm I wrote is to spread the love around fairly evenly inside the prime tower so you don't get zits, you just get a rat's nest confined inside the prime tower where it can't hurt anything. That eliminates the risk of the nozzle snagging. |
|
Over the last 3 or 4 years I've written post processors for a variety of situations that have come up here, or on the UM Forum. Some of them are niche things that I have found useful. You can download "Little Utilities v25" from my Git page. It's a compilation of about 25 different post processors.
If you decide to use them, be careful. They work for my Ender, and where applicable the code is in there for "Origin at Center" machines, but your printer is different and you may find something odd or that just doesn't work. |
|
Did you get the normal prime tower glitch fixed in the move tool change script? |
Cura Version
5.8.0
Operating System
Windows 10
Printer
Any
Reproduction steps
Printing using dual extrusion.
Actual results
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:
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
The text was updated successfully, but these errors were encountered: