KiCad: Mehrere Schaltplanseiten/Hierarchische Schaltpläne

Hallo MarkusB.

> Ist es eigentlich auch möglich, vorgefertigte Schaltpläne zu
> importieren?

Ja. Mit gewissen Einschränkungen, weil es "eigentlich" nicht vorgesehen 
ist. Ich hatte mal geplant, einen Artikel dazu zu schreiben, was aber 
aus Zeitgründen bisher nicht geklappt hat. Darum jetzt hier nur auf die 
Schnelle. Alles dazu weiss ich auch nicht, aber ich habe damit 
erfolgreich experimentiert, und es kann wirklich eine Menge Arbeit 
sparen.

Folgende Vorgehensweise: Du zeichnest Deinen Subschaltplan, den Du als 
"Building Block" einführen möchtest. ALLE Anschlüsse an den Rest der 
Schaltung werden als Hierarchische Label ausgeführt. Am besten achtest 
Du auch noch auf die Cache library. Die wird spätestens angelegt, wenn 
Du alles speicherst und den Schaltplan schliesst.
Wieder öffnen und unter Einstellungen alle Symbolbibliotheken austragen, 
aber die Cache library eintragen. Suchpfad auf relativ.
Alles in der Projektdatei speichern.


Es ist aus verschiedenen Gründen sinnvoll, den "Buildingblock", also die 
Gruppe aus Schematik ".sch", die cache library ".lib" und die 
Projektdatei ".pro" in das Arbeitsverzeichnis zu kopieren, eventuell 
mehrmals, mit geändertem Namen. Dazu später mehr. Es wird auch immer ein 
.brd angelegt, das aber leer ist. Keine Ahnung, wie damit umzugehen ist. 
Ich belasse die .brd Datei im Verzeichnis, wo ich den Buildingblock 
erstelle, weil KiCAD sonst rummeckert, kopiere sie aber nicht mit um.


Nun legst Du in Deinem Hauptschaltplan ein hierarschisches Blatt an, mit 
Verweis auf den hineinkopierten Subschaltplan. Wie steht im Manual. 
Wenn
Du nun im Hauptschaltplan mit der rechten Maustaste in das Rechteckes 
des Subschaltplan klickst, bekommst du eine Möglichkeit, Pins zu 
importieren. Wenn Du diese Möglichkeit wählst, erscheinen Dir sukzessive 
alle hierarschischen Pins des Subschaltplanes, die Du nun am Rand des 
Subschaltplanes verschieben, plazieren und die Du auf gewohntem Wege mit 
dem Rest der Schaltung verbinden kannst.

Wenn Du zwei Subschaltpläne anlegst, die auf den gleichen "Building 
Block" verweisen, ist das erstmal kein Problem. Die Annotation ist in 
der Lage, diese beiden (oder auch drei, vier....N?) solcher Schaltpläne 
auseinanderzuhalten. Du bekommst diese tatsächlich mehrfach in der 
Netzliste angezeigt, und kannst denen dort in CVpcb auch 
unterschiedliche Module/Footprints zuweisen. Inwieweit das Sinnvoll ist, 
dazu später mehr.

Allerdings: Wenn Du auch nur eine Kleinigkeit an dem einen Subschaltplan 
änderst, hast Du die Änderung in allen anderen auch. Wie anders auch, 
verweisen doch beide (alle) auf das gleiche "Building Block" Schematic.

Wenn Du das nicht möchtest, musst Du den Buildingblock halt noch einmal 
unter anderem Namen, und zur Vorsicht auch noch die Cache library und 
die Projektdatei mit anderem Namen in Dein Arbeitsverzeichnis kopieren, 
und Dich halt bei dem abweichenden Subschaltplan auf diesen neuen 
Buildingblock beziehen. Der ist dann bei änderungen unabhängig von den 
anderen.

Wie ich schon oben geschrieben habe, kannst Du bei "wiederholten" 
Bauteilen aus mehreren Subschaltplänen, die auf den gleichen 
"Buildingblock" verweisen, durchaus unterschiedliche Footprints 
zuweisen, weil die Annotation/Netzliste eben Unterscheiden kann. 
Allerdings ist es sinnvoll, das irgendwo im "Value" des Bauteiles zu 
hinterlegen, weil es nur so in die BOM eingeht. Leider gilt für den 
"Value" aber, das eine Änderung sich auf alle Subschaltpläne 
auswirkt......Du kannst also zwar unterschiedliche Footprints zuweisen, 
der eingetragene "Value" ist aber immer gleich, und taucht immer gleich 
in der BOM auf. Das wäre manchmal egal, meist aber nicht, wenn Du z.B. 
einmal einen Thruhole, und einmal SMD ansetzt, oder auch nur 
unterschiedliche Werte für einen Wiederstand mit ansonstem gleichem 
Footprint.

Aus Gründen der Konsistenz ist es dann nach meiner Ansicht schon 
sinnvoll, besser mit einer umbenannten Kopie des Buildingblockes zu 
arbeiten, sobald unterschiedliche unterschiedliche Werte oder Footprints 
verwenedet werden.

Wie gesagt, diese Funktion ist vermutlich nicht beabsichtigt gewesen, 
funktioniert aber......



> Für VCC und GND sollte man dann globale
> Lables verwenden, oder?

Eher nicht, Du kommst in Teufels Küche, wenn Du im Buildingblock z.B. 
ein globales GND anlegst, tatsächlich aber intern mal mit 
unterschiedlichen Massen arbeiten möchtest. Dein Buildingblock nagelt 
dann alles per globales GND zusammen, und es ist für Dich erstmal nicht 
offensichtlich, woher das kommt.... Aber so richtig ausgeforscht habe 
ich das noch nicht.
Berichte also über Deine Erfahrungen.


> Das ganze habe ich als powersupp.sch abgespeichert. Anschließend habe
> ich einen zweiten Schaltplan erstellt und mit "hierarchischen Schaltplan
> hinzufügen" eine Box gezogen. In die Box mit den Schaltplan
> Eigenschaften gibt man als Dateinamen gibt man powersupp.sch ein. Der
> Schaltplan muss sich im gleichen Verzeichnis befinden.

Na siesse, geht doch. Auch ohne meine Hilfe.

@noName:
> Ich befürchte, auf diese Weise geht dir aber die "Netzliste" verloren.
> Das bedeutet, du musst jedes mal deinen Schaltzeichen neue Footprints im
> CVPCB zuweisen.

Die Netzliste kriegt das eher hin. Das Problem ist der "Value" und die 
BOM.
Allerdings, Du musst natürlich, wenn der gleiche Widerstand im 
buildingblock halt mehrmals als z.B. R30 und als R50 wiederholt, weil 
zwei  Subschaltpläne, die sich auf diesen Buildingblock beziehen, beiden 
einen Footprint zuweisen. Und da liegt ja auch der hase im Pfeffer: Du 
kannst zwei unterschiedliche Footprints zuweisen, mit dem Board gibt das 
kein Problem, aber eben halt mit dem "Value" und der BOM (Bill Of 
Materials/ Bauteilliste), weil diese sich immer auf den Buildingblock 
bezieht, und da halt nur ein Wert stehen kann.

Wenn Du sagst, es langt mir, wenn da z.B. 10k steht, obwohl das eine ein 
1/3 Watt through Hole, und der andere ein 0805 ist, ist das kein 
Problem.
Wenn Du aber zum Beispiel zweimal den gleichen Transistor verbaust, und 
der eine Footprint steht, und der andere liegt, und Du willst das in der 
BOM sehen, weil Du in der Arbeitsvorbereitung die Hälfte der 
Transistoren durch eine Biegevorrichtung schicken musst, dann musst Du 
dafür dummerweise einen zweiten Buildingblock per kopieren und 
umbenennnen erzeugen.

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic

http://www.dl0dg.de

> Wenn Du zwei Subschaltpläne anlegst, die auf den gleichen "Building
> Block" verweisen, ist das erstmal kein Problem.

Ich bin neu in KiCad, hab früher immer mit Orcad gearbeitet, aber das 
kann ich mir nicht leisten als Hobbyanwender.

Meine Aufgabe war, für einen bereits existierenden Print den Schaltplan 
nachträglich zu zeichnen (sozusagen "reverse engineering").

Damit scheidet die Mehrfachverwendung eines einzigen Subsheets aus, die 
Namen der Bauteile können nämlich nicht über die automatische Annotation 
erzeugt werden - weil sie schon fest vorgegeben sein müssen! Manuelles 
Festlegen geht (erstmal) auch nicht, weil das Editieren sich auf alle 
Instanzen des (mehrfachverwendeten) Subsheets auswirkt.

Bleibt also nur das manuelle Umkopieren des Subsheets unter anderen 
Namen, hier "Building Blocks" genannt. Damit handelt man sich natürlich 
immer den Nachteil ein, bei einer nachträglichen Änderung im Subsheet 
alle daraus kopierten Building Blocks nachziehen zu müssen. Abgesehen 
von dem hier diskutierten Problem "gleiches Value bei unterschiedlichem 
Footprint".

Ideal wäre wenn KiCad "richtige" Templates verwalten könnte, auf denen 
dann die Subsheets basierten. Bauteilereferenzen oder Werte könnten dann 
per Annotation automatisch oder manuell vergeben werden. Das Editieren 
von Subsheets würde sich nicht auf ein Template auswirken, nur 
umgekehrt.

Das scheint mir irgendwie nicht optimal gelöst in KiCad. Sehe ich hier 
was falsch oder gibt es eine Möglichkeit das in KiCad doch noch 
anständig hinzubekommen?

Hallo Peter Lustig.

> Ich bin neu in KiCad, hab früher immer mit Orcad gearbeitet, aber das
> kann ich mir nicht leisten als Hobbyanwender.

Ich habe Anno 2000 zuletzt mit einem alten DOS Orcad gearbeitet. ;O)
Ein faszinierendes Programm.....die Steuerung mit den Shortcuts fand ich 
genial....allerdings musste ich mich nach jedem Urlaub neu einarbeiten. 
:-(

>
> Meine Aufgabe war, für einen bereits existierenden Print den Schaltplan
> nachträglich zu zeichnen (sozusagen "reverse engineering").

Ok, dafür sind aber auch die wenigsten Programme "maßgeschneidert".

>
> Damit scheidet die Mehrfachverwendung eines einzigen Subsheets aus, die
> Namen der Bauteile können nämlich nicht über die automatische Annotation
> erzeugt werden - weil sie schon fest vorgegeben sein müssen! Manuelles
> Festlegen geht (erstmal) auch nicht, weil das Editieren sich auf alle
> Instanzen des (mehrfachverwendeten) Subsheets auswirkt.

Richtig. Ich hab mit Kicad auch schon Reverse engeneering gemacht, und 
bin auch darauf gestossen. Genaugenommen war es für mich sogar der 
Anlass, mich damit auseinanderzusetzten, wie man aus Subschaltplänen 
"building blocks" macht. ;O)

Allerdings war in meinem Fall keine Bauteilreferenzen auf der 
Platine....d.h. ich war mit den Bauteilreferenzen frei, weil ich sie eh 
neu vergeben musste....

>
> Bleibt also nur das manuelle Umkopieren des Subsheets unter anderen
> Namen, hier "Building Blocks" genannt. Damit handelt man sich natürlich
> immer den Nachteil ein, bei einer nachträglichen Änderung im Subsheet
> alle daraus kopierten Building Blocks nachziehen zu müssen. Abgesehen
> von dem hier diskutierten Problem "gleiches Value bei unterschiedlichem
> Footprint".

Richtig.
>
> Ideal wäre wenn KiCad "richtige" Templates verwalten könnte, auf denen
> dann die Subsheets basierten. Bauteilereferenzen oder Werte könnten dann
> per Annotation automatisch oder manuell vergeben werden. Das Editieren
> von Subsheets würde sich nicht auf ein Template auswirken, nur
> umgekehrt.


Ich habe schon darüber nachgedacht, mir für den Zweck ein Python 
Programm zu schreiben, was zumindest die Umkopiererei automatisiert und 
die manuelle Referenzenvergabe unterstützt und erleichtert.
Das ist in Kicad relativ einfach machbar, weil die *.sch Dateien (und 
die anderen auch) fast klarschriftmäßig zu lesen sind.

Allerdings arbeite ich mich gerade erst in Python ein, darum ist das 
also alles ziemliche Zukunftsmusik.

>
> Das scheint mir irgendwie nicht optimal gelöst in KiCad. Sehe ich hier
> was falsch oder gibt es eine Möglichkeit das in KiCad doch noch
> anständig hinzubekommen?

Das siehst Du schon richtig, anders mache ich das auch nicht. Sehen wir 
mal, was die Zukunft bringt....bei kicad ist immer noch viel im Fluss.

Der Schritt von den Subsheets zu Templates ist ja nicht mehr so 
furchtbar groß. Zumindest ist er wesentlich kleiner als bei Programmen, 
die überhaupt keine Subsheets kennen.

Jedenfalls wärst Du mit Deiner Problemstellung auch nur bei 
kommerziellen Programmen der höheren Preisklasse gut aufgehoben.
Eagle z.B. ist in dem speziellen Punkte sogar deutlich unhandlicher als 
kicad finde ich.

Kennst Du http://tech.groups.yahoo.com/group/kicad-users/ ? Das wäre der 
richtige Platz um Deine Anregungen kundzutun.


Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.dl0dg.de

Hallo Bernd,

vielen Dank für deine Antworten! Das gute alte Orcad für DOS habe ich 
auch noch irgendwo auf Disketten...bloß wo ist das Diskettenlaufwerk 
hin...und läuft das eigentlich noch auf Windows 7 in der Konsole ? ;-))

Die Shortcut-Bedienung war mir damals in Fleisch und Blut übergegangen 
und ermöglichte sehr schnelles mausfreies Arbeiten. Und auch wenn die 
Netzlisten von DOS-Orcad immer noch brauchbar wären, leider gab es mit 
zunehmender Windowisierung der PCs immer mehr Probleme die Schaltpläne 
unter DOS anständig auszudrucken, so das wir die erstellten Pläne sogar 
in "Orcad für Windows" eingelesen haben, nur um sie dann ordentlich auf 
den A3-Drucker im Netzwerk zu schicken. Geroutet wurde anschließend mit 
Ultiboard.

Aber genug der Nostalgie, KiCad scheint mir von Leuten entwickelt worden 
zu sein die damals mit Orcad arbeiten mussten? Mir kommt es an vielen 
Stellen einfach sehr bekannt vor, auch das mit der Hierarchie. Leider 
nicht so sehr mit den Shortcuts.

Jetzt habe ich nach 10 Jahren aber leider vergessen wie es in Orcad und 
der komplexen Hierarchie eigentlich genau funktionierte, und ob es einen 
Tick besser gelöst war oder man auf die gleichen Problemchen beim 
Mehrfachkopieren der "Building Blocks" kam.

Wie auch immer, ich habe auch schon überlegt mir ein Programm zu 
schreiben das außerhalb von KiCad die Verwaltung von Templates 
übernimmt. In der Tat ist das .sch-Format nicht besonders kompliziert, 
und zum Glück haben die Components einen "Timestamp", der innerhalb 
eines Sheets eindeutig ist. Damit könnte man die Bauteile identifizieren 
und bei späteren Änderungen am Master aus dem Template heraus 
modifizieren, um z.B. ihre Position, nicht aber ihre Referenz, den Wert, 
Footprint usw. zu ändern, oder um etwas planvoller zu annotieren. Oder 
nicht mehr vorhandene Components zu löschen bzw. neue einzufügen.

Ich vermute dass sich irgendjemand auf diesem Planeten diese Arbeit 
schon gemacht hat, und man die Tools nur orten muss. Wenn ich etwas 
finde oder mir selbst erstelle werde ich das hier posten.

Dass diese Funktionalität eigentlich in KiCad hineingehört versteht sich 
von selbst, aber das dauert wohl noch ein paar Jahre.

Hallo Peter Lustig.


> Aber genug der Nostalgie, KiCad scheint mir von Leuten entwickelt worden
> zu sein die damals mit Orcad arbeiten mussten?

Keine Ahnung. Federführend ist wohl Jean-Pierre Charras, der 
Prorammierung in Frankreich lehrt. Der Rest der Programmierer ist über 
die ganze Welt verstreut.

> Mir kommt es an vielen
> Stellen einfach sehr bekannt vor, auch das mit der Hierarchie. Leider
> nicht so sehr mit den Shortcuts.

Nun, irgendwie sind sich Programme zum Schaltplanzeichnen und 
Platinenlayouten immer "irgendwie" ähnlich. Liegt wohl in der Natur des 
Objektes. Die Unterschiede ergeben sich dann in "Kleinigkeiten" wie
Hierarchien, Handling von Labels und so....

Der große Vorteil von open Source Programmen ist, das sie sich meistens 
von Leuten passend zu ihrem praktischen Bedarf geschrieben werden, und 
weniger für "Entscheider" die nicht so genau wissen, was eigentlich 
gebraucht wird, aber "den großen Überblick" haben und die Brieftasche 
zücken können. ;O)

> Jetzt habe ich nach 10 Jahren aber leider vergessen wie es in Orcad und
> der komplexen Hierarchie eigentlich genau funktionierte, und ob es einen
> Tick besser gelöst war oder man auf die gleichen Problemchen beim
> Mehrfachkopieren der "Building Blocks" kam.

Mmmmh. Ich hatte damals noch keinen wirklichen Bedarf an Hierarchien, 
weil:

1. Der Schaltplan noch auf ein DIN A4 Blatt passte, auch wenn das schon 
recht voll wurde. ;O)
2. Keine Baugruppe mehr als einmal vorkam, so das es sich nicht lohnte 
"Templates" zu benutzen.

>
> Ich vermute dass sich irgendjemand auf diesem Planeten diese Arbeit
> schon gemacht hat, und man die Tools nur orten muss.

Es ist langfristig für Kicad angedacht, eine Schnittstelle für Python 
einzubauen, die dann analog zu der ULP Schnittstelle bei Eagel verwendet 
werden kann.
Wie dem auch sei, es muss auch ohne gehen können. Mann sollte nur vorher
kicad schliessen, damit nicht zwei unterschiedliche Programme nach der 
gleichen Datei greifen.

In dem Falle ist natürlich auch die Wahl Deiner Programmiersprache 
egal...Du nimmst, was Dir am besten liegt.

Von einem einzigen solchen Programm unter Windows weiss ich. Es schaltet 
Dir die Values im Schaltplan wahlweise alle auf unsichtbar oder 
sichtbar, ohne das Du alle einzeln durchklicken musst.

> Wenn ich etwas
> finde oder mir selbst erstelle werde ich das hier posten.

Danke im Voraus!
Allerdings wäre eine andere gute Stelle zum veröffentlichen hier im File 
Repository der User Group: 
http://tech.groups.yahoo.com/group/kicad-users/
Möglicherweise findest Du oben erwähntes Programm auch dort.

> Dass diese Funktionalität eigentlich in KiCad hineingehört versteht sich
> von selbst, aber das dauert wohl noch ein paar Jahre.

Frag doch mal an, ob Du mitschreiben kannst. ;O)

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.dl0dg.de

Stefan Salewski schrieb:

> Wenn man alles einbaut, was sich Einzelne wünschen, dann wird es
> womöglich für die breite Masse zu kompliziert, insbesondere für
> Hobbyisten.

Wenn man es "nur" einbaut sollte ja auch der Hobbyist damit klarkommen, 
wenn er es einfach nicht verwendet solange er es nicht braucht, und es 
so gut versteckt ist dass es ihn nicht stört ;-)

Die Subsheets helfen sehr bei der Strukturierung und der Lesbarkeit 
eines Schaltplans. Das macht Sinn wenn es sich um komplexere oder "in 
sich oft wiederholende" Schaltungen bzw. Schaltungsteile handelt. Die 
Schaltungen mit denen ich zu tun hatte verteilten sich oft auf 25 A4 
Blätter, aber oft war dann auf einem Blatt wirklich nicht viel drauf.

Man wird bei hierarchischen Schaltplänen nicht sofort von Bauteilen und 
Wires erschlagen, sondern versteht erstmal die grobe Funktion der 
Schaltung anhand des Root-Sheets (in Blöcken, z.B. Netzteil, I/O, CPU, 
Schnittstellen, Steckerleisten).

Wenn man dann in die Blöcke hineingeht steckt dahinter die 
Implementierung. Anhand von Bussen und anderen Leitungen wird schnell 
klar welcher Block welche Signale benötigt und mit welchem anderen Block 
in Verbindung steht.

Ist ein wenig so wie die Kapselung beim Programmieren, also das Programm 
in mehrere Module zu teilen statt alles in ein Modul zu packen. In jedem 
Subsheet gibt es dann z.B. lokale Labels, die auch nur dort gültig sind 
und auch wieder die Lesbarkeit erhöhen. Heißt hier auch "Flat 
Hierarchy".

Um beim Programmieren zu bleiben, sowas wie "prozedurale Programmierung" 
kommt ins Spiel, wenn man das selbe Subsheet mehrfach verwendet, hier 
heißt das dann "Complex Hierarchy": es spart einem das immer wieder 
gleiche Malen des selben Schaltungsteils, wenn es ihn mehrfach gibt. Bei 
Änderungen muss man nur noch ein Subsheet ändern - fertig.

Das Problem von KiCad ist dass man in letzterem Fall auf automatische 
Annotation angewiesen ist, die Benennung der Bauteile erfolgt dabei 
immer durch KiCad, beim Reverse Engineering fällt man damit auf die 
Nase, weil die Bauteilennamen schon vorher feststehen.

Der Ausweg mit dem Umkopieren eines Subsheets als  "Building Block" ist 
nur ein Notbehelf, letztlich fertigt man nur Kopien von Subsheets und 
erstellt keine Referenz - mit all seinen Nachteilen.

Natürlich machen Subsheets Mühe - man muss seine Schaltung strukturieren 
und kann nicht einfach drauf loszeichnen. Hat man was vergessen muss man 
neue Pins setzen, evtl. mehrere Subsheets zusammenfassen oder neu 
zerteilen, das Umbauen macht also auch wieder Mühe.