Yeah I’ve handled the division some time ago, when there was a python3 release for windows available. And since then I am using the future package.
I’ll probably ping the person responsible if he can release 5.1 also.
Yeah I’ve handled the division some time ago, when there was a python3 release for windows available. And since then I am using the future package.
I’ll probably ping the person responsible if he can release 5.1 also.
I tried the fixes and additional issues came up. I opened a github ticket because its probably better to track the issues there. If you need someone to test the fixes, feel free to call me.
@orsonmmz used this as an example in his KiCon 2019 talk https://youtu.be/_zVJ96SdYrs?t=1398
Thanks for the notice. It’s always nice to be noticed.
Thanks, and while I have your attention there are two things I’d like to point out:
It is something to keep in mind when planing a roadmap for KiCad’s python funcitionality
I would rather simplify the plugin installation process and let the users decide which plugins they want to have.
One idea would be to imitate FreeCAD’s plugin/script manager where the user can install a new Plugin with a couple of clicks from a central repository, but still is able to install Plugins the “hard way” putting the files on the correct path. The manager could also check which plugins are compatible with the current version of KiCAD, in order to not show broken/unmanteined/old stuff.
(This discussion could be moved out of this thread)
We should first check with the developer the better way to do it:
In https://bugs.launchpad.net/kicad/+bug/1823733 I propose the creation of a https://github.com/KiCad/plugins repository to keep just the meta data and the plugin will check the installed version and the avaliable to download (the important infos will be: name, description/propose, category, icon, version, download link and we could reserve some info to say “pcbnew plugin” for allow future “eeschema plugins” https://bugs.launchpad.net/kicad/+bug/1728258).
I didn’t check kipi yet but, even if by a hard way (not using git
commands) it will be interesting deal with different branch and repositories (I usually keep ‘stable’ and ‘in-development’ at git, should be interesting give this options to the users, also because I need some users to check my in-development version).
Another open source project to borrow (steal) ideas from is the ArduinoIDE board manager. That system allows pointing to several repositories that each maintain their own repository manifests. Allowing to install plugins (for different board targets) not only from the “official” source, but also 3rd party locations (I have attiny, AdaFruit, and SparkFun linked). I’m not saying that the ArduinoIDE board manager doesn’t have it’s own problems, but there is certainly some techniques worth learning from there.
I also like this Arduino IDE feature (although other aspects of the software are rather more dubious). One especially useful aspect is that it allows you to select exactly which version you want to install very easily.
Or like Notepad++ plugin management, or like Visual studio Extension… That would be nice for many kind of plug-in can be directly download. IFF the distribution server(s) is/are simple, fee/low of maintain (may be like the way pip server are – so far I think/assume it was low maintenance)
I have three problems with the Replicate_Layout plugin as follows:
Zones do not appear to be replicated reliably. Some replicate, some don’t, and minor changes to the anchor layout (the “master” that gets replicated) such as shifting a footprint or "D"ing a trace can cause a zone no longer be replicated, even if the change is no-where near the zone in question.
For those zones that are replicated, the replicated zones are not associated with any nets. They must be assigned manually.
When I run Debug on the whole layout after replication, I get some errors on the replicants (the results of replication) that do not appear on the “master”. Further, when I examine both replicants and “master”, I find that:
a. some courtyards overlap in the replicants that are not overlapping in the “master”, and
b. some traces have moved relative to some pads, resulting in “trace too close to pad” errors for the replicants but not for the “master”.
This is a problem because it the “master” consistently passes the DRC but the replicants don’t. So it becomes a slow, time-consuming trial-and-error process. I could solve the problem quickly by increasing the spacing the components, but my board cannot get bigger.
Does anyone have solutions to these problems?
Best regards,
Peter
Hi!
I’d really appreciate it if you open an issue on GitHub for each of this issues. This way even if I don’t have the time to fix the issues now they will not be forgotten. And when you do report the issues, please attach a replicate_layout.log
file which should be in the project folder
As for the issues:
replicate_layout.log
file with additional info regarding which zone has this issueRegarding 3 One way would be to position anchor footprints really far apart, then run the plugin and then you can select the replicated sheet and move it manually in place.
Just added GUI progress dialog. It is not perfect, but it is a start.
MUCH appreciated, MitjaN. Your plugins are invaluable and excellent.
I will have I test.
I hadn’t tested the highlight yet. It’s very useful. Is it possible allow the Pcbnew to get zoom out/in when the “Replicate layout” windows are in focus?
Other point: I am using the last Nightly (5.99) on Ubuntu 16.04, after I use the replicate plugin KiCad get frozen but the replication worked just fine (despise the need to restart KiCad). I don’t known if is a plugin or Pcbnew issue.
I am reporting on GitHub
I’ve moved this to the plugins section and made it a WIKI so you can update the first post and it doesn’t get locked after 3 months.
Just want to say thanks!
Iterating placements of an audio mixer, would have been major paaaain without this plugin:
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.