Hallo, in KiCad vermisse ich immer wieder Funktionen, die es in anderen (kommerziellen) Programmen für Leiterplattendesign gibt. Oftmals sind das nur Kleinigkeiten, die man mehr oder weniger einfach selber programmieren kann (z.B. als Python-Skript), da KiCad ein Textformat für Projekte und Bibliotheken verwendet. Es ist aber nicht besonders Sinnvoll, wenn die KiCad-Anwender solche Tools immer selber machen müssen, da es ja häufig die gleichen Aufgaben sind, die sich immer wiederholen. Und wenn sich dann in KiCad das Dateiformat ändert, muss jeder seine Skrite neu schreiben... Gibt es vielleicht eine "offizielle" Seite, in der Anwender solche Skripte veröffentlichen können, so dass man sich die Arbeit irgendwie teilen kann oder dass die KiCad-Entwickler einige dieser Tools sogar in die Release integrieren können? Ich hab mir z.B. mal ein Python-Programm gemacht, um Bauteile in einer .brd-Datei nach der Position neu zu nummerieren und diese Änderungen auch in den Schaltplan zu übernehmen. Seit der Änderung auf da neue Format (.kicad_pcb) funktioniert das natürlich nicht mehr, was mich etwas ärgert. Bevor ich das jetzt neu mache, wollte ich mal fragen, ob jemand aus dem Forum auch so ein Tool hat und ob evtl. Interesse besteht, ein gemeinsames Projekt daraus zu machen. Es gibt außerdem viele andere Sachen, wo Tools nützlich wären, die über die Funktionalität von KiCad selber hinausgehen, z.B. zur Erstellung von Stücklisten. Kennt da jemand Tools, die es schon gibt?
Hallo Johannes. Johannes E. schrieb: > Es ist aber nicht besonders Sinnvoll, wenn die KiCad-Anwender solche > Tools immer selber machen müssen, da es ja häufig die gleichen Aufgaben > sind, die sich immer wiederholen. Es ist in PCBnew ein System in Arbeit, das vergleichbar zu den ULPs in Eagle funktioniert, aber mit Python2. Informationen zu dieser Schnittstelle gibt es hier: http://www.kicad-pcb.org/display/KICAD/KiCad+Scripting+Reference+Manual Wenn das ganze etabliert ist, wird vermutlich im KiCad file tree ein passender Zweig reserviert werden, vergleichbar mit den anderen Bibliotheken auch, inklusive einer "commiters" Abteilung. > Und wenn sich dann in KiCad das Dateiformat ändert, muss jeder seine > Skrite neu schreiben... Ja. Aber er hat etwas Zeit. Weil sich, solange es noch sinnvoll ist, Boards noch im alten .brd format gespeichert und eingelesen werden können. Darüber ergibt sich vorläufig noch ein Workaround zu dieser Problematik. Ausserdem bleibt der Algorithmus selber vermutlich im wesentlichen erhalten, auch wenn die Notation anders ist. > Gibt es vielleicht eine "offizielle" Seite, in der Anwender solche > Skripte veröffentlichen können, so dass man sich die Arbeit irgendwie > teilen kann oder dass die KiCad-Entwickler einige dieser Tools sogar in > die Release integrieren können? Ich würde das File Repository in der KiCad User Group empfehlen: http://groups.yahoo.com/neo/groups/kicad-users/info (unter "More", dann "Files") Dort existiert ein Ordner "Python Scripts for KiCad" der wiederum zwei Unterordner enthält: "KiCad Interface" und "Stand alone". Das ist der richtige Platz dafür. Ich habe mein (Python3) Skript unter "stand alone" einsortiert. Alternativ halt auf der Mikrocontroller.net KiCad-Seite: http://www.mikrocontroller.net/articles/KiCAD Ich habe mein Skript als Link einfach in den Text einsortiert, aber natürlich ist es bei mehr Skripten sinnvoll, einen eigenen Unterpunkt mit einer weiteren Unterteilung: "KiCad Interface" und "Stand alone" zu machen. Wie zukünftig mit solchen Skripten verfahren werden soll weiss ich nicht. Entweder sie werden bei der Programmentwicklung subsummiert, oder bei den Libarys (wo eh schon ein "Committer" Zeig existiert). Dann wird auch bei Launchpad ein ordner dafür existieren. > Ich hab mir z.B. mal ein Python-Programm gemacht, um Bauteile in einer > .brd-Datei nach der Position neu zu nummerieren und diese Änderungen > auch in den Schaltplan zu übernehmen. Seit der Änderung auf da neue > Format (.kicad_pcb) funktioniert das natürlich nicht mehr, was mich > etwas ärgert. Vorläufig gibt es noch den Workaround, und zum anderen sind solche Skripte eine gute Vorarbeit für aktuelle. Darum würde ich sie auf keinen Fall einfach wegwerfen, sondern ebenfalls an den vorgeschlagenen Stellen archivieren. Zu einem solchen Skript gehört ja auch immer eine Erläuterung (mein ich, selbsterklärend find ich nix). Das alles zusammenzippen, mit einem sprechenden Dateinamen, der den Zusatz "Obsolete" und eventuell das Datum enthält, versehen, und halt dort archivieren.. > > Bevor ich das jetzt neu mache, wollte ich mal fragen, ob jemand aus dem > Forum auch so ein Tool hat und ob evtl. Interesse besteht, ein > gemeinsames Projekt daraus zu machen. Ich hab was geschrieben, um im Schaltplan die Unterschaltpläne in einer anderen Reihenfolge zu sortieren. Wenn Du Dein Skript dazu packst, sind es schon zwei, und dann lohnt es sich, im KiCad-Artikel einen Unterabschnitt Pythonskripte anzulegen. ;O) > Es gibt außerdem viele andere Sachen, wo Tools nützlich wären, die über > die Funktionalität von KiCad selber hinausgehen, z.B. zur Erstellung von > Stücklisten. Kennt da jemand Tools, die es schon gibt? Es wurde mal ein Tool erstellt, um im Board die Bauteile wie im Schaltplan angeordnet vorzugruppieren....kann sogar sein, dass das schon irgendwo im Artikel integriert ist. Dann liegen hier ein paar angefangene Sachen, die so direkt mit KiCad nix zu tun haben, aber natürlich auch nützlich sein könnten, wie z.B. eine lowlevel-TXT Datenbank um Bauteile anhand des Markings und der Bauform zu identifizieren..... Ich glaube, ich werde mal zu der Thematik eine entsprechende Anfrage im KiCad user Forum stellen, weil ich schon denke, das es durchaus eine Sache ist, worüber Nachzudenken ist. Aber nicht mehr dieses Wochenende. Es ist WAG Contest. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.dl0dg.de
Nachtrag: Bernd Wiebus schrieb: > Es ist in PCBnew ein System in Arbeit, das vergleichbar zu den ULPs in > Eagle funktioniert, aber mit Python2. > Informationen zu dieser Schnittstelle gibt es hier: > http://www.kicad-pcb.org/display/KICAD/KiCad+Scripting+Reference+Manual > Ich hab noch einen Link dazu gefunden: http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/files/4401/scripting https://lists.launchpad.net/kicad-developers/msg09576.html Vieleicht hilft das weiter. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.dl0dg.de
Hallo Bernd, Bernd Wiebus schrieb: > Es ist in PCBnew ein System in Arbeit, das vergleichbar zu den ULPs in > Eagle funktioniert, aber mit Python2. Ja, das habe ich auch schon gesehen. Für mich hört sich das aber so an, dass es noch sehr lange dauern könnte, bis das einsetzbar ist. Ich suche eher nach einer Lösung, die jetzt schon verwendet werden kann. Bernd Wiebus schrieb: > Ich würde das File Repository in der KiCad User Group empfehlen: Danke für den Tipp. Da ist sogar ein Tool abgelegt (Kren), das auch Bauteile positionsabhängig umbennen kann. Lustigerweise gab es dort gestern einen Eintrag genau zum gleichen Thema, in dem sich jemand beschwert, dass Kren mit dem neuen Dateiformat nicht funktioniert. Bernd Wiebus schrieb: > Wenn Du Dein Skript dazu packst, sind > es schon zwei, und dann lohnt es sich, im KiCad-Artikel einen > Unterabschnitt Pythonskripte anzulegen. ;O) Das könnte ich schon machen. Ich habe jetzt mal angefangen, das Skript an das neue Dateiformat anzupassen. Allerdings ist mein Skript sehr einfach programmiert, ohne GUI und ohne Parameter, alle Einstellungen müssen direkt im Source-Code gemacht werden. In diesem Zustand ist es eigentlich nicht geeignet, um es zu veröffentlichen. Doku gibt es natürlich auch nicht ... Ich hatte immer gehofft, dass so eine Funktion in der "nächsten" KiCad-Release drin ist und deshalb dachte ich, dass es sich nicht lohnt, hier viel Aufwand reinzustecken. Aber vielleicht findet sich ja jemand, der Lust hat, ein komfortables User-Interface dafür zu machen... Wenn das Tool mit dem neuen Dateiformat funktionert werde ich mich nochmal melden.
Hallo Johannes. Johannes E. schrieb: > Ja, das habe ich auch schon gesehen. Für mich hört sich das aber so an, > dass es noch sehr lange dauern könnte, bis das einsetzbar ist. Ich suche > eher nach einer Lösung, die jetzt schon verwendet werden kann. Dem Vernehmen nach ist es anscheinend unter Windows ein erhebliches Problem, eine Python Schnittstelle einzubauen. Vergleichbares habe ich auch von anderen Projekten vernommen. Die Linux Version funktioniert wohl schon. Du must Dir aber eine Testing Version selber compilieren und dabei eine passende Angabe machen. > Allerdings ist mein Skript sehr einfach programmiert, ohne GUI und ohne > Parameter, alle Einstellungen müssen direkt im Source-Code gemacht > werden. Ich hoffe, Du hast wenigstens passende Kommentarzeilen hinzugefügt. Ohne solche weiss ich aus eigener Erfahrung, das es nach drei Monaten ein Problem ist, den eigenen Code zu verstehen....eine Änderung ist fast immer ein Redesign mit Reverse Engeneering. ;O) > > In diesem Zustand ist es eigentlich nicht geeignet, um es zu > veröffentlichen. Doku gibt es natürlich auch nicht ... Wenn Du strategisch geschickt wirkungsvolle Kommenrarzeilen einstreust, kann das je nach Komplexität des Programmes durchaus sinnvoll zu veröffentlichen sein. Mindestens als eine gute Grundlage für weiterentwicklungen. Wenn die Kommentarzeilen einen guten Hinweis geben, wo was zu welchem Zwecke im Source-Code einzustellen ist, ist das fast schon Luxus. ;O) Schreib aber in den Header Kommentar schon hinein, ob es für Python 2 oder 3 ist. Als ewiger Anfänger weiss ich, das solche Hinweise auch für "offensichtliches" nötig sind. Denk daran, dass ein Anfänger nicht unbedingt weiss, was ein Shebang ist.... > > Ich hatte immer gehofft, dass so eine Funktion in der "nächsten" > KiCad-Release drin ist und deshalb dachte ich, dass es sich nicht lohnt, > hier viel Aufwand reinzustecken. Der allgemeine Bedarf an solchen Funktionen ist für Leute, die nur gelegentlich eine Platine entwickeln, eher klein. Darum ja auch der Ansatz mit dem Skripting....das erhöt die Flexibilität. > > Aber vielleicht findet sich ja jemand, der Lust hat, ein komfortables > User-Interface dafür zu machen... > > Wenn das Tool mit dem neuen Dateiformat funktionert werde ich mich > nochmal melden. Wirf die Funktionalität mit dem alten Dateiformat aber nach Möglichkeit nicht weg. Es werden noch Jahre ins Land gehen, bis Du keine KiCad .brd Dateien mehr antriffst. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.dl0dg.de
Bernd Wiebus schrieb: > Die Linux Version funktioniert wohl schon. So wie ich das verstanden habe aber nur für Pcbnew und nicht für das Schaltplan-Modul. Um Bauteil-Namen im Layout und im Schaltplan zu ändern, hilft mir das auch nicht wirklich. Das neue Datenformat erscheint mir übrigens nicht sehr durchdacht: Parameter, die String-Typen sind, werden manchmal mit Anführungeszeichen geschrieben (vermutlich immer dann, wenn Leerzeichen enthalten sind), meistens aber ohne. Man sieht einem String allerdings nicht immer an, dass es ein String ist, z.B. kann eine Versions-Nummer wie eine Integer- oder Fließkomma-Zahl aussehen. Man muss also anhand des Parameter-Namens entscheiden, was für ein Datentyp es ist. Das ist sehr lästig, wenn man ein File parsen möchte, ohne alle Parameter-Namen zu kennen und in der Zeit von XML eigentlich nicht mehr zeitgemäß. Und dann gibt es auch noch boolsche Variablen mit "true" und "false", zusätzlich dann aber auch noch Variablen mit "yes" und "no". Die werden nicht als Strings interpretiert und müssen zwingend ohne Anführungszeichen geschrieben werden. Ich frage mich schon, warum man nicht gleich ein modernes Datenformat verwendet hat, wenn schon auf ein neues System umgestellt wurde.
Johannes E. schrieb: > Ich frage mich schon, warum man nicht gleich ein modernes Datenformat > verwendet hat, wenn schon auf ein neues System umgestellt wurde. Du kannst Dir gerne ein gutes Dateiformat ausdenken -- wenn es wirklich gut ist wird es womöglich auch für gEDA und andere EDA-Software übernommen. Ob XML wirklich die beste Lösung ist, ist aber etwas umstritten, das Format ist sperrig, und einige Leute möchten Dateien auch mit dem Texteditor oder Skripten bearbeiten, das ist bei XML nicht so einfach. Auf der gEDA Mailingliste war man von XML nicht wirklich angetan, eventuell besser könnte YAML sein? Für den PCB-Teil muss man überlegen, wie weit man sich am Gerber-Format orientieren will, jedenfalls muss ja alles nach Gerber abbildbar sein, und das möglichst einfach. Aber entscheidend ist natürlich der Inhalt -- Sperrflächen und 3D Modelle fehlen etwa derzeit im gEDA Format, warscheinlich noch viel mehr, was mir aber nicht einfällt. Also mir fiele so spontan keine gute Lösung ein -- womöglich kann man sich ja an kommerzeiellen Lösungen orientieren, aber da muss man wohl auch vorsichtig sein. Und dieses Specctra Format -- darf man das eigentlich frei verwenden? Also dann mach mal und gib uns bescheid wenn Du soweit bist.
Salewski, Stefan schrieb: > Ob XML wirklich die beste Lösung ist, ist aber etwas > umstritten, das Format ist sperrig, und einige Leute möchten Dateien > auch mit dem Texteditor oder Skripten bearbeiten, das ist bei XML nicht > so einfach. Meine Anmerkung dazu: - XML kann problemlos mit Texteditoren bearbeitet werden. - Für die automatische Verarbeitung von XML wurde XSLT entwickelt. XSLT ermöglicht problemlos das Transformieren einer XML Datei in eine neue XML Datei (oder etwas anderes; z.B. .txt, .csv, .pdf). KiCad verwendet XML und XSLT bereits beim Generieren von Netzlisten und BOM's im Hintergrund. Man kann wunderbar einen eigenen BOM Generator in KiCad mit Hilfe von XSLT integrieren. Man muss nur eine .XSLT Datei erstellen und den xsltproc Aufruf als Plugin bei den Netzlisten hinzufügen. Warum XML nicht für das neue Dateiformat verwendet wurde verstehe ich auch nicht. Ich muss aber gestehen, ich hab mir das alte und das neue Format noch nicht angesehen. Schönen Abend.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.