Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Combine XY and Z moves at the start of the print #241

Closed
combolek opened this issue May 12, 2020 · 11 comments
Closed

Combine XY and Z moves at the start of the print #241

combolek opened this issue May 12, 2020 · 11 comments
Labels
enhancement fix is live in the last release Please download /build the last release and try to reproduce.

Comments

@combolek
Copy link

Version

2.2.50

Operating system type + version

Windows 10 (18363) 64-bit

3D printer brand / version + firmware version (if known)

TwoTrees Sapphire-S upgraded with Klipper v0.8.0-526-gf0c394de and SKR 1.4 Turbo

Behavior

  • Describe the problem

At the begining of the print the head always first drops to the initial layer height and then does a fast horizontal move to the correct (x, y) location (this is all after the custom start G-code).

  • Steps needed to reproduce the problem

Slice the attached project
Observe the G-code at start (after home and custom g-code):

  • Expected Results

Single 3D move would be safer in case the bed is not perfectly level

G1 X85.317 Y77.452 Z0.200 F9000.000
  • Actual Results

First Z drop, then XY move

G1 Z0.200 F9000.000
[...]
G1 X85.317 Y77.452 F9000.000

Is this a new feature request?

Yes (I think?)

Project File (.3MF) where problem occurs

belt_tensioner.zip

@supermerill
Copy link
Owner

problem is, before going to z= first_layer_height + zlift, we don't know the z of the printer.
Unless we scan the custom start gcode to be sure it's not too low, we suppose it's at 0.
this feature willc reate many special cases on various places with potential side-effects and complicated safeguards... not very keen of it.

but i think it's possible to add a mega-zlift for the first layer. basically if layer_heught == lift "above_z", then double the z_lift. Enough?

@combolek
Copy link
Author

Yeah, I am certainly not asking for parsing custom gcode. But I don't think I understand the issue. Can we just first go to a safe Z eg. 10mm and then combine the initial Z and XY moves into a single XYZ move. The X, Y and Z values can stay exactly the same as original, there is no need to compute or know anything else. What am I missing?

@supermerill
Copy link
Owner

supermerill commented May 13, 2020

problem is that you have to go back from "10mm" and at the right place, and that is a bunch of special cases, as it interacts with lift, offset, and some others things. it's possible but tedious.

@combolek
Copy link
Author

OK, so can you explain the mega-z-lift workaround? I didn't get that either :-( What is z-lift? Can you describe the sequence of moves that would happen?
Thanks

@combolek
Copy link
Author

OK, so I found that Z lift in Slic3r++ is what Cura calls Z hop on retraction. I then realized that maybe you meant this: lower to the first layer height as it is now, then raise Z by some amount and then do the XY move and then lower again. Is this what you meant? If so, I think this would work as long as the Z raise amount is not tied to the "Z lift on retract", because that may have to be set independently (e.g. forced to be 0). It would have to be a separate parameter but maybe a hard coded value would work too.
Am I understanding correctly?

@supermerill
Copy link
Owner

supermerill commented May 14, 2020

yes.
i was thinking something like 2* first layer hieght. so with Z z-lift and 0.2 first layer height, it will go to 0.6. when moving quikly, for all moves on the first layer.

oh, you can already do that right now. just add an other extruder, set the z-lift of the first extruder to 2mm, slice, add an extruer change at the second layer, and that's it! (it's for testing purpose, as it's a bit of an inconvenience, but it's exactly the behavior i propose).

should i add a hardcoded minimum distance for the mega-lift, like more that 10*extruder width ?

@combolek
Copy link
Author

I think this would work. So with z-lift=0 and first layer=0.2mm this will travel at 0.4mm? I would not even bother with all travel moves, just the initial move to starting XY. In general I do not like to use any z-hop/z-lift. But if you do implement it for all travel moves then yeah, I think some minimum distance is needed.
Thanks

supermerill added a commit that referenced this issue May 15, 2020
…height)

can be disable if no z-lift is used for the extruder of the current object.
can be enable with no z-lift by using random value for z-lift and retract_lift_above to 9999
@supermerill supermerill added the fixed for the next version That means that you should be able to test it in the latest nightly build label May 15, 2020
@supermerill
Copy link
Owner

Finally, i accepted that i need to tinker with the current lift, much simpler to do. So it's you first idea, more or less.
you can read the commit comment for explanation of what it does.

@combolek
Copy link
Author

Thanks, I downloaded the latest CI build with this change but I am getting strange results. I set

retract_lift = 5
retract_lift_above = 1000

but I am still seeing this in the g-code:

G1 Z0.200 F9000.000
G1 E-2.00000 F2400.00000
G1 X88.492 Y84.838 F9000.000

so it still does the initial travel move at the first layer height. Also, later in the g-code I see this:

G1 Z0.600 F9000.000
G1 X106.582 Y95.068
G1 Z0.200

???
Project and g-code attached
belt_tensioner.zip

@supermerill
Copy link
Owner

oh, i added it before each object, but not the skirt ... i'll correct that

@supermerill supermerill added fix is live in the last release Please download /build the last release and try to reproduce. and removed fixed for the next version That means that you should be able to test it in the latest nightly build labels Jun 3, 2020
@combolek
Copy link
Author

Thanks!

supermerill added a commit that referenced this issue Nov 4, 2021
 * At the first move, merge Z-move and don't split the travel, so the printer won't "dance", whatever where the nozzle is.
Note:it's a hack, please redo it properly when reworking gcode-writer.
 * retract_lift_first_layer is gone back to the old simple behavior (revert b16ecbf)
 * removed auto extra lift for first layer, now that lift_min exists.
 * with complete object, don't unlift at object/first layer change, to avoid Z-dance
 * lift_min will be used between brims, skirts, objects but not between object-skirt, object-brim and their object
#1783
#1775
#1575
#599
#429
#395
#241
supermerill added a commit that referenced this issue Nov 6, 2021
 * At the first move don't split the travel
 * At the first move, if start_gcode_manual and no layer_gcode, don't lift the nozzle so the printer won't "z-dance", whatever where the nozzle is.
Note:it's a hack, please redo it properly when reworking gcode-writer.
 * retract_lift_first_layer is gone back to the old simple behavior (revert b16ecbf)
 * removed auto extra lift for first layer, now that lift_min exists.
 * with complete_object, don't unlift at object/first layer change, to avoid Z-dance
 * lift_min will be used between brims, skirts, objects but not between object-skirt, object-brim and their object
#1783
#1775
#1575
#599
#429
#395
#241
supermerill added a commit that referenced this issue Nov 6, 2021
Also change other behaviors to be compliant:
 * At the first move don't split the travel
 * At the first move, if start_gcode_manual and no layer_gcode, don't lift the nozzle so the printer won't "z-dance", whatever where the nozzle is.
Note:it's a hack, please redo it properly when reworking gcode-writer.
 * retract_lift_first_layer is gone back to the old simple behavior (revert b16ecbf)
 * removed auto extra lift for first layer, now that lift_min exists.
 * with complete_object, don't unlift at object/first layer change, to avoid Z-dance
 * lift_min will be used between brims, skirts, objects but not between object-skirt, object-brim and their object
#1783
#1775
#1575
#599
#429
#395
#241
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement fix is live in the last release Please download /build the last release and try to reproduce.
Projects
None yet
Development

No branches or pull requests

2 participants