Add "Change Z Height" to Change at Z post processing script

[weaseljohnson]

Is your feature request related to a problem?

This is an effective solution to elephants for for the cases where elephants foot is related to backlash or z binding in the first few layers.

Describe the solution you'd like

I'd like for an option to be added to the 'Change at Z' post processing script which allows you to change the z height at a specific layer. This would accomplish the same thing as manually adjusting the z offset once a specific layer starts.

The solution would be to change the Code at the specified layer in a similar way that the current 'z offset' setting does. The z height at the specified layer would be adjusted by the set value, then a G92 command would be executed to set the current position of the z axis to the value it was before being adjusted by the modification.

Example: G0 F300 X112.797 Y123.91 Z0.5 ; rather than incrementing to 0.4 from 0.2, z is modified to add 0.1 resulting in 0.5 G92 Z0.4 ; set printer coordinate system to z=0.4, the original z before modification

Describe alternatives you've considered

There are other methods of resolving elephants foot, initial layer horizontal expansion, to name one. However, this does not fully eliminate elephants foot as E.F. is usually caused over the first several layers, not just the first layer. Also, changing the initial layer horizontal expansion can cause issues with small details on the first layer.

You could also tune your extrusion settings.

However, once you've tuned the typical fixes, backlash (especially) or z-binding in the first few layers can still cause elephants foot.

Affected users and/or printers

Anyone suffering from elephants foot could potentially benefit.

Additional information & file uploads

No response

[GregValiant]

This can be done with Search and Replace using Regular Expressions. Something like this: Search: ;LAYER:2\n Replace: ;LAYER:2\nG92 Z0.3\n Regular Expressions: checked The "\n" is a newline character. By using regular expressions you can avoid replacing 20,21,22 201, etc.

[weaseljohnson]

@GregValiant, I did consider Search and Replace but dismissed it because seemed like it doesn't really provide a good solution. The z move happens before the "Layer" comment in the Gcode. Also, simply setting the coordinate system z won't make the gantry move up; G92 isn't a movement command.

The line you would have to replace is the line directly after the ";Mesh:Nonmesh" line. That line is exactly the same for each layer so you couldn't search a specific line to change the Z. Also, in order to properly replace the Z value, you'd have to know the exact values of x, y, and the feed rate in the line directly after the mesh:nonmesh line. So the Search and Replace feature doesn't make things any easier than just opening the Gcode file and making the changes manually.

[weaseljohnson]

@GregValiant I am still fairly new to messing with Gcode, would this work? Again, the issue is that the z-move happens before the "LAYER" callout in the code. So, I'd need the gantry to move up, as well as reset the coordinate z before starting to print the layer.

Search: ;LAYER:2\n Replace: ;LAYER:2\nG0 Z0.5/nG92 Z0.4\n Regular Expressions: checked

Another thing is that I feel like it would work better to replace the actual z movement right after the mesh:nonmesh line because that would cause a larger z-movement. If I tell it to move up .1 or .05 right after the "Layer" line, then that is potentially a much more challenging movement to do accurately/successfully. Do you know what I mean? Moving to the adjusted Z height all at once, rather than increments, would probably result in a more accurate z-movement overall. That's why I thought adding a 'Change Z Height' to the "Change at Z" script would be a good solution.

[GregValiant]

Altering ChangeAtZ or creating a simpler post script to do what you want might be options. You may be waiting for for a while until someone alters the very complex ChangeAtZ script. Whether to put the time and effort into a change often boils down to how many people would benefit from the change. You proposed Search and Replace looks good and it's easy to check within the gcode to insure it went in correctly. It's also something you can do now instead of having to wait.

[weaseljohnson]

@GregValiant, agreed. Thank's for your help!!