Skip to content

[Panelize][Added] Rail widener for pick-and-place sensor detection - #954

Merged
set-soft merged 1 commit into
INTI-CMNB:devfrom
Reid-n0rc:rail-widener
Sep 11, 2026
Merged

set-soft merged 1 commit into
INTI-CMNB:devfrom
Reid-n0rc:rail-widener

Conversation

@Reid-n0rc

Copy link
Copy Markdown

Closes #953

Summary

Adds a "rail widener" to the panelize output: a solid patch of extra rail/frame material at chosen outer panel corners (tl/tr/bl/br), so pick-and-place photoelectric sensors get a bigger flat target without growing the panel's outer outline or ever overlapping a board.

  • New framing.widenercorners/widenerwidth/widenerlength/widenergap options, valid for framing.type railstb/railslr/frame/tightframe.
  • Implemented as a KiKit FramingPlugin (kibot/panelize_plugins/rail_widener.py) that delegates to KiKit's own framing builder for the requested base type, then unions in the corner patch(es).
  • The patch is clipped against the board outline(s) (expanded by widenergap, defaulting to the frame's hspace/vspace) so it can never touch/overlap a board, with an extra allowance for KiKit's own reverse-tab-fillet pass so the gap that survives matches what was requested.
  • The new concave "step" corner where the patch returns to the normal rail width gets an exact tangent-arc fillet (radius = framing.fillet), computed directly from the corner/step geometry so it only affects that one point.
  • Updated PanelDemo_4x4.kibot.yaml to demonstrate widening the top corners.
  • Regenerated the PanelizeFraming docs for the new options.

Test plan

  • Ran the demo config (4x4 panel, railstb framing) through kibot and inspected the generated panel/preview: widened patches appear at the requested corners, never overlap the boards, and don't grow the panel outline.
  • Verified with widenercorners on all four corners at once, and with a widener width/length deep enough that it would otherwise overlap a board, confirming the clip.
  • Opened the generated panel in pcbnew to visually confirm the patches and the step fillet.
  • No automated regression test added yet under tests/test_plot/ — happy to add one if you can point me at the preferred board sample/pattern for panelize tests (I noticed tests/board_samples/*/light_control.kicad_pcb is used for other panelize tests).

@set-soft

set-soft commented Aug 6, 2026

Copy link
Copy Markdown
Member

Hi @Reid-n0rc !
The option looks good. Here are some details:

  1. The docs should explicitly say this option will modify the code and arg. In fact a check to see if these options were defined by the user can help to catch silly errors, just report an error when the user tries to use it and also to specify another plug-in. I wonder is its possible to create some sort of wrapper that might allow both things (explicit and implicit plug-ins)
  2. I think we should keep the panel example template without modifications, just create an example in the tests/yaml_samples/ dir. Similar to the demo, but oriented to test the feature. Why? If the KiKit API makes your plug-in obsolete it will break the basic example.
  3. For the test you can add some very silly board, might be just a rectangle, and apply the test configuration. Using light_control for this is an overkill. Just try to verify the widener. Why: KiCad changes things like zone fillers, fonts, etc. and they break the light_control reference from time to time, keeping this test as simple as possible will make reference updates less common.

@set-soft

Copy link
Copy Markdown
Member

Hi @Reid-n0rc !

Please address these items. Also: if the plug-in was created using Claude assistance please mention it.

Hi @Reid-n0rc ! The option looks good. Here are some details:

  1. The docs should explicitly say this option will modify the code and arg. In fact a check to see if these options were defined by the user can help to catch silly errors, just report an error when the user tries to use it and also to specify another plug-in. I wonder is its possible to create some sort of wrapper that might allow both things (explicit and implicit plug-ins)
  2. I think we should keep the panel example template without modifications, just create an example in the tests/yaml_samples/ dir. Similar to the demo, but oriented to test the feature. Why? If the KiKit API makes your plug-in obsolete it will break the basic example.
  3. For the test you can add some very silly board, might be just a rectangle, and apply the test configuration. Using light_control for this is an overkill. Just try to verify the widener. Why: KiCad changes things like zone fillers, fonts, etc. and they break the light_control reference from time to time, keeping this test as simple as possible will make reference updates less common.

Reid-n0rc added a commit to Reid-n0rc/KiBot that referenced this pull request Aug 10, 2026
…ression test

Addresses review feedback on the rail widener (INTI-CMNB#954):
- Docs now state widenercorners overwrites type/code/arg, and config()
  errors out if the user also sets code/arg explicitly instead of
  silently overwriting them.
- Keep PanelDemo_4x4.kibot.yaml unmodified so the base panelize example
  doesn't depend on the widener; the demo now lives in its own
  tests/yaml_samples/panelize_widener_1.kibot.yaml.
- Add test_panelize_widener_1, using the simple simple_2layer board
  instead of light_control to keep the reference cheap to maintain.
- While wiring up that test, found widenercorners/widenerwidth/
  widenerlength/widenergap were leaking into the JSON preset handed to
  the kikit CLI (which doesn't know those keys) and made the plugin
  path fail; they're now excluded once folded into arg.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@Reid-n0rc

Copy link
Copy Markdown
Author

Thanks for the review, @set-soft! Addressed in 371b69c:

  1. code/arg override: the widenercorners docs now explicitly say it overwrites type/code/arg, and PanelizeFraming.config() now raises a KiPlotConfigurationError if the user also sets code/arg explicitly instead of silently clobbering them. I kept it to that explicit check rather than building the implicit/explicit-plugin wrapper you floated — didn't want to add that abstraction speculatively without a concrete second use case driving its shape, happy to revisit if you have one in mind.
  2. Demo template: reverted PanelDemo_4x4.kibot.yaml back to unmodified; the widener example now lives in its own tests/yaml_samples/panelize_widener_1.kibot.yaml.
  3. Test board: test_panelize_widener_1 now uses simple_2layer (already used elsewhere in the suite) instead of light_control.

While wiring up that test I actually caught a real bug: widenercorners/widenerwidth/widenerlength/widenergap were leaking into the JSON preset handed to the kikit CLI, which doesn't recognize those keys and failed with 'list' object has no attribute 'split'. Fixed by excluding them from the preset once they're folded into arg. Verified locally (KiCad 10 + KiKit) that the test now runs and the panel renders as expected.

Also, yes — Claude assistance was used throughout this PR (implementation and this round of fixes), noted via Co-Authored-By in the commits.

@Reid-n0rc

Copy link
Copy Markdown
Author

@set-soft any thoughts?

@set-soft

Copy link
Copy Markdown
Member

Hi @Reid-n0rc !
Sorry for the delay.
Can you squash the commits to make them just one? And also rebase it to dev branch (not master)

Adds framing.widenercorners/widenerwidth/widenerlength/widenergap options
to add solid corner patches to the panel rail, giving pick-and-place
photoelectric sensors a bigger flat target without growing the panel's
outer outline. Implemented as a KiKit FramingPlugin (kibot/panelize_plugins/
rail_widener.py) that delegates to KiKit's own framing builder for the base
rail/frame, then adds a gap-clipped patch per requested corner plus an
exact tangent-arc fillet matching framing.fillet at the new step corner.

Fixes along the way:
- buildDummyFramingSubstrates() returned the board substrates unchanged
  instead of KiKit's own offset dummy rail boundary, so fixed/spacing
  tab building had no target to grow tabs towards and silently produced
  zero tabs (and thus zero mouse bites) whenever a *+widener framing
  type was selected.
- The frame/tightframe corner-separation cuts KiKit builds before the
  widener runs are sized to the plain rail width, so mouse bites along
  them stopped well short of the widened corner patch. Extend whichever
  cut touches each widened corner to match the patch's actual extent.
- widenercorners/widenerwidth/widenerlength/widenergap were leaking into
  the JSON preset handed to the kikit CLI (which doesn't know those
  keys) and made the plugin path fail; they're now excluded once folded
  into arg.
- Docs now state widenercorners overwrites type/code/arg, and config()
  errors out if the user also sets code/arg explicitly instead of
  silently overwriting them.
- Keep PanelDemo_4x4.kibot.yaml unmodified so the base panelize example
  doesn't depend on the widener; the demo now lives in its own
  tests/yaml_samples/panelize_widener_1.kibot.yaml.
- Add test_panelize_widener_1, using the simple simple_2layer board
  instead of light_control to keep the reference cheap to maintain.

Regenerated the framing docs RST for the new options.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019yXsDgcZLfMH7b1zWe85vr
@Reid-n0rc
Reid-n0rc changed the base branch from master to dev September 10, 2026 13:27
@Reid-n0rc

Copy link
Copy Markdown
Author

Done — squashed into a single commit and rebased/retargeted onto dev.

@set-soft

Copy link
Copy Markdown
Member

Thanks @Reid-n0rc
The patch needs to solve a couple of details, but I'm merging it and solving the issues

@set-soft
set-soft merged commit c8d5286 into INTI-CMNB:dev Sep 11, 2026
14 of 20 checks passed
@Reid-n0rc

Copy link
Copy Markdown
Author

Thank you @set-soft

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[FEATURE] Rail widener: give pick-and-place sensors a bigger flat rail target at chosen corners

2 participants