Modified color change g-code seemingly executes out of order, or simultaneously when unexpected
I've been trying to write some custom color change g-code for my Core One after installing a silicon wiper mod. I want it to wipe after changing so that if the purge material doesn't fall from gravity, it gets knocked off before continuing printing, without me having to open the door and let out hot air.
The simplest order of operations is to change material, wipe nozzle, resume printing. I found that I could change M600 to M600 N to get it to not immediately return to printing after changing, but I next had to figure out how to get it to return after the wipe. What I came up with - and correct me if there's a better way - was to run G60 S1 before M600 N, then G61 S1 after wiping to return to the original location before resuming.
That led to my first problem, which was the print head colliding with the print, because it would try to return in the most direct path, and that would be through the print. The solution to that was to run G61 S1 Z before G61 S1 to move up before moving over. That solves the issue... in theory.
This is where the real problems started. For whatever reason, it seemed to completely skip over G61 S1 Z and continue in the straight path. Later on after some poking, it seemed like it may have executed the command somewhere in the mix of what it was doing, but it certainly wasn't immediately prior to the G61 S1 like it was supposed to be. This would lead to the collisions continuing.
Through trial and error, though, I found that I could get it to move up before moving over if I put enough space in the code between the G61 S1 Z, G61 S1, and the part where it actually resumed the printing process. I did this by adding a slight Z raise between G61 S1 Z and G61 S1, which provides the added benefit of additional height clearance when returning.
That just seemed to kick the can down the road, though. Instead of resuming printing after returning to the position, it would instead start moving, but just kind of stop to print at random points? Or something like that? It's hard to tell. There's a lot happening at once, not in the correct order.
While trying to figure out a solution, I was reading the RepRap wiki page for g-code, and came across G4: Dwell. I knew it existed, but what I missed was a line "Pnnn Time to wait, in milliseconds (In Teacup, P0, wait until all previous moves are finished). I thought that might work in Prusa as well. Alas, it was not meant to be. It seemed to have no effect. What it did, however, was give me the idea to add short dwells that might cause it to wait until it's properly in position to resume printing.
What I found was... nope. It wouldn't. It would change how it acted, but still not make it work correctly. So now, I'm out of ideas and I'm coming to you, the forum. Below is the g-code I have for Color Change G-Code. Here is a pastebin link for the .gcode file for my test piece. You can ctrl+f in it for "M600 N" to get to where the color change happens. Below is also a video of what happens when I run that g-code. Please help.
Color change g-code:
G60 S1 ; Save current position M600 N ; Execute color change. Do not return to previous position. ; Use the wiper to clean the nozzle G0 X80 Y-19 F10000; Move to right side of wiper at current height G0 Z2.4 F10000; Move down to wiper height G0 X-2 Y-14 F10000; Move to left side of wiper G0 X113 Y-19 F10000; Move to right side of wiper G0 X-2 Y-14 F10000; Move to left side of wiper G0 X113 Y-19 F10000; Move to right side of wiper G0 X-2 Y-14 F10000; Move to left side of wiper G0 X113 Y-19 F10000; Move to right side of wiper G61 S1 Z ; Raise back to previous height G91 ; Set to relative mode for next move G0 Z10 ; Move up by 10 more millimeters G90 ; Return to aboslute mode M83 ; extruder relative mode G4 P100 ; Dwell G61 S1 ; Return to previous position G4 P100 ; Dwell G1 E0.3 F1500 ; prime after color change
Video:
RE: Modified color change g-code seemingly executes out of order, or simultaneously when unexpected
Bumping this. My next stop is going to be the github, I think, because I'm starting to lean more towards thinking it's a bug.
RE: Modified color change g-code seemingly executes out of order, or simultaneously when unexpected
I'm trying to do exactly the same thing and having the same problem. Did you find a solution?
RE:
I ran into exactly this issue. The problem is that G61 S1 Z is not a “do this now” motion command. It is a state restore request that gets deferred and sometimes partially merged with other moves (especially around M600). That’s why spacing, dummy Z moves, or dwells appear to work without making it really work as intended.
I don't do a lot of multicolor/material prints on the C1 since it's a PITA (I'm waiting for my INDX to arrive). I did come up with something like:
; Save print position G60 S1 ; Filament change without auto-resume M600 N ; ------------------------------ ; Wipe sequence ; ------------------------------ ; Go to a known-safe wipe Z G90 G0 Z10 F6000 ; Move to wiper G0 X80 Y-19 F10000 G0 Z2.4 F6000 ; Wipe passes ... ... ; ------------------------------ ; return to print ; ------------------------------ ; Absolute, deterministic clearance G0 Z20 F6000 ; hard safety lift ; Restore XY ONLY (no collision risk) G61 S1 X Y ; Restore Z AFTER XY is complete G61 S1 Z ; Ensure extruder mode matches PrusaSlicer M83 ; Small prime to re-seat filament G1 E0.3 F1500
RE: Modified color change g-code seemingly executes out of order, or simultaneously when unexpected
Thanks. I can't get this to work, G60 and G61 commands just don't seem to execute. Some research seems to turn up that G60/G61 isn't implemented in Prusa firmware. After a lot of tests and crashes, I'm moving to a Python solution to post-process the g-code to add in wipe codes.