KiKit icon indicating copy to clipboard operation
KiKit copied to clipboard

Feature Request: Mousebites on the frame

Open g-v-egidy opened this issue 1 year ago • 4 comments

Prerequisites

  • [X] I have read the documentation and the proposed feature is not implemented.

Description

For depanelization I prefer the manual DP-25-N tool pictured below. It is available for example from Hakko or Piergiacomi. tool1 tool2

For the tool to work properly, you need mousebites on both sides of the pcb as the tool needs to break off the tab on both sides and push it downwards.

Currently when Kikit creates a panel with tabs and outer frame, there are mousebites between two single pcbs, but no mousebites between the pcb and the outer frame: mousebites-current-kikit

For the example pcb shown above I manually copied the mousebites over like this: mousebites-manually-made

It would be nice if KiKit could automatically do this for me with an option.

g-v-egidy avatar Aug 19 '24 14:08 g-v-egidy

I think that mouse bites are generated at one side is because of manufacturing limitations. If you look at a guide for JLCPCB they will not manufacture this kind of PCB.

dronecz avatar Aug 20 '24 13:08 dronecz

Thank you for looking into this issue.

JLCPCB has produced several different panels with mouse bites on both sides for me without complaining or asking me about this.

When reading the guide you linked, I read "Mouse bites are not needed on the process edge side". I don't read from this that there is a manufacturing limitation or that they won't manufacture it that way. I read from this that they don't think these double row mousebites are necessary. This is probably because they prefer some other depaneling method/tool.

So I think creating the double row mousebites should not become the default. But I would still prefer if it would be an option you can select if you use one of the depaneling tools I showed.

g-v-egidy avatar Aug 20 '24 13:08 g-v-egidy

We should definitely support this. However, the implementation won't be straightforward because of how we treat tabs - a tab is a piece of substrate that starts on a partition line and spans towards PCB edge. The PCB edge forms a cutline. Board-to-board tabs is actually a combination of two tabs spanning from the same point to different directions. However, frame tab is only a single tab. Details: https://yaqwsx.github.io/KiKit/latest/panelization/tabs.

We need to distinguish tabs between boards and tabs between a board and a frame. I see a couple of possibilities on how to approach this, however, it will require further analysis.

yaqwsx avatar Sep 17 '24 05:09 yaqwsx

We should definitely support this. However, the implementation won't be straightforward because of how we treat tabs - a tab is a piece of substrate that starts on a partition line and spans towards PCB edge. The PCB edge forms a cutline. Board-to-board tabs is actually a combination of two tabs spanning from the same point to different directions. However, frame tab is only a single tab. Details: https://yaqwsx.github.io/KiKit/latest/panelization/tabs.

We need to distinguish tabs between boards and tabs between a board and a frame. I see a couple of possibilities on how to approach this, however, it will require further analysis.

Working in manufacturing there is always a need for double mouse-bites so maybe an option to set a second row on a specified distance especially when using annotations to add the bites, de-panel tool will always need like 1.8 - 3 mm tab to pull out.

AustrisHM avatar Apr 15 '25 07:04 AustrisHM