Indexed in the plugins list and the first post is now wiki’d to allow changes past 3 months.
Hi @cflin
DRC will work correctly with these footprints… all are just made as pads, using poly-lines or curves inside a primitive geometry. Those geometries are fully supported in Kv5.
My Miter script has been developed from an original script I found at KiCAD mailing list… unfortunately the message didn’t get many attention and the contribution didn’t get inside kicad code… and after a while I finally decided to revamp the code to align it to kv5.1
My latest commits have been merged by @jsreynaud and his Via Stitching plugin is now updated to work with KiCAD v5.14 latest stable and v5.1 nightly.
I’m working also on other RF tools and I will post some news later on.
M
That’s… AWESOME!!
Now I cannot wait to see these options directly in the track routing.
(Actually I have been waiting for a long time)
The same was for me … at last since I saw Ben Kempke track rounder
Anyway, because legacy canvas has been dropped and Ben code will never go into KiCAD main branch, I developed an action plugin to hack KiCAD
Just available here:
RF-tools-KiCAD
That soldermask expander can also be useful for power traces that want to be exposed to pick up extra solder to increase the current rating. Nice work, @maui.
These are great features, thanks!
Still not fully fledged as the ADS layout tools, but in the right direction.
I wonder if the name is “taper” instead of “tamper”, as the lines used for matching are usually addressed as “tapered lines”.
Thank you for appreciating
That was a typo … (I’m not a native speaker of English)
It should be fixed now at the repo
Thx
I have a lot of questions and comments relevant to this thread.
Looking @Anool’s posting above, I see that the 5.1.4 build for Ubuntu 18.04 has Python3 enabled. Mine, for Ubuntu 16.04, doesn’t (or so “About” claims). Why? Does it mean I need to take the risk of upgrading to Ubuntu 18.04?
I want to point out an ingenious subtlety in @maui’s RF tools: In the schematic, they are used as flags between connected nodes. This circumvents the problem of having a two-port copper “component,” which would require a different net on each port, causing the DRC to flag an error of shorted nets. However, the issue of grounding traces which are “hot” on the other side (which are a significant fraction of the wavelength) persists in RF design. As I mentioned in this forum before, since the DRC only thinks in DC, it cannot accommodate RF design. Take the printed F antenna as an example (look for “PIFA” in wikipedia): The bottom of the F is electrically “hot,” while the end of each arm is grounded. Perfectly understandable in terms of RF, since each dimension is a significant part of a wavelength, but the DRC’s “DC-only” thinking would flag a nonexistent error (shorting to ground). Probably a zero-length component would do, but how would it be visible in the layout? This problem is not unique to KiCAD.
I installed the KiCad action scripts, but only the ViaStitching plugin shows up. Here is my ‘~/.kicad_plugins’ directory structure:
And here is the directory structure of ‘~/.kicad_plugins/kicad-action-scripts’:
‘ViaStitching’ and ‘CircularZone’ are links to the original subdirectories under ‘./kicad-action-scripts’. All installed plugins except CircularZone show up.
Concerning via stitching, I think it fails to function when I tell it to place vias only within a zone (selecting the last option on the bottom only). Otherwise, it seems to work. In general, if I had a coplanar waveguide (see, for example, https://en.wikipedia.org/wiki/Coplanar_waveguide) and I wanted a “via fence” to ground extending only a certain distance from the hot trace, is there any easy way to do that? It would be something like using the trace to define a path in Inkscape.
Finally, here is the information about my KiCAD 5.1.4:
Application: KiCad
Version: 5.1.4-e60b266~84~ubuntu16.04.1, release build
Libraries:
wxWidgets 3.0.2
libcurl/7.47.0 OpenSSL/1.0.2g zlib/1.2.8 libidn/1.32 librtmp/2.3
Platform: Linux 4.15.0-65-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
Boost: 1.58.0
OpenCASCADE Community Edition: 6.8.0
Curl: 7.47.0
Compiler: GCC 5.4.0 with C++ ABI 1009
Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=OFF
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON
The latest Debian has both.
hermit@~:locate bin/python
/usr/bin/python
/usr/bin/python2
/usr/bin/python3
hermit@~:ls -la /usr/bin/python
lrwxrwxrwx 1 root root 7 Mar 4 2019 /usr/bin/python -> python2
It defaults to python2 though. I’d say check to see if you have both on your system. If so, then you may be able to work from there.
Just noticed you have python3 scripting = off.
@hermit: I do have python3 installed on my system. ‘ls -la /usr/bin/python’ shows me ‘/usr/bin/python -> python2.7’. Yes, I have ‘KICAD_SCRIPTING_PYTHON3=OFF’. I had 5.1.4 installed from the repo (js-reynaud-ubuntu-kicad-5_1-xenial.list); I did not compile it from source. That’ how it came from the repo. Is there a way to change ‘KICAD_SCRIPTING_PYTHON3’ without compiling from source (and selecting it as a config variable before ‘make’ is run?)?
@maui: Wow! I just did a git pull and the track caliper works! One comment: It seems to me that the track caliper and the via stitcher only work in mm and don’t care if I change the units to inches.
Thanks for your great work!
@skuep started to develop on 2017 this action via fence plugin
I have updated the plugin adding some features and let it work with kicad 5.1.4 and did a PR, but ATM it is not merged.
You can test my version downloading my forked repo here:
Via Fence plugin
It should work fine if you select a Zone and after run the tool checking the related box.
@maui: Wow, the via fence plugin works beautifully!
As for the via stitching of a zone, I had to do the following to a zone on an inner layer, declared to be GND:
-
Insert a couple of vias manually, and declare each of them to be part of the same net (GND); that enabled showing the whole zone filled and with the fillets at the corners.
-
Delete the manually-placed vias, still keeping the filled display of the zone.
-
Activate the via stitching tool, set the parameters, and then run it.
I think the crucial step was (1) above. Probably only one manually inserted via would have done it. Well, zones have always been quirky anyway. One more thing: The vias were not quite aligned (see pic). Could the grid settings have anything to do with that?
Is there any way to use a different step size along different directions?
Once more, thank you for your excellent work, which elevates the value of KiCAD!
@hermit: Thank you for the suggestions. I do have python3 installed in my system. In fact, I have Ubuntu 16.04’s version, the snap version (both system-wide, of course), the anaconda version (locally, so this should not matter)… And yes, ~/usr/bin/python is a link to python2.7. I think the lack of python3 scripting is a packaging issue and I need to contact the packager—if I only knew how. Otherwise, I need to bite the bullet and compile KiCAD from source, which I’d rather avoid at the moment.
thanks… please consider that fencing vias plugin is still in development and ATM doesn’t check any DRC and can place vias on not allowed zones/pads.
Via Stitching plugin has instead already a DRC check when placing vias and it will place vias only on the selected net and allowed zones/places.
Not ATM.
Still if there is room for improvements, I think KiCAD can now handle many critical aspects that weren’t easily obtainable before.
I have done a small video to show the tools capabilities:
This is functionaly the same as the [Pad2pad action plugin](https://github.com/MitjaNemec/Kicad_action_plugins#pad2pad-track-distance. I should have put more resources in PR activities
Moreover track length feature is also available in kicad std menu (Route:Tune track length) , but I needed a very basic way to get the length without the risk to modify the track itself.
BTW I have to thank you for other code snippets
Particularly useful the hack for wxFormBuilder (which is generating incompatible dialog code for wxPython & python version 2) that I slightly modified.
I should have included contribution in my code as the hack regarding the SetSizeHints is not mine but from Qu1ck Length stats: action plugin
please consider that fencing vias plugin is still in development and ATM doesn’t check any DRC and can place vias on not allowed zones/pads.
However, if I explicitly invoke DRC chekcing (say from the tool button), shouldn’t the errant vias be caught then?