Taper tool error occurred in kicad 9.0

[chen70854022]

Taper tool error occurred in kicad 9.0

[Farmbot26]

I haven't been able to use this feature of the plugin at all since 9.0 dropped.

[zodoczi]

I wonder guys if anyone tried the Kicad "built in" teardrop option? That makes not such a nice connection but a bit similar

[brendanm250]

Same issue, I either get the same message as above or Kicad just quits with no message.

[kodizhuk]

me too, the same issue

[pr0mixe]

Same error here on Win11, KiCad 9.0.1.

1. An unhandled exception occured. Press "Abort" to terminate the program, "Retry" to exit the program normally and "Ignore" to try to continue. (Retry just closes the app, no warnings)
2. Hitting "Abort" produces KiCad Error: Unhandled exception class: class std::bad_optional_access what: Bad optional access. Then the app quits.

Please fix.

[MarwanOSayed]

I've fixed the taper wizard for V9. You can check it out in my fork or the pull requests.

[Cocoader]

I've fixed the taper tool for V9. You can check it out in my fork or the pull requests.

I tried your pull request and the issue persists at least on macOS.

[MarwanOSayed]

I've fixed the taper tool for V9. You can check it out in my fork or the pull requests.

I tried your pull request and the issue persists at least on macOS.

I meant the taper wizard. Will edit my answer to correct it.
I will see what could be the problem with the taper tool.
In the meantime, as a workaround, you can use the wizard in the footprint editor to manually generate the taper you want and then use it in the PCB.

[Cocoader]

I've fixed the taper tool for V9. You can check it out in my fork or the pull requests.

I tried your pull request and the issue persists at least on macOS.

I meant the taper wizard. Will edit my answer to correct it. I will see what could be the problem with the taper tool. In the meantime, as a workaround, you can use the wizard in the footprint editor to manually generate the taper you want and then use it in the PCB.

No worries about the name — we all know what’s meant.
Thanks for checking what might still be causing it on macOS. 👍 I'm more than happy to test any potential fix.
Unfortunately, the workaround isn’t an option for me since I use the tool in a similar way to what’s shown in the .gif in the README. https://raw.githubusercontent.com/easyw/RF-tools-KiCAD/refs/heads/master/resources/pcbnew-taper-plugin.gif

[MarwanOSayed]

Ok I've just uploaded a quick fix on a new branch in my fork here:
https://github.com/MarwanOSayed/RF-tools-KiCAD/tree/TaperTool-Dev

IMPORTANT: For now the taper's clearance value has to be set manually after taper zone creation. Otherwise, it will remain at zero.

I'll create a pull request if I come up with a more elegant fix that doesn't require manual clearance setup.

[Cocoader]

Ok I've just uploaded a quick fix on a new branch in my fork here: https://github.com/MarwanOSayed/RF-tools-KiCAD/tree/TaperTool-Dev

IMPORTANT: For now the taper's clearance value has to be set manually after taper zone creation. Otherwise, it will remain at zero.

I'll create a pull request if I come up with a more elegant fix that doesn't require manual clearance setup.

Your quick fix works perfectly — no more crashes on macOS and works as intended. 👍
MarwanOSayed@54444c4#diff-a6a11504dc76d81b74ea756b836d07bf0a7b5d0c4dd43b906596c3ef4a1866d5R54

I don't see any apparent issues with setting the clearance to 0. As far as I understand it the clearance defined in the net classes will be favoured in this case and override it anyway. Let's say you have a situation with different net classes and clearances around that area:

I would rather have this predictable somewhat ugly behaviour where the net classes are applied properly than having one global clearance that might lead to an unnoticed DRC error or to unnecessary large clearances. This can easily be fixed before getting the board that might have manufacturing defects.

Just out of curiosity (my python skills are pretty limited) are the changes in rf_tools_wizards/uwTaper_wizard.py, which you did in your pull request 5bb2f1e, still the cause of the problem, or was the real issue only the z.SetLocalClearance(0) in taper_fz/taper.py?

Thanks a lot — I really appreciate your contribution.

[MarwanOSayed]

Ok I've just uploaded a quick fix on a new branch in my fork here: https://github.com/MarwanOSayed/RF-tools-KiCAD/tree/TaperTool-Dev
IMPORTANT: For now the taper's clearance value has to be set manually after taper zone creation. Otherwise, it will remain at zero.
I'll create a pull request if I come up with a more elegant fix that doesn't require manual clearance setup.

Your quick fix works perfectly — no more crashes on macOS and works as intended. 👍 MarwanOSayed@54444c4#diff-a6a11504dc76d81b74ea756b836d07bf0a7b5d0c4dd43b906596c3ef4a1866d5R54

I don't see any apparent issues with setting the clearance to 0. As far as I understand it the clearance defined in the net classes will be favoured in this case and override it anyway. Let's say you have a situation with different net classes and clearances around that area:

I would rather have this predictable somewhat ugly behaviour where the net classes are applied properly than having one global clearance that might lead to an unnoticed DRC error or to unnecessary large clearances. This can easily be fixed before getting the board that might have manufacturing defects.

Just out of curiosity (my python skills are pretty limited) are the changes in rf_tools_wizards/uwTaper_wizard.py, which you did in your pull request 5bb2f1e, still the cause of the problem, or was the real issue only the z.SetLocalClearance(0) in taper_fz/taper.py?

Thanks a lot — I really appreciate your contribution.

The real issue is that there was no standard API but rather the C++ source code of KiCAD is wrapped and interfaced to python through a wrapper called SWIG. This means that each time the KiCAD's C++ source code changes, the python function calls in the plugin have to be amended as well to reflect this change. The changes can be anything between changes in functions' signatures (the parameters it accepts as input), functions' returns and their types, or that functions have been removed altogether and some things have to be achieved in a totally new way. Hence, for each incompatibility issue, the code has to be traced to pin down which function call/s is/are causing the problem. The specific function call in taper_fz/taper.py that caused the problem is not the same as the ones in rf_tools_wizards/uwTaper_wizard.py.

[Cocoader]

The real issue is that there was no standard API but rather the C++ source code of KiCAD is wrapped and interfaced to python through a wrapper called SWIG. This means that each time the KiCAD's C++ source code changes, the python function calls in the plugin have to be amended as well to reflect this change. The changes can be anything between changes in functions' signatures (the parameters it accepts as input), functions' returns and their types, or that functions have been removed altogether and some things have to be achieved in a totally new way. Hence, for each incompatibility issue, the code has to be traced to pin down which function call/s is/are causing the problem. The specific function call in taper_fz/taper.py that caused the problem is not the same as the ones in rf_tools_wizards/uwTaper_wizard.py.

Thank you for the detailed answer.

[StayWavy1]

I took in @MarwanOSayed latest update but get a division by zero error. I even tried messing with track widths, placement, units, etc and had no luck either. Happens for call to SetTaper_Zone and ends at the weaken calculation below.

taper_fz/taper.py, line 151 in __ ComputeCurvedTracks
weaken = (vpercent/100.0 ........

ZeroDivisionError: float division by zero