How can I control the moves taken after tpost#.g?



  • When I swap tools, I purposely inject a Z jump of 10 so that any little drips won't wipe on the perimeter of my print.

    I want the behavior to be the following

    1. tfree#
    2. tpree#
    3. tpost# which includes a Z+10 before the wipe command
    4. X and Y are restored, thus any blobs are not dragged into the print
    5. Z position is restored, lowering blob onto the starting position, which if there's going to be a blob, better to have it match where it's printing
    6. print resumes

    The way it's happening now is

    1. tfree#
    2. tpree#
    3. tpost# which includes a Z+10 before the wipe command
    4. Z position is restored
    5. X and Y are restored, thus any blobs are dragged into the print
    6. print resumes


  • @dc42 @Phaedrux

    Any Ideas?



  • Hi,

    Are you doing the X and Y restore?

    I don't see anything in the docs for changing tools that talks about position restoration.

    Frederick



  • @fcwilt I'm 99% sure I'm not, it's just what happens naturally once a print resumes, the tool head has to move into position to start printing.


  • Moderator

    Checking.



  • @gnydick said in How can I control the moves taken after tpost#.g?:

    @fcwilt I'm 99% sure I'm not, it's just what happens naturally once a print resumes, the tool head has to move into position to start printing.

    Hi,

    Please post your pause.g and resume.g files using the </> tag

    That is where I have the commands that control position restoration.

    Thanks.

    Frederick



  • pause and resume aren't used during tool changes. I've even gone so far as to manually store and retrieve the positions, and nothing happens when I click through the dialogs

    ;tfree#.g
    
    G91
    G1 Z20
    G90
    
    M291 S2 P"About to store the position"
    G60 S0 ; save the current position
    M291 S2 P"Just stored the position"
    
    ;tpost#.g
    M291 S2 P"About to restore the position"
    G1 R0 ; restore the current position
    M291 S2 P"Just restored the position"
    


  • @fcwilt

    OMG --- I just looked at what was generated in the resume.g. That's my answer!!



  • @gnydick

    Hi,

    From the G60 docs:

    Slots 0, 1 and 2 are available. When a print is paused the coordinates are saved to slot 1 automatically, and at the start of a tool change the coordinates are saved to slot 2 automatically. Use G0 or G1 with the R0, R1 or R2 parameter to move the current tool to a saved position.

    It mentions the position being saved automatically to slot 2 but it says nothing about automatic restore.

    Frederick



  • @gnydick said in How can I control the moves taken after tpost#.g?:

    @fcwilt

    OMG --- I just looked at what was generated in the resume.g. That's my answer!!

    You said resume.g was not involved.

    Confused.

    Frederick



  • @fcwilt it gave me an example of how to use the R parameter properly with G1



  • @fcwilt, EVERYONE, et al

    So, here's a summary of the behavior.

    1. Without using G60 in my tool changing scripts, the print resumes by moving to the next position in the gcode. That is where the newly current tool will start. This changes Z, then moves to the XY, rubbing the print.

    2. With using G60 in my tfree# tool changing scripts, the print resumes at the last position of the previous tool. That is bad, as I don't want the tool to come down over the previous traces.

    So, I want the XY progression from #1, since it moves to the first position of the new tool, but I don't want it to change Z first, then slide into the print area.

    Does this make sense?



  • @gnydick

    I understand what you are saying but having never used a multi-tool printer I don't understand why it is needed.

    Is the tool change tied to a layer change?

    So none of the abilities mentioned here regards using G1 with R can get you what you want?

    Rn Return to the coordinates stored in restore point #n (see G60). Any X, Y, Z and other axis parameters in the command are used as offsets from the stored position. Axes not mentioned are not moved, so use offset 0 for axes you want to restore to the stored value. For example, G1 R0 X0 Y0 Z2 will move to 2mm above the position stored in restore point 0.

    Frederick



  • @fcwilt

    No, it's not what I want. Let's say I'm printing in RED, I change tools to BLACK. Even if I'm using G60 with a Z offset, then when G1 R0 X0 Y0 Z15 the BLACK tool will move to 15mm above the last RED position, and when that's finished, it still lowers all the way down to whatever the correct Z position is for the next move, before moving XY to the first BLACK position.

    That in a nutshell is what I can't seem to defeat. The "let me lower all the way down before moving XY" behavior.


  • administrators

    As @fcwilt says, you can achieve the result you want using restore point 2. For example:

    G1 R2 Z2 ; move to 2mm higher than the restore position
    G1 R2 X0 Y0 Z2 ; move to 2mm above the restore position



  • @dc42 that doesn't work

    G1 R2 Z2 moves 2mm above the last position, but then the Z height lowers to the restore point, then XY to the first BLACK point

    G1 R2 X0 Y0 Z2 only additionally moves over the last point first.

    Either way, the Z is changed FIRST to the next point, which is bad. It will always wipe the print.



  • @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.


  • administrators

    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.


  • administrators

    @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.


Log in to reply