Add InfillCode plugin

[st7ma784]

• You have read the "Registering a new Plugin" guide.
• You want to and are able to maintain the plugin you are registering, long-term.
• You understand why the plugin you are registering works.
• You have read and acknowledge the Code of Conduct.

What is the name of your plugin?

InfillCode

What does your plugin do?

Having filament run out can be a pain and waste perfectly good prints and filament. This plugin edits the spacing of linear infill layers so that a camera can detect where the print got to, and create gcode to resume from where the print stopped!

Where can we find the source code of your plugin?

https://github.com/st7ma784/infillcoder

Was any kind of genAI (ChatGPT, Copilot etc) involved in creating this plugin?

Yes - Claude has helped with some of the logic

Is your plugin commercial in nature?

No,

Does your plugin rely on some cloud services?

No

Further notes

InfillCode embeds a per-layer fingerprint into 3D print infill line spacing. When a print fails, a webcam snapshot identifies the last completed layer and generates a resume GCode file automatically. I quite like using Arc-welder (shout out!!) so this is set to auto-process .aw.gcode uploads, startup bed scan, mid-print health monitoring with rolling score, optional auto-pause, one-click resume button.

[jacopotediosi]

@st7ma784 First of all, thank you for your contribution!

Unfortunately, I'm unable to review your plugin until the PR template has been filled out - it should appear automatically when opening a PR in this repository.

That template helps us reviewers work more efficiently and ensures that plugin maintainers have read all the necessary documentation and accepted the terms.

We've noticed that a few recent PRs, also from other users, have been missing it, so just a friendly reminder - please take a moment to complete it, and I'll be happy to proceed with the review. Thanks!

[jneilliii]

missing closing header indicator....add this here.

---

[jneilliii]

we prefer to not have images load from external website/sources. look at how other plugins (all of mine include paypal links for example) are saving these and referencing.

[jneilliii]

should be your own copy of the image you want to use and linked from a folder /assets/img/plugins/infillcode/ as part of this PR.

[jacopotediosi]

I'm trying to write this comment as calmly as I can, because I want to be constructive, but I'm also quite frustrated.

This plugin reads as AI-generated slop, and submissions like this aren't respectful of reviewers' time: generating it takes a few prompts, while reviewing it and articulating what's wrong takes hours.

A standard OctoPrint plugin follows a well-defined structure, based on the cookiecutter template and the official documentation. This plugin's repository does not. It has an unusual nested structure: the top level is a wrapper for building documentation and the site that serves it, plus some library files. The actual plugin code lives under octoprint_plugin, but even that folder isn't self-contained, because the core folder is pulled in from the top level into release artifacts via a build step.

I'm not sure this layout is compatible with installation via the Plugin Manager at all, given that it expects a path containing the entire plugin code in one place, without intermediate build steps. It certainly won't work via the URL declared in the archive field of this PR's manifest, which points to the main branch - i.e., the entire repository, not just the plugin folder.

Beyond that, there are numerous issues:

• Some files (README.md, LICENSE) are duplicated between the top level and the inner plugin folder, with nothing visible that keeps them in sync.
• The "full documentation" link in the README.md returns 404.
• The README's install instructions claim the plugin can be installed via pip install infillcode, but the package is not registered on pypi.org. This smells like an AI hallucination.
• Both requirements.txt and pyproject.toml are present, which is an odd combination, and again nothing seems to keep the two dependency lists aligned.
• Inside octoprint_plugin, setup.py and pyproject.toml don't match the expected structure, miss several required fields, and contain other oddities (e.g., long_description is set to the contents of ../README.md, a path that escapes the package directory).
• In the plugin's __init__.py, the SimpleApi endpoints are only placeholders, and the plugin update hook is not implemented.
• Under octoprint_plugin/infillcode/templates/ there is an unexpected path static/infillcode.js, which from reading it appears to be a stale, broken copy of octoprint_plugin/infillcode/static/infillcode.js.

There are many other parts of the code that don't add up. The resume logic in particular emits the following hardcoded G-code commands that I find questionable:

# Position to resume Z with a hop
hop_z = round(resume_z + z_hop_mm, 4)
init_lines.append("; --- Position to resume layer ---\n")
init_lines.append("G90 ; absolute positioning\n")
init_lines.append("M83 ; relative extrusion\n")
init_lines.append(f"G1 Z{hop_z:.4f} F600 ; lift to clear ooze\n")
init_lines.append("G1 X5 Y5 F6000 ; move to prime corner\n")
init_lines.append(f"G1 Z{resume_z:.4f} F600 ; descend to resume Z\n")
# Short prime purge
init_lines.append(f"G1 E{prime_length_mm:.1f} F{prime_feedrate:.0f} ; prime nozzle\n")
init_lines.append("G92 E0 ; reset extruder\n")
init_lines.append("; --- Resume layers ---\n")

Some modes are set unconditionally (e.g. G90, M83), and then the file body from the resume layer onwards is concatenated and will run under these modes - not necessarily the ones that were active during the original print. This can result, for example, in the resume layer extruding far more than expected because of the switch from absolute to relative extrusion, producing a large blob at the resume point. There's also that absolute G1 Z<resume_z>: on many printers, after a reset the firmware loses the Z reference, and in response to that command the toolhead can end up anywhere.

Overall, I believe this plugin should be rejected from the official OctoPrint plugin repository. In my opinion, the author doesn't have a working understanding of what they're submitting, not least because this code structure is basically unmaintainable and the code unreadable.

It genuinely pains me to write this, and I'm deeply sorry that yet another opportunity for a real contribution to the OctoPrint ecosystem has been lost to AI slop.

[foosel]

I sadly have to agree here. And I hate having to continue to close requests like this. But in this day and age of stochastic parrots puking out code faster than it can be reviewed by humans, I fear this won't be the last time.