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.

Sign up for GitHub

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

Jump to bottom

Initial dance in the start of the gcode #1775

Closed
newphreak opened this issue Nov 2, 2021 · 9 comments
Closed

Initial dance in the start of the gcode #1775

newphreak opened this issue Nov 2, 2021 · 9 comments
Labels
fixed for the next version That means that you should be able to test it in the latest nightly build problem

Comments

@newphreak
Copy link

newphreak commented Nov 2, 2021 •
edited
Loading

Describe the bug

Expected behaviour: goes through start script and starts printing directly.

Actual behaviour: After heating up it goes down to the center of the part, moves up, moves to front left corner, down, up then starts printing.

M109 S205 ; set temperature and wait for it to be reached
M190 S60 ; set bed temperature and wait for it to be reached
;LAYER_CHANGE

#### Weird dance
;Z:0.24
;HEIGHT:0.24
;BEFORE_LAYER_CHANGE
;0.24

G1 Z0.24 F18000
;AFTER_LAYER_CHANGE
;0.24
G1 E-0.3 F1800
G1 Z1.02 F18000
M204 S1500
G1 X22.092 Y22.097
#### Where i actually think it should start
M204 S2000
G1 X44.184 Y44.194
G1 Z0.24
G1 E0.3 F1800
;TYPE:Skirt
;WIDTH:0.44
G1 F2400
G1 X47.204 Y41.175 E0.16223

To Reproduce
Happens to everything i slice, so hopefully my project has some clues if this is not normal behaviour.

>> Project File <<
Voron_Design_Cube_v7_56m_20211102-211326.zip

Desktop (please complete the following information):

  • OS: Windows
  • Version all the latest, even nightly

Additional context
You can find me on discord also: Jon#4961
@newphreak
Copy link
Author

newphreak commented Nov 2, 2021 •
edited
Loading

On second though, this may seem odd on my printers because they home on y and x max position instead of min. I think this is where the difference stems from.
And from older setup's you wouldnt hover the center of the bed during heatup.
I don't home at 0,0 origin, i dont use purge line and i hover in the center of the bed until things are hot. So ideal transition to any user case here would be to move to the start of the skirt, and start printing. Not jumping anywhere before doing so.

@supermerill
Copy link
Owner

it's exactly that.
It doesn't know where it is.
so it move at printing height ( mayyybe could be avoided).
It detect a big move, so it retract and move to a safe height (because first layer i think)
then it moves to the printing point.
Here is a problem: i recently split move in two to distinguish accel and decel, but here it's problematic as I don't know the starting point, assuming 0,0.

@newphreak
Copy link
Author

newphreak commented Nov 3, 2021 •
edited
Loading

Well, during start the plate should be entirely clear, so it should be quite safe to assume it's at a safe height, and that moving directly to print start position should be safe? I fail to see how the aimless jumping to different places would differ.
So hopefully that can be more streamlined.

Start script is done before all this, so start position would either be skirt/brim or perimeters of the part? I'm not a coder so this is probably alot more complicated then i can imagine.

Edit: Prusa 2.4.0-Beta1 does this normally. It heats up, moves down to bed, and moves directly to start position.

@supermerill
Copy link
Owner

supermerill commented Nov 3, 2021 •
edited
Loading

so it should be quite safe to assume it's at a safe height

I have multiple people asking for that because their bed isn't safe.

What i have with prusslicer 2.3.1:

G1 Z0.200 F10800.000
;AFTER_LAYER_CHANGE
;0.2
G1 E-0.80000 F2100.000
G1 Z0.600 F10800.000
G1 X109.943 Y91.476
G1 Z0.200

There is the same "z-dance"

I'm not a coder so this is probably alot more complicated then i can imagine.

the problem is less a code issue than everyone having a different expectation, the only good one.

I'll try to improve a bit to avoid "dance".

@neophyl
Copy link

neophyl commented Nov 3, 2021

If PS beta doesn't do this then wont the issue go away in Susi once its merged ?

@supermerill
Copy link
Owner

I don't think so, as I added more things. I'll see when I merge.

@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 Nov 3, 2021
supermerill added a commit that referenced this issue Nov 4, 2021
@supermerill
lift & lift_min update:
e015c3a 
 * 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
@newphreak
Copy link
Author

Just to make it clear, it's not just the "z-dance", what i wanted solved was the go visit the front left corner then jump back to print was my main oddity here. it has an odd jump "halfway" towards x0 y0, then goes back towards where it's supposed to.

@supermerill
Copy link
Owner

should be fixed.
just a note: to prevent the z-dance, you must have a clean void "after layer change" custom gcode. Or it will go to the layer height anyway before calling the macro.

supermerill added a commit that referenced this issue Nov 6, 2021
@supermerill
lift & lift_min update:
b778d18 
 * 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
@supermerill
Add lift_min: minimum height to travel between objects
f2a9945 
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
@newphreak
Copy link
Author

It's fixed. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
fixed for the next version That means that you should be able to test it in the latest nightly build problem
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@newphreak @supermerill @neophyl