Hallo, seit ein paar Tagen arbeite ich mich in Kicad ein. Auch hier im Forum habe ich schon einige Tipps erhalten. Im folgenden komme ich aber nicht weiter. Ausgangsituation (Beispiel): Ich habe 3 Schaltplandateien (hierarch_1.sch, root_1.sch, root_2.sch). hierarch_1.sch ist als "BuildingBlock" in root_1.sch und root_2.sch lt. Beitrag "Re: KiCAD - hierarchical sheets -- Hilfe!" eingebunden. Das klappt sehr gut. Problem: Wähle ich bei Ausführen der Annotation in root_1 oder root_2 "Auf alle Schalpläne anwenden", dann werden mir die Indizes auch im hierarch_1.sch geändert. Mache ich zuerst die Annotation für hierarch_1.sch und danach in root_1 oder root_2 jeweils mit "nur auf den gegenwärtigen Schaltplan anwenden" und "bestehende Annotation ersetzen", dann wird wieder mit Index Nummer 1 begonnen und spatestens beim ERC mittels Fehlermeldung das "Mehrfachelement!" bemängelt. Was muß ich tun, um einmal im Building Block vergebene Indizes beizubehalten und dennoch den ERC zufrieden zu stellen und die Netzliste erzeugen zu können? Danke -Holger P.S. Bernd schreibt in Beitrag "Re: KiCad: Mehrere Schaltplanseiten -- Rationelles Arbeiten mit "Buildingblocks" u.a.: <<<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.>>> Meine Frage ist: Was muß ich tun, damit das passiert?
Hallo Holger. > Ausgangsituation (Beispiel): Ich habe 3 Schaltplandateien > (hierarch_1.sch, root_1.sch, root_2.sch). hierarch_1.sch ist als > "BuildingBlock" in root_1.sch und root_2.sch lt. > Beitrag "Re: KiCAD - hierarchical sheets -- Hilfe!" eingebunden. Das > klappt sehr gut. > Ja. Aber.....Du bist schon mit der Nase an das Problem gestossen. > Problem: Wähle ich bei Ausführen der Annotation in root_1 oder root_2 > "Auf alle Schalpläne anwenden", dann werden mir die Indizes auch im > hierarch_1.sch geändert. Mache ich zuerst die Annotation für > hierarch_1.sch und danach in root_1 oder root_2 jeweils mit "nur auf den > gegenwärtigen Schaltplan anwenden" und "bestehende Annotation ersetzen", > dann wird wieder mit Index Nummer 1 begonnen und spatestens beim ERC > mittels Fehlermeldung das "Mehrfachelement!" bemängelt. Das Problem ist, das hierarch_1.sch ja für beide roots ein und dasselbe File ist. Wenn root1 am File rumfummelt, so ist es dann auch für root2 geändert und umgekehrt. > > Was muß ich tun, um einmal im Building Block vergebene Indizes > beizubehalten und dennoch den ERC zufrieden zu stellen und die Netzliste > erzeugen zu können? Abhilfe: File hierarch_1.sch Kopieren und umbenennen, oder Kopie mit gleichem Namen in anderem Pfad (find ich persönlich aber gefährlich). Warum sollte nicht root1 einen hierarch_1.sch haben und root2 einen hierarch_2.sch. Die beiden kommen sich nicht ins Gehege, und auch der Mensch findet sich besser zurecht. Das mit dem beibehalten der Indizes aus dem Building Block ist so einfach nicht möglich. Grundsätzlich nicht, weil der gleiche Building block ja mehrmals auftreten kann. Gleiche Referenzen/Indizes würde dann bedeuten, das mehrere Bauteile mit der gleichen Referenz auftauchen. Das ist aber etwas, was man nach kurzem Überlegen lieber vermeiden möchte. Allerdings kann ich Deinen Wunsch verstehen....was machbar wäre, der Übersichtlichkeit halber, wäre, gleiche Bauteile in mehrmaligen Verwendungen eines Building Blocks mit einem "Nummernkreissystem" zu bezeichnen. Also z.B. R15 aus einem Building Block würde in der ersten Verwendung zum R115 (oder RA15), in der nächsten zum R215 (oder RB15) usw. KiCAD unterstützt als Referenz vier alphanumerische Stellen. Solange Du bei Zahlen bleibst, geht das nur bis 9999. Unter Zuhilfenahme von Buchstaben wird das aber viel mehr...... Leider macht das die Annotation nicht automatisch. Das müsstest Du von Hand machen, und dabei noch eine Abstreichliste führen, damit Du Dich nicht vertust. Ok, möglicherweise seid Ihr Jungspunde mir da mit Eurem Konzentrationsvermögen noch überlegen. So ein Nummernkreissystem wäre auf meinem KiCAD Wunschzettel zimlich weit oben, ist aber garantiert nicht leicht zu implementieren.....und hier muss ich die Klappe halten, weil ich selber gar nicht programmieren kann. Was auch nett wäre, wäre Pre- oder Suffixe zur Bauteilreferenz einzuführen, abhängig davon, in welcher Verwendung von Buildingblock das bauteil gerade auftaucht. Ist aber genauso Wunschvorstellung. > P.S. Bernd schreibt in > Beitrag "Re: KiCad: Mehrere Schaltplanseiten -- Rationelles Arbeiten mit "Buildingblocks" u.a.: <<<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.>>> Das bezieht sich auf einen hierarch_1.sch, der im GLEICHEN root.sch MEHRMALS verwendet wird. Und es bezieht sich ausdrücklich nur auf die Annotation. Sobalt Du den Schaltplan aber topologisch änderst, hast Du die Änderung in allen Verwendungen (Instanzen?) von hierarch_1.sch, weil sie alle auf das gleiche File verweisen...... Willst Du mehrere topologische Variationen von hierarch_1.sch im gleichen root, must Du hierarch_1.sch kopieren, umbenennen (oder in einen anderen Pfad packen, s.o.)und dann ändern. Diese Varianten können wiederum selber in mehreren Verwendungen (Instanzen?) auftreten. Die automatische Annotation hält diese Verwendungen (Instanzen?) durchaus auseinander. Ich glaube, in der modernen Sprache wird hier vieleicht besser der Begriff "Instanz" verwendet. Sicher bin ich mir aber nicht, weil ich meine, mich zu erinnern, das "Instanzen" automatisch eine hierarchische Ordnung voraussetzten. Die Verwendungen hier sind aber u.U. durchaus gleichwertig Nebeneinander, und nicht unbedingt in unterschiedlichen Ebenen, obwohl auch dieses sein kann. Hast Du Dir das Beispielprojekt mal angesehen? Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.dl0dg.de
Hallo Bernd, vielen Dank für deine Ausführungen. > Abhilfe: File hierarch_1.sch Kopieren und umbenennen, ... Ja aber genau das möchte ich ja vermeiden. Ich möchte EINEN Building Block haben und wenn ich an dem was verändere soll das in allen root_x.sch eingearbeitet werden. Möglicherweise habe ich dabei noch nicht alle Kosequenzen bedacht: Ich stelle mir das ähnlich vor, wie der Aufbau von Software-Modulen (oder Libraries). Der einmal geschriebene code einer Library (Building Block) kann da auch in mehrere Programme (root_x.sch) compiliert werden. Wenn ein Fehler in einer Funktion der Library ausgemerzt wird, braucht dies nicht in den Sourcen der (vielen) Programme passieren, sondern nur in der Library. Neucompilieren der Programme. Fertig. > Das mit dem beibehalten der Indizes aus dem Building Block ist so > einfach nicht möglich. Grundsätzlich nicht, weil der gleiche Building > block ja mehrmals auftreten kann. Gleiche Referenzen/Indizes würde dann > bedeuten, das mehrere Bauteile mit der gleichen Referenz auftauchen. Das > ist aber etwas, was man nach kurzem Überlegen lieber vermeiden möchte. Ja, das trifft doch aber nur zu, wenn ein Building Block mehrmals in einem root eingebunden wird. Das war ja nicht mein ursprüngliches Problem (s.u. Fallbeispiele) > Allerdings kann ich Deinen Wunsch verstehen....was machbar wäre, der > Übersichtlichkeit halber, wäre, gleiche Bauteile in mehrmaligen > Verwendungen eines Building Blocks mit einem "Nummernkreissystem" zu > bezeichnen. > Also z.B. R15 aus einem Building Block würde in der ersten Verwendung > zum R115 (oder RA15), in der nächsten zum R215 (oder RB15) usw. KiCAD > unterstützt als Referenz vier alphanumerische Stellen. Solange Du bei > Zahlen bleibst, geht das nur bis 9999. Unter Zuhilfenahme von Buchstaben > wird das aber viel mehr...... > Leider macht das die Annotation nicht automatisch. Das müsstest Du von > Hand machen, und dabei noch eine Abstreichliste führen, damit Du Dich > nicht vertust. Ok, Sehr gute Idee. Ich werde in diese Richtung mal weiterexperimentieren. Hab' mal angefangen die Indizes der Building Blocks mit "a" beginnen zu lassen (z.B. aR1, aR2, für die nächste Art Building Block bR1, bR2, usw.) Grundsätzlich muß man wohl die Fallbeispiele: * in einem root wird eine Art Building Block mehrfach verwendet (dann klappt das mit aXX, bXX aber auch nicht ohne hierarch_1.sch mehrfach zu kopieren. * ein Building Block wird in mehreren root_x.sch verwendet (mein ursprüngliches Problem) auseinanderhalten. > möglicherweise seid Ihr Jungspunde mir da mit Eurem... Naja, so jung bin ich auchh nicht mehr - aber das ist ein anderes Thema... > Hast Du Dir das Beispielprojekt mal angesehen? Das im HierarchischeLabel.zip habe ich mir angesehen, geht aber an meinem Problem vorbei, wenn ich das richtig verstanden habe. Viele Grüße Holger
Hallo Holger. > Ich möchte EINEN Building > Block haben und wenn ich an dem was verändere soll das in allen > root_x.sch eingearbeitet werden. Gefährliche Idee. Grundsätzlich ist da zwar was dran, aber in dem Punkte finde ich gibt es schon einen gravierenden Unterschied zu Software: Software ist verhältnismäßig einfach zu Parametrisieren. Du kannst Schalter einbauen noch und nöcher, und passend umschalten könnte sich das sogar von selber. Hardware ist wesentlich stärker auf eine konkrete Situation hin entwickelt. Die Sondermaßnahmen, die Du in Schaltung B einbaust, weil sie in einer extrem gestörten Umgebung verwendet wird, möchtest Du in der sehr ähnlichen Schaltung A jetzt nicht nachträglich einführen, weil die gut läuft, in unkritischer Umgebung eingesetzt wird, und die Entstörmaßnahmen zum Beispiel Geld und Platz kosten, und z.B. das Regelverhalten zum Trägen hin verschieben. Und das gilt jetzt nur für den Schaltplan. Wenn Du das Layout mit unterschiedlichen Technologien (SMD, TH und mixed) nimmst, und jetzt noch das Layout in unterschiedliche Formen bringst (mal alles auf einem Knubbel, mal an der Kante lang, mal um die Ecke, Einzel-, Doppel- und Multilayer), siehst Du, das es nicht so einfach ist. Die Building Blocks sind als schnelle Arbeitsmöglichkeit für Standardschaltungen gedacht. Selbst beim LM317 kommen, wenn man es genau nimmt, dutzende zusammen..... So ein Building Block kann also nur einfache Standardsituationen abdecken, und ansonsten ein Gerüst bilden, das im konkreten Fall noch angepasst werden muß. Bei Software ist es leichter, Situationen zu finden, wo ein Standardunterprogramm alle oder fast alle Situationen abdecken kann. Besonders jetzt, wo Speicherplatz so wohlfeil geworden ist. Wenn Du um jedes Byte erbittert und zäh kämpfen müstest, sähe das auch anders aus. Du kannst natürlich auch in Hardware ein "Netzteil" bauen, das von 1V DC einer Taschenlampenbaterie über 250V 50HZ bis 500V 400Hz alles schluckt und Dir daraus potentialfreie 12V DC macht.....denkbar und machbar wäre das, aber das ganze wäre so aufwändig, und hätte soviele andere Nachteile (z.B. Wirkungsgrad) das es keiner macht. In der Software findest Du etwas ähnliches aber oft. :-) > > Möglicherweise habe ich dabei noch nicht alle Kosequenzen bedacht: Ich > stelle mir das ähnlich vor, wie der Aufbau von Software-Modulen (oder > Libraries). Der einmal geschriebene code einer Library (Building Block) > kann da auch in mehrere Programme (root_x.sch) compiliert werden. Wenn > ein Fehler in einer Funktion der Library ausgemerzt wird, braucht dies > nicht in den Sourcen der (vielen) Programme passieren, sondern nur in > der Library. Neucompilieren der Programme. Fertig. Der Nachteil der einen Schaltung ist oft der Vorteil der anderen. Insofern ist der Fehler nicht unbedingt immer ein "Fehler". Die Fehlerlose alles abdeckende Universalschaltung ist meistens nicht praktikabel, was somit der Hauptfehler wird. Es ist sehr wahrscheinlich, das Du nicht willst, das jede Änderung sofort in allen davon abgeleiteten anderen Schaltungen mitumgesetzt wird. > >> Das mit dem beibehalten der Indizes aus dem Building Block ist so >> einfach nicht möglich. Grundsätzlich nicht, weil der gleiche Building >> block ja mehrmals auftreten kann. Gleiche Referenzen/Indizes würde dann >> bedeuten, das mehrere Bauteile mit der gleichen Referenz auftauchen. Das >> ist aber etwas, was man nach kurzem Überlegen lieber vermeiden möchte. > Ja, das trifft doch aber nur zu, wenn ein Building Block mehrmals in > einem root eingebunden wird. Das war ja nicht mein ursprüngliches > Problem (s.u. Fallbeispiele) Nun, stell Dir vor, Du hast eine Schaltung, z.B. einen Spannungswandler aufgebaut als Buildingblock, und die darin enthaltenen Widerstände von 1-10 Durchnummeriert. Nun hast Du einen anderen Building Block, z.B. einen AD-Wandler, wo Du das auch machst. Steckst Du beide in den gleichen root-schaltplan, hast Du schon wider die Situation, das zwei Bauteile die gleiche Nummer haben. Und vermutlich werden die noch nichteinmals eine ähnliche Funktion haben..... Ok, Du könntest jetzt in Deinem AD-Wandler Block die Widerstände z.b. von 11-20 durchnummerieren, dann käme das wieder hin, aber wo sollte das enden? Vor allem, was machst Du, wenn Du jetzt im Spannungswandler zwei Widerstände hinzufügen willst? Oder, noch trivialer, zwei Spannungswandler aus dem gleichen Buildingblock einfürst...einer von 1-10, der nächste von 11-20? Ok, Du könntest jetzt von 21-30 Nummerieren....was ist, wenn Du aber jetzt irgendwo einen "vergessenen" Vorverstärker für den AD-Wandler hast, der von 21-30 nummeriert ist? Du selber könntest für Dich vieleicht mit viel Mühe ein solches System konsistent halten, aber wenn Du Building Blocks mit anderen wie z.B. Footprints teilen woltest, käme das sehr schnell nicht mehr hin. Trozdem kommt das Beispiel mit den Software Librarys als solches hin.....Du machst Dir beim objektorientierten Programmieren z.B. nur wenig Gedanken über die "nummerierung" bzw. Benahmung der Unterprogramme. Weil entweder Deine Entwicklungsumgebung das komplett übernimmt, und Du nicht mitbekommst, das die nur brutal geradeaus "durchnummeriert", oder die Entwicklungsumgebung halbautomatisch Nahmen nach bestimten kriterien aus einem Namensraum heraus kreiert. Die Nummerierung oder Nahmensgebung ist in diesem Falle kein Thema. Brutal durchnummerieren kann KiCAD auch gut. Du kannst sogar die Zählrichtung wählen. Nur brutal durchnummerieren langt Dir jetzt auf einmal nicht...... Dem "Namensraum" würde der Idee mit Nummernkreis bzw. Pre- oder Suffix entsprechen. > Sehr gute Idee. Ich werde in diese Richtung mal weiterexperimentieren. > Hab' mal angefangen die Indizes der Building Blocks mit "a" beginnen zu > lassen (z.B. aR1, aR2, für die nächste Art Building Block bR1, bR2, > usw.) > Naja. Auf diese Weise schafst Du gut Systematik, "verbrauchst" aber viele Nummern. Weil wenn Du in einem Block bestimmte Nummern nicht brauchst, kannst Du sie nicht in einem anderen verwenden, ohne die Systematik zu verletzten. Auf die Tour kannst du höllisch Nummern "verfeuern". Dann wird vierstellig auch knapp. > Grundsätzlich muß man wohl die Fallbeispiele: > * in einem root wird eine Art Building Block mehrfach verwendet (dann > klappt das mit aXX, bXX aber auch nicht ohne hierarch_1.sch mehrfach zu > kopieren. > * ein Building Block wird in mehreren root_x.sch verwendet (mein > ursprüngliches Problem) > auseinanderhalten. > Also ich sehe die Fälle so: Wird einmal oder mehrmals auf das gleiche hierarch_1.sch zugegriffen? Wird ein Wert oder eine Referenz geändert? Es ist ein Unterschied, ob in dem mehrfach verwendeten Block die REFERENZ oder der WERT des Bauteils geändert wird. Die Referenz kann KiCAD auseinanderhalten, den Wert nicht. Darum kannst Du wohl in zwei Subschaltplänen die auf ein und das selbe hierarch_1.sch zugreifen, den einen Widerstand RA1 nennen und den Korespondierenden aus dem anderen Subschaltplan RB1, ohne das KiCAD Probleme macht, aber Du kannst NICHT dem einen Widerstand jetzt 10k zuweisen, und dem anderen 4k7. Das geht NICHT, weil es in hierarch_1.sch eingetragen wird, und somit immer für beide gilt. Unterschiedliche Footprints, z.B. einmal TH und einmal SMD, oder einmal TH liegend und einmal TH stehend, geht aus dem gleichen Grund nicht. In Punkto Footprints kannst Du aber leichter Abstriche machen, weil Du die Zuweisung in CVpcb noch nachträglich ändern kannst. Und in der Netzliste kannst Du jedem individuellen Bauteil einen individuellen Footprint zuweisen. Wenn Du also in anderen Feldern ausser der Referenz Unterschiede haben willst, MUSST Du hierarch.sch kopieren. >> Hast Du Dir das Beispielprojekt mal angesehen? > Das im HierarchischeLabel.zip habe ich mir angesehen, geht aber an > meinem Problem vorbei, wenn ich das richtig verstanden habe. Stimmt. Trozdem denke ich, könnte Dir ein detailiertes Verständnis dafür auch bei Deinem Fall weiterhelfen. Wie gesagt, wichtig ist, die Referenz kann sich KiCAD selber im root.sch merken, aber der Wert wird dem hierarch.sch entnommen. Also ist zu Überlegen: Wert Änderung? Wieviele und wer greift darauf zu? Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.dl0dg.de
Nachtrag: Nachdem ich darüber geschlafen habe, ist mir aufgefallen, das ich einen Fehler gemacht habe, weil ich einfach "Referenz" und "Annotation" durcheinandergeworfen und gleichgesetzt habe. Die Referenz ist natürlich wie der Wert im hierarch.sch festgelegt. Aber die Annotation NICHT. So schafft es KiCAD, auch in hierarchischen Subschaltplänen, die mehrfach auftreten, die Durchnummerierung konsistent zu halten. Hinweis: Eine Bauteilbezeichnung (z.B. "R12") setzt sich zusammen aus der Referenz (im Beispiel das "R") und einer Annotation (im Beispiel die "12"). Die Annotation ist also ein reiner Zählwert. Die Referenz wird als Teil des Symbols fest angelegt, kann aber nachträglich Editiert werden. Auch die Annotation kann von Hand geändert werden. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.dl0dg.de
den wunsch solche mehrfach instanzierungen zu machen in einem schema kenne ich gut. wäre ja so schön einen block einmal zu zeichnen und dann mehrfach zu benutzen. software kanns vhdl kanns wieso nicht hier? klar das dies nicht einfach ist zu implementieren, mit den vielen abhängigkeiten die damit entstehen. aber keine bange, ich habe da meine erfahrungen mit altium designer 2004 und 2006 und dem versuch vom mehrfach instanzierung. am ende hatte ich wieder zwei seperate subsheets...
Hallo nuess0r. > den wunsch solche mehrfach instanzierungen zu machen in einem schema > kenne ich gut. wäre ja so schön einen block einmal zu zeichnen und dann > mehrfach zu benutzen. software kanns vhdl kanns wieso nicht hier? > Das mit den Instanzen mehrfach verwenden klappt in KiCAD recht gut. Aber Instanz heißt immer eine "Instanz von einem Original". Wenn ich jetzt Änderungen an einer einzelnen Instanz haben möchte, ist das ja in dem Sinne keine Instanz mehr.....ich brauche eben dafür ein neues "Original". Das ist erstmal ein grundsätzliches logisches Problem. In Software Librarys wird sowas glaube ich oft durch eine zusätzliche Parametrisierung gemacht....? Das mit dem Durchnummerieren ist ein anderes Problem, das mit dem obigen insofern verknüpft ist, als das die Idee eines Workarounds war, die Unterscheidung von Bauteilen in verschiedenen Subsheets über die Referenz zu machen..... Bei der Referenz ergibt sich dann das Problem mit den Instanzen..... > ich habe da meine > erfahrungen mit altium designer 2004 und 2006 und dem versuch vom > mehrfach instanzierung. am ende hatte ich wieder zwei seperate > subsheets... Auch, wenn Du keine Unterschiede zwischen den Instanzen hattest? Denn das würde ich dann schon erstaunlich finden. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.dl0dg.de
Thread beobachten
Seitenaufteilung abschaltenBitte 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.