How can I control the moves taken after tpost#.g?
-
@gnydick said in How can I control the moves taken after tpost#.g?:
@dc42 that doesn't work, because the restore position is the last RED position. And after G1 R0 (or R2) happens, the Z height lowers down to the print, then XY moves to the first BLACK position.
What I don't understand is this.
Why doesn't BLACK need to start extruding at the last RED position?
If it was a single color with no tool changing/pausing there would be extrusion between the two points - not a gap.
Frederick
-
@fcwilt because it's two different objects. Why would black start where red left off?
-
@gnydick said in How can I control the moves taken after tpost#.g?:
@fcwilt because it's two different objects. Why would black start where red left off?
Well that makes a world of difference.
So back to a single extruder setup.
It would reach the end of the first object - stop extruding - move to the next object and start extruding. Correct?
So does it matter if it changes extruder before moving to the next object if it has already stop extruding?
Frederick
-
@fcwilt with a single extruder, if it's "changing" tools like a filament swapper, yes, it's still a separate object (depending on the slicer).
I like to use the "separate shells" option which provides full perimeters, tops, and bottoms on the different objects.
-
I see, you want to change tool and then resume position at the start of the next printing move, not the start of the travel move from the old part being printed to the new part. The problem here is that when RRF executes the T move, it hasn't processed the following G0 or G1 moves (or any other moves that might come first), so it doesn't know whether the next move starts printing immediately or not.
If you know that after a tool change there will always be a travel move before the next printing move, then you could try using G60 in the tpost file to store the XY coordinates of a point away from the print, along with a Z coordinate higher than the print, to restore point 2. Then it would move to that position after a tool change.
-
@dc42 exactly, sort of
I would really just prefer the behavior of the firmware to be different. I don't understand why it executes Z alone, then the XY when restoring the position. Because, no matter what the intermediate point is, it still Z-downs all the way to the point where it will scrape the print when it resumes.
-
@gnydick said in How can I control the moves taken after tpost#.g?:
@dc42 exactly, sort of
I would really just prefer the behavior of the firmware to be different. I don't understand why it executes Z alone, then the XY when restoring the position. Because, no matter what the intermediate point is, it still Z-downs all the way to the point where it will scrape the print when it resumes.
It executes Z first to take account of any change in tool offset. Otherwise, if you selected a tool with a lower nozzle than the old one and didn't raise it, the tool would crash into the print. I guess it would be possible to add a test for whether the nozzle height of the new tool, taking the offset into account, is already at least as high as the resume location, and only make that automatic Z move if it is lower.
If you put the commands I suggested at the end of tpost.g (to place the head 2mm above the restore point), then the automatic Z move will only occur after the XY position has been restored. Then it's just the travel move to the new print that you have to worry about.
There is some code that handles object cancellation that might be usable to achieve resuming at the start of the first print move of the new piece. Basically, after a tool change we could behave as if we have just skipped a cancelled object and are about to start a non-cancelled one.
-
@gnydick
Other people use a wipe-tower to remove any blobs. Is that an option for you?
Or is it the scraping that's bothering you? -
@dc42 If the Z move that's happening is the offset adaptation, then I believe it's including the position of the next point instead of just adjusting the current offset.
I would expect the Z offset adjustment to happen, THEN X, Y, and Z all move to the next point. Since my 2 tools are the same Z offset, I shouldn't see a lone Z move in that case.
-
@o_lampe I have a wipe tower, even with that, what happens is the extruder comes down where it shouldn't, so little leaks/oozes can still happen on contact.
-
I am building a printer with independently actuated hotends and running into the same issue. 100% agree with OP that this should not be how firmware tool changes are handled. Any update?
-
@dc42 said in How can I control the moves taken after tpost#.g?:
I see, you want to change tool and then resume position at the start of the next printing move
Is there a way to change the way resume functions? The way I see it, my gcode looks like
Assume Z = 1
1 G1 X### Y### E### ; last move for color 1.
2 G10 ; retract 2mm hop, Z = 3
3 T1 ; tool change algo
4 ; tfree,pre,post,resume
5 G1 X### Y### ; travel to new position to start color 2, Z = 3
6 G11 ; untretract Z = 1
7 G1 X### Y### E### ; Start printing again.Why cant I just have resume do nothing? Step 4 moves end effector away, does its thing to change nozzles, and applies the XYZ offsets but does not resume. Now I have a state where my tool is loaded and the next command is to move to the new XY position.
-
@tangent1 are you saying that the tool change doesn't take account of the Z hop when it completes? Because if it does take account of the Z hop, it should be above the print until the G11 is executed.