cnckitchen / gradientinfill Goto Github PK

This is a very clever method and I can't wait to try it out. I followed your isntructions and have the python script saved inside the scripts directory. I ran Cura 4.8, sliced a cyliner, clicked on Extensions > Post Processing > Modify Gcode and clicked on add script. GradientInfill was not there. Restarted Cura. Same result. Rebooted everything. Same thing or did I mess up somewhere?

Between Inner-wall and Outer-wall there is not a big difference to test the distance with the infill elements. But Outer-profil are normaly smaller ( just one contour ) so computation time is faster.

The result was inconclusive on a machine equipped with a Bowden feeder. In this case we must change also the feedrate to obtain a better result.

My thought is to use a standard 'Y = A*X^B + C' curve (with user-defined A, B, & C) for the edges to give complete leeway in how the gradient is defined.

Hi just generate some gcode with cura 4.7 in ubuntu with setting proposed in instrucctions but still get the next error when running from command line the python script "python addGradientInfillCLI.py -i FQQS_foilmast.gcode"

File "addGradientInfill.py", line 125, in getXY
return Point2D(float(elementX), float(elementY))
ValueError: could not convert string to float:

seems the parsing is reading some string instead of numbers but don't know why it could be.

Any ideas?.

python used was python 3.7 but tried with python 2.7 but get another error:

File "addGradientInfillCLI.py", line 35
def arg_to_infill_type(arg: str) -> InfillType:
^
SyntaxError: invalid syntax

Yet you manage to write some of the cleanest, best-annotated Python code I've ever read. Bravo!

I love the type hints and the lack of external dependencies.

A couple of small suggestions which are more style/approach opinions than anything else:

• In the main loop, you might consider making the main processing function which expects iter(lines_of_gcode) and returns (or better yet yields) lines as an iterator. Move the file i/o to another function which takes the input file, iterates the lines into the processor, and writes out. The thinking here is to make it easier to eventually integrate into a slicer/gcode pipeline
• I see that there are some comments for syntax using F-strings - IMHO stick with .format for this script and target py3.5-3.7 for compatibility
• Personally, I would parse and validate a line of gcode/comment in a single spot, rather than e.g. #L265 checking if "E" in the string in multiple places. Here's an example regex for parsing gcode. There are python gcode parsers out there, but I like the lack of deps, pip can be daunting for the general audience. No need to get crazy with classes, just a namedtuple or class with slots to contain the values of the fields, or None if not present. Or a dict where keys are letter codes.
• I'd give process_gcode() some sane default parameters
• Add an examples folder with known input/output pairs so contributors can validate their output

Again, excellent work!

Could be interesting to convert this script into a Cura Postprocessing script to test the potential of this new infill method without running the script from a Python IDE and necessity to modify the File Input and Output name.

As usual @smartavionics have done a great job and produced one of his great Cura Master Release with the Gradient Infill option in the experimental section
On github :
smartavionics/Cura#38

https://community.ultimaker.com/topic/31262-gradient-infill-now-supported-by-experimental-cura-builds/

I had the idea that you could potentially implement your desired end goal of topologically defined infill by just post-processing an existing infill method and moving segment points to match the desired density profile. This could be used together with or instead of your current ideas of modifying extrusion amount and feed rate.

Essentially you could evaluate the density at each point (e.g. by distance to closest neighbour, or just to the ends of its segments for a small segment infill), and compare that to the density field that you'd like at that point (e.g. somehow get your stress as a function of position, or to start with just use your 'distance to closest wall' function). From there you can iteratively shift all the infill line points that aren't on perimeters to closer or further from their two nearby points, in order to get closer to the desired densities. The more iterations you run, the closer you get to your desired state.

You can end the optimisation at either a set number of iterations, or a maximum error from the desired densities (this is how very basic machine learning systems work - just iterative progress of an optimisation).