Hallo zusammen. Als kurzer Disclaimer: Ich nutze seit Ewigkeiten EAGLE privat, seit knapp 10 Jahren auch in meiner Firma. Für den Umfang der Boards, die ich und meine Kollegen machen reicht das alles aus und durch die erstellten Bibliotheken und Zusatz-Skripte (ULPs) ist es auch über die Zeit immer mehr auf uns angepasst. Das einzige Thema ist: Was passiert, wenn irgendwann EAGLE 7.7 nicht mehr unterstützt wird? Dafür wollte ich mich mal umgucken, was es so an Alternativen gibt und da ist KiCAD natürlich auch zu berücksichtigen. Dazu habe ich mal ein, zwei Videos geguckt und mir hinsichtlich der Bauteil-Bibliotheken die Frage gestellt, wie diese in der Regel bzw. am Besten angelegt werden. Wie gesagt komme ich aus der EAGLE-Ecke und dort habe ich u.a. eine Bibliothek für Spannungsregler und eine für Transistoren. In jeder Bibliothek sind Symbol und Package gespeichert, die dann als Device zusammengefügt werden. Das bedeutet, es gibt keine eigene Package-Bibliothek was den Nachteil bringt, dass ich z.B. das SOT23 Package in beiden Bibliotheken parallel (doppelt) gespeichert habe. Muss ich am Package was anpassen, muss ich diese Änderungen also in allen Bibliotheken vornehmen (bzw. kopieren), die dieses Package beinhalten. Wenn ich mir die Videos und das Vorgehen darin angucke, wird dort beim Erstellen des Symbols schon der Pin zugewiesen. Und da verstehe ich nicht den Sinn, wieso das im Symbol schon fix festgelegt wird. Ich habe mal zwei Bilder angehängt, das Pinout vom MCP1754S und vom TLV1117. Beides sind Festspannungsregler mit mehreren wählbaren Ausgangsspannungen. In EAGLE würde ich nun also die passenden Packages erstellen, ein Symbol mit Vin, Vout und GND und zwei Devices erzeugen (TLV1117 und MCP1754S). Dort kann ich dann das Symbol einfügen, die entsprechenden Packages mit dem Namenszusatz (DCY, KCT, ...) einfügen und dort dann die Symbol-Pins den Package-Pads zuweisen. Zusätzlich kann ich über die "Technology" Funktion auch noch die verschiedenen Spannungsoptionen eintragen, sodass ich dann am Ende allein beim MCP1754S jeweils drei Ausgangsspannungen für insgesamt vier Packages habe. Ich kann so also (nur für den MCP1754S betrachtet) zwölf verschiedene Bauteile erstellen und jedem nicht nur das Pinning verpassen, sondern auch Bestellnummern oder Lagerplätze hinterlegen. Wenn in KiCAD nun aber das Symbol das Pinning beinhaltet... Muss ich dann einen Regler-Symbol für jedes Pinout erzeugen? Im SOT23 ist Pin 1 GND, beim SOT-89 ist es aber Vin. Beim SOT-223-3 gibt es aber 4 Pins (GND ist also Pin 2 UND 4) und im DFN Package ist es wieder komplett anders. Ich kann ja noch nicht mal sagen, dass es ein Reglersymbol gibt, dass für SOT-223-3 Packages passt, denn dann kommt der TLV1117 um die Ecke und da ist dann wieder alles anders, als beim selben Package beim MCP1754S. Wie würde man sowas am besten umsetzen? Denn ich kann mir nicht vorstellen, dass ich der erste bin, der auf dieses Problem stößt. Muss ich dann dem Symbol Namen passend für das Pinning geben? Also Regulator_GND_VOUT_VIN, Regulator_VIN_GND_VOUT, .... Oder bekommt jedes einzelne Bauteil eine eigene Bibliothek? Das wäre ja auch mega umständlich, Fehler zu fixen und 1000e Bibliotheken durchzuarbeiten. Was darüber hinaus auch nie Thema bei den Videos war: Wie funktioniert das mit der Auswahl der Ausgangsspannungen und den daran geknüpften Bestellnummern oder Lagerplätzen. Es haben alle nur z.B. einen 0805 Widerstand eingefügt und den dann manuell auf 1k oder so gesetzt. Entsprechend könnte ich als Bauteilwert des Reglers auch "5V" schreiben.. Aber was ist dann mit der Bestellnummer, ...? Und woher weiß ich, dass ich für den MCP1754S das "SOT23" Package wählen kann, für den TLV1117 aber nicht? Sprich, was hindert mich daran ein Package zu nehmen, dass in der Bibliothek vorhanden ist, aber nicht hergestellt wird und gekauft werden kann. Es wäre schön, wenn mich da jemand aufschlauen könnte. Gerne auch mit Tutorials oder Vorlagen. Grüße Michael
Angehängte Dateien:
-
MCP1754S.png
36 KB -
TLV1117.png
25 KB
:
Bearbeitet durch User
Michael S. schrieb: > Was passiert, wenn > irgendwann EAGLE 7.7 nicht mehr unterstützt wird? Nix. Diese Version telefoniert nicht nach Hause.
Ich habe dabei auch eher in Richtung Microsoft und IT geschielt. Irgendwann kommt Windows 12 oder so und dann läuft damit das alte EAGLE nicht mehr. Wer weiß..
Michael S. schrieb: > Ich habe dabei auch eher in Richtung Microsoft und IT geschielt. > Irgendwann kommt Windows 12 oder so und dann läuft damit das alte EAGLE > nicht mehr. Wer weiß.. Dann läuft es eben in einer VM oder unter Linux.
Michael S. schrieb: > Wie funktioniert das mit der Auswahl der Ausgangsspannungen und den > daran geknüpften Bestellnummern oder Lagerplätzen Dafür kann ich die Inventree-Software empfehlen. Mit einem Plugin (in Inventree) können Bauteile direkt aus der Inventree-Bauteilverwaltung in Kicad geladen werden. In Inventree werden die tatsächlichen Bauteile angelegt (eindeutige ID z.B. R_10k_0603, Bauteiltyp z.B. Widerstand, Wert z.B. 10k, beliebig viele Herstellerteile z.B. Vishay mit C0603103azr und Yageo mit wid0603k10ajfes, pro Herstellerteile beliebige Lieferanten z.B. Mouser und Reichelt mit jeweils Bestellnummer/Link, jeweils Lagerort und Bestand, KiCad-Symbolpfad in den Symbol-Bibliotheken z.B. Devices:R, Kicad-Footprint z.B. mySMD:0603). Dann kann in der Kicad-Bauteilauswahl das Bauteil für den Schaltplan gewählt werden und zeigt direkt in der Bauteilauswahl den vorhandenen Lagerbestand. In der Stückliste erscheint dann die eindeutige ID aus Inventree und kann damit weiterverarbeitet werden.
Michael S. schrieb: > Wie würde man sowas am besten umsetzen? Denn ich kann mir nicht > vorstellen, dass ich der erste bin, der auf dieses Problem stößt. Muss > ich dann dem Symbol Namen passend für das Pinning geben? Also > Regulator_GND_VOUT_VIN, Regulator_VIN_GND_VOUT, .... Oder bekommt jedes > einzelne Bauteil eine eigene Bibliothek? Die Pins müssen nicht unbedingt Nummern sein, sondern können -in Symbol und Footprint- auch Text sein. Also im Footprint ein Pad Vin, eines Vout, eines Gnd. Ggfs. zwei Pads, die Gnd heißen, z.B. für SOT-89-4. Je nach Bauteiltyp hättest du dann zwei Footprints mit unterschiedlichem Namen, die sich in der Pinbezeichnung unterscheiden. Den (Standard-)Footprint kannst du am Symbol vorgeben. Das Symbol ist dann 1. entweder für alle (Festspannungs-)Regler das gleiche (dann über Inventree separate Bauteile aus Bauteilwert, Symbol und Footprint zusammenstellen oder im Schaltplan händisch anpassen) oder 2. pro Ausgangsspannung ein Symbol erstellen und wiederverwenden. Für den zweiten Reglertypen dann den passenden anderen Footprint vorgeben. Oder andersherum zwei Symbole anlegen, bei denen die Pins als Nummern angegeben sind und jeweils zum generischen Footprint passen. Die Bibliotheks-Bauteile für Mosfets könnten da als Beispiel dienen.
H. H. schrieb: > Dann läuft es eben in einer VM oder unter Linux. Ich brauche für die Projekte und Bibliotheken etc. Zugriff auf das Firmennetz. Also selbst, wenn ich von der IT aus eine VM aufsetzen darf, kann ich vermutlich wählen zwischen einer alten Windows-Version ohne Netzwerk-Zugriff oder aktuellen Windows-Version, wobei ich mir dann die VM auch sparen kann. Markus E. schrieb: > Also im Footprint ein Pad Vin, eines Vout, eines Gnd. Ggfs. zwei Pads, > die Gnd heißen, z.B. für SOT-89-4. > Je nach Bauteiltyp hättest du dann zwei Footprints mit unterschiedlichem > Namen, die sich in der Pinbezeichnung unterscheiden. Den > (Standard-)Footprint kannst du am Symbol vorgeben. Aber damit verschiebe ich ja das Problem von "tausenden" Symbolen zu den Footprints und habe da dann "tausende" Footprints. Ein SOT-223-3_TLV1117, dann SOT-223-3_MCP1754S, SOT23_MCP1754S, ... Das ist ja noch schlimmer ;) Markus E. schrieb: > Oder andersherum zwei Symbole anlegen, bei denen die Pins als Nummern > angegeben sind und jeweils zum generischen Footprint passen. Das ist ja dann quasi wie ich beschrieben habe. Für jede Variante dann ein eigenes Symbol, dass zum generischen Footprint passt. Markus E. schrieb: > Dafür kann ich die Inventree-Software empfehlen. Markus E. schrieb: > Die Bibliotheks-Bauteile für Mosfets könnten da als Beispiel dienen. Jörg schrieb: > Scho gelesen: > https://docs.kicad.org/master/de/getting_started_in_kicad/getting_started_in_kicad.html#tutorial_teil_4_benutzerdefinierte_symbole_und_footprints Gucke ich mir mal alles an. Danke
:
Bearbeitet durch User
Michael S. schrieb: > Wie gesagt komme ich aus der EAGLE-Ecke und dort habe ich u.a. eine > Bibliothek für Spannungsregler und eine für Transistoren. In jeder > Bibliothek sind Symbol und Package gespeichert, die dann als Device > zusammengefügt werden. Das bedeutet, es gibt keine eigene > Package-Bibliothek was den Nachteil bringt, dass ich z.B. das SOT23 > Package in beiden Bibliotheken parallel (doppelt) gespeichert habe. Muss > ich am Package was anpassen, muss ich diese Änderungen also in allen > Bibliotheken vornehmen (bzw. kopieren), die dieses Package beinhalten. Wenn ich dich richtig verstehe, gibt es in Eagle nur je ein Bauteil in dem Symbol und Gehäuse untrennbar zusammen enthalten sind. > Wenn ich mir die Videos und das Vorgehen darin angucke, wird dort beim > Erstellen des Symbols schon der Pin zugewiesen. Und da verstehe ich > nicht den Sinn, wieso das im Symbol schon fix festgelegt wird. Du meinst hier KiCad? Man erstellt einen Schaltplan, damit man ihn verwenden kann. Darin möchte ich schon sehen an welchen Pin/Pinnummer der Eingang ist und wo der Ausgang usw. Dein Bsp. der Spannungsregler ist doch genau passend. Es gibt sehr viele unterschiedliche Pinbelegungen und Gehäusevarianten. In Eagle erstellst du damit ein Bauteil mit passenden Symbol und Gehäuse, was am Ende zusammengehört. In KiCad machst du das Gleiche nur eben in getrennten Bibliotheken. Symbol, Gehäuse, 3DModel. Die Pinnummern vom Gehäuse allein wird sich nie ändern. Das 3D Modell dazu auch nicht. Nur im Symbol wird sich je nach Spannungsregler, mit gleichen Gehäusen, die Funktion/Bedeutung der Pinnummer ändern. Das heißt du kannst am Bsp. Spannungsregler gezielt Symbole mit konkreten Bauteilnamen erstellen. TLV1117, MCP1754S. Diesen Symbolen weißt du das passende Gehäuse bis hin zum 3D Modell zu. Im Schaltplan fügst du das Symbol hinzu und fertig. Dann hast du im Layout Editor alles andere automatisch drin. Das ist nichts anderes wie in Eagle. Wenn alle Regler das gleiche Gehäuse verwenden, musst du nur unterschiedliche Symbole erstellen. Finde ich einfach. Was anders in KiCad ist, dass Gehäuse und 3D Modell kannst du auch mit anderen Symbolen verknüpfen, eben weil die Bibliotheken unabhängig sind. Bei Standardbauteilen wie Widerstände, benötigt man im Schaltplan nur ein generisches Symbol für alle Arten im Schaltplan. Hierfür lege ich für jeden Widerstand individuell im Schaltplan fest, welche Gehäuseform er haben soll. Unter > "Werkzeuge" > "Symbolfelder bearbeiten". Hier nutzt man die getrennten Bibliotheken. Will man sich die Bearbeitung sparen, legt man sich Symbole mit aussagekräftigen Namen an und weißt die Gehäuseform zu. Muss dann aber bei jeder Änderung im Schaltplan das Symbol neu ersetzen. Kann man halten wie Nolte. Ich sehe keine Probleme in der Verwendung. Also wenn du bisher gewohnt bis das ein Bauteil fest aus Symbol und Gehäuse besteht, dann kannst du das weiterhin auch in KiCad machen. Nur eben mit einer jederzeit änderbaren Zuweisung welches Gehäuse zum Symbol gehören soll. Was man wiederum jederzeit im Schaltplan unter > "Werkzeuge" > "Symbolfelder bearbeiten" ändern kann.
Michael S. schrieb: > Das einzige Thema ist: Was passiert, wenn > irgendwann EAGLE 7.7 nicht mehr unterstützt wird? An EAGLE 7.7 wird schon lange nichts mehr unterstützt. Aktuell ist Version 9.6 und die ist wegen Abschaltung des Lizenzservers durch AutoDesk nächstes Jahr wohl wirklich tot.
:
Bearbeitet durch User
Veit D. schrieb: > Wenn ich dich richtig verstehe, gibt es in Eagle nur je ein Bauteil in > dem Symbol und Gehäuse untrennbar zusammen enthalten sind. Jein. Du hast eine Sammlung an Symbolen und Packages in einer Lib-Datei und kannst mit den Devices dann die Symbole und Packages zusammenfügen, wie es gerade passt. Veit D. schrieb: > Dein Bsp. der Spannungsregler ist doch genau passend. Es gibt sehr viele > unterschiedliche Pinbelegungen und Gehäusevarianten. In Eagle erstellst > du damit ein Bauteil mit passenden Symbol und Gehäuse, was am Ende > zusammengehört. Am Beispiel der oberen beiden Chips würde ich ein Symbol erstellen und fünf Packages: für den TLV brauche ich den SOT-223 und TO-252 und für den MCP nutze ich auch den SOT-223 und brauche zusätzlich noch SOT-23, SOT-89 und 2x3mm DFN8. Was jetzt nur noch fehlt sind zwei Devices: TLV1117 und MCP1754S. Bei diesen verknüpfe ich die Pins (Vin, Vout, GND) mit den Pads der jeweiligen Packages. In den Devices kann ich zusätzlich die Festspannungen als Option angeben. Ich bin am Ende also bei fünf Packages, einem Symbol und zwei Devices. Beim MCP habe ich 3 Spannungen zur Auswahl (1.8V, 3.3V und 5V), beim TLV habe ich 5 Spannungen (1.5V, 1.8V, 2.5V, 3.3V und 5V). Die Verschiedenen Bezeichnungen wie TLV1117-15DCY (1.5V, SOT223) werden automatisch anhand meiner Einstellungen im Device erstellt und dann bei der Wahl beim Platzieren im Schematic ausgewählt. Wenn ich das jetzt übertrage und richtig verstehe, müsste ich also für die beiden Bauteile ebenso fünf Packages erstellen und dann aber 22 Symbole erstellen (12 Symbole für den MCP - 4 Packages á 3 Spannungen, und 10 für den TLV - 2 Packages á 5 Spannungen). Denn im Symbol steckt nicht nur das Pinning, ergo Package, sondern ebenso die Bestellnummer/Bezeichner -> Spannungsoption. Veit D. schrieb: > Du meinst hier KiCad? Man erstellt einen Schaltplan, damit man ihn > verwenden kann. Darin möchte ich schon sehen an welchen Pin/Pinnummer > der Eingang ist und wo der Ausgang usw. Richtig, ich auch. Bei EGALE wird dann die Pin-Nummer entsprechend zum gewählten Package angezeigt. Die ist also nicht fix am/im Symbol, was ja quasi Knackpunkt meiner ganzen Fragerei ist. Veit D. schrieb: > Ich sehe keine Probleme in der Verwendung. Also wenn du bisher gewohnt > bis das ein Bauteil fest aus Symbol und Gehäuse besteht, dann kannst du > das weiterhin auch in KiCad machen. Nur eben mit einer jederzeit > änderbaren Zuweisung welches Gehäuse zum Symbol gehören soll. Was man > wiederum jederzeit im Schaltplan unter > "Werkzeuge" > "Symbolfelder > bearbeiten" ändern kann. Ein Bauteil kann mehrere Gehäuse haben. Das ist der Punkt, wo man sich soweit ich das verstanden habe die Arbeit spart. Außerdem, wie ich oben auch schon meinte, kann ich im Projekt (Schaltplan/Layout) beim Package nur das wählen, was mit dem Device verknüpft ist. Ich kann dort kein TO-252 für den MCP1754S wählen, da es den gar nicht gibt. Diese Information bekomme ich bei KiCAD scheinbar nicht (direkt). Ich darf da eigentlich ja nur die Symbole mit anderen austauschen, wo das gewünschte Package hinterlegt ist. Denn sonst stimmt mindestens die Bestellnummer nicht oder ich wähle ein Package aus, das gar nicht für den Chip vorhanden ist. Rainer W. schrieb: > Michael S. schrieb: >> Das einzige Thema ist: Was passiert, wenn >> irgendwann EAGLE 7.7 nicht mehr unterstützt wird? > > An EAGLE 7.7 wird schon lange nichts mehr unterstützt. > Aktuell ist Version 9.6 und die ist wegen Abschaltung des Lizenzservers > durch AutoDesk nächstes Jahr wohl wirklich tot. Ich weiß. EAGLE 7.7 bekommt keinen Support mehr. Ich meine "von der Umgebung/Windows nicht mehr unterstützt". Sprich, es käme Windows 12, die IT sagt, das muss jetzt überall drauf, und damit liefe kein EAGLE 7.7 mehr. Michael S. schrieb: > Markus E. schrieb: >> Die Bibliotheks-Bauteile für Mosfets könnten da als Beispiel dienen. > > Gucke ich mir mal alles an. Danke Ich habe mal reingeguckt und es ist so, wie ich es bisher auch verstanden habe. Es gibt für jede einzelne Variante ein eigenes Symbol. Das macht die Liste in den jeweiligen Bibliotheken natürlich elend lang. Aber durch die Suchfunktion kommt man da schon ans Ziel und mit dem "Symbol ableiten von" kann man sich scheinbar ein bisschen Arbeit beim erstellen der ganzen Varianten sparen. Ich meine das geht über Spannungsregler ja hinaus. Microcontroller mit verschiedenen Speichergrößen und Temperaturbereichen, teilweise Spannungsbereichen aber immer gleichem Pinning.
Rainer W. schrieb: > Aktuell ist Version 9.6 und die ist wegen Abschaltung des Lizenzservers > durch AutoDesk nächstes Jahr wohl wirklich tot. Achso, dazu noch eine Sache: EAGLE als isoliertes Tool wird abgeschaltet. Aber soweit ich weiß, bleibt es auch künftig Teil von AutoDesk Fusion. Man könnte es also unter Fusion soweit ich weiß weiter nutzen. Es heißt dann halt nicht mehr EAGLE und ist auch keine alleinstehende Software mehr.
Hallo, wenn du jede Gehäusevariante eines Bauteils mit Kenndaten und Bestelldaten hinterlegen möchtest, dann bleibt dir gar nichts anderes übrig wie Hunderte von Symbolen mit entsprechenden Zusatzeinträgen anzulegen. Gehäusezuordnungen bleiben ja größtenteils gleich, wenn sich nur die Spannung ändert. Lege ein Symbol mit allen komplett an, danach kopieren und Änderungen der Einträge und im Symbol vornehmen. Damit sollte sich die Arbeit im Rahmen halten. Oder jeweils ein "einfaches" Symbol ohne Spannungsangabe und ohne hinterlegte weiteren Daten. Dann könnte man ein Kommentar im Schaltplan hinterlegen ob 3.3V oder 5V bzw. man sieht es am Spannungsreferenzsymbol. Also nur Symbole mit zugeordneten Gehäusen anlegen. Den Rest trägt man in die erzeugte BOM ein zum bestellen. Wie man es macht hängt von seinen Vorlieben ab.
Hallo nochmal ;) Ich melde mich nach einiger Zeit mal wieder, da ich zufällig mitbekommen habe, dass nun KiCAD v10 verfügbar ist und ich ein bisschen die Hoffnung hatte, dass sich was in der Richtung des oben beschriebenen Themas getan hat. Ich dachte mir, wozu denn diese ganzen KIs gut sind, wenn die mir da nicht auch helfen können. Um es abzukürzen: Gemini hat mir über ziemlich lange Zeit verkauft, dass ich das Symbol/Footprint-Matching auf Pin/Pad Ebene über die Datenbank-Bibliotheken machen kann. Nach längerer Zeit und mal von ein paar Google-Suchen und ChatGPT sowie Copilot bestätigt, hat sich das als "ach ups, ne das waren nur mal Vorschläge" rausgestellt. Leider. Allerdings hab ich mich gefragt, und das wollte ich dann sicherheitshalber mal direkt Menschen fragen, und nicht irgendwelchen dusseligen KIs, ob es sowas wie branches des kompletten KiCADs oder auch PlugIn's gibt, die das Lösen. Es ist ja schließlich OpenSource und PlugIns kann man wohl auch jeder selber schreiben. Ich habe bei meiner Recherche eben nichts davon gelesen, dass es möglich wäre, EIN Symbol und EIN Footprint variabel auf mehr als eine Weise zu verknüpfen. Allerdings habe ich viele Leute gesehen, die genau das vorhatten und am Fluchen waren, dass es eben nicht geht. Vermutlich alles ehemalige EAGLE-Nutzer ;) Ich sträube mich auch noch etwas dagegen, 20+ mal ein N-MOSFET Symbol, 10+ mal ein P-MOSFET Symbol, 10+ mal einen Vin/Vout/GND Regler-Symbol, ... zu kopieren. Das ist so ein Haufen redundanter Daten, da stellt es mir die Nackenhaare auf ;) Ich bin aber auf die Datenbank-Bibliotheken gestoßen und das würde, wenn ich das richtig verstanden habe, mir schon viel helfen, was in Richtung Spannungsvarianten, Temperaturvarianten, Widerstandswerde, usw. geht, wenn ich das richtig verstanden habe. So kann ich mit der Tabelle das Symbol Device:R und Footprint 0805 verknüpfen und mir eine Liste mit festen Werten und Bestellnummern anlegen, ohne da hunderte Kopien von Standard Widerstand-Symbol zu erstellen. Eben alles, wo das Pinning zwischen Symbol und Footprint gleich bleibt. Vielleicht weiß da jemand was. InvenTree scheint für mich keine Lösung dafür zu sein. Dort kann ich auch nur Symbol und Footprint als solches zusammenfügen. Aber dort kann ich, soweit ich sehe, auch nicht dem einen MOSFET sagen, dass Gate an Pin 1 vom SOT23-3 Package ist und beim anderen, dass Gate Pin 2 vom SOT23-3 ist.
Michael S. schrieb: > Das ist so ein Haufen redundanter Daten, da stellt es mir die > Nackenhaare auf ;) Naja, im Vergleich zu den Datenmengen, die die 3D-Modelle benötigen, sind die paar ASCII-Zeichen für ein Transistor-Symbol doch nun wirklich "Peanuts". Mittlerweile werden außerdem abgeleitete Symbole unterstützt, also eine Art Vererbung. Wenn du dir in der Systembibliothek bspw. einen 2N2219 (bei mir der Erste in Transistor_BJT) ansiehst, dann wirst du sehen, dass sein Name kursiv dargestellt ist. Wenn du ihn in den Editor lädst, steht rechts oben ein Vermerk, dass er von Q_NPN_BNC abgeleitet ist (und die Grafik deshalb in diesem Eintrag nicht editierbar ist). Die Redundanz hält sich also arg in Grenzen. :-) (Beim Anlegen eines neuen Symbols wirst du gefragt, ob du es on einem anderen ableiten willst.) Letztlich sind es in aller Regel ohnehin nur die sehr einfachen Bauteile (wie Transistoren), die man halbwegs beliebig auf Package-Pins abbilden kann. Ich habe jahrelang mit BAE gearbeitet, welches eine explizite Zuordnungstabelle zwischen Symbol und Footprint benutzt (dort "Packager" genannt), aber schon bei AVRs in unterschiedlichen Gehäusen war oft Schluss mit lustig, und man hat doch verschiedene Schaltplansymbole gebraucht.
Angehängte Dateien:
Jörg W. schrieb: > Naja, im Vergleich zu den Datenmengen, die die 3D-Modelle benötigen, > sind die paar ASCII-Zeichen für ein Transistor-Symbol doch nun wirklich > "Peanuts" Mir geht es dabei nicht um die Datenmenge, sondern um eigentlich gleiche Teile (Symbole in diesem Fall). Wenn man sich das angehängte Bild ansieht, würden hier ja eigentlich 2 Symbole (4, wenn man unbedingt zwei separate Symbolpins für den Drain haben will) reichen. Ich meine Q_NMOS_DGS, Q_NMOS_DSG, Q_NMOS_GDS, ... ist ja die eine Sache, auch wenn man aus einem Symbol somit 6 Stück macht. Aber Q_Dual_NMOS_S1G1S2G2D2D2D1D1.... das kann doch keiner ernst meinen. Und dabei hilft Ableiten ja auch nur bedingt. In diesem Fall wohl eher unwarscheinlich, aber wenn ich nun z.B. vorhabe, dass der Gate-Anschluss nicht so aus sieht, wie ein gedrehtes T, sondern wie ein gespiegeltes L, müsste ich also nur für die im Bild gezeigten Einträge 24 Symbole ändern, anstatt nur 2-4. Irgendwie fehlt mir halt das Verständnis, wieso es eine Gute Idee, die Pad-Nummern mit im Symbol zu verknüpfen, wenn doch schon Symbol und Footprint komplett unterschiedlich gemanaged werden. Aber ich schätze jedes ECAD-Tool hat so seine Eigenheiten.
Wenn Du unbedingt möchtest, dass sich KiCad exakt so wie EAGLE 7.7 verhält, dann kannst Du doch einfach einen Fork erstellen und es genau an Deine Wünsche anpassen. Aber ich wünsche dann viel Spaß damit, den eigenen Fork so zu pflegen, dass er mit der äußersten schnellen allgemeinen KiCad-Entwicklung mithalten kann.
Michael S. schrieb: > Irgendwie fehlt mir halt das Verständnis, wieso es eine Gute Idee, die > Pad-Nummern mit im Symbol zu verknüpfen, wenn doch schon Symbol und > Footprint komplett unterschiedlich gemanaged werden. Aber ich schätze > jedes ECAD-Tool hat so seine Eigenheiten. Ich hatte an der Stelle auch so meine Schwierigkeiten beim Umstieg von Eagle. Nimm einmal einen Dual-OPA an. Im Symbol werden alle Anschlüsse den pin Nummern zugeordnet. Dann gibt es als Footprint verschiedene Gehäuse wie DIL8 oder SOIC-8, mit denselben pin-Nummern. Um jetzt den NE5532 zu platzieren, brauchst Du nur ein einziges Symbol "Dual-OPA" - und auch nur den einzigen Footprint "DIL-8" zuzuweisen. Um ein weniger universelles IC wie irgendeinen modernen Schaltregler einzupflegen, muß ich einmal ein Symbol erstellen mit den pin-Nummern, die zum Standardgehäuse der Wahl passen. Die Gehäuse mit den pinnings innerhalb der Footprint-Bibliothek sind dann universell für sämtliche Typen. Das führt zu einem eher überschaubaren Minimal-Bestand and Symbolen und Footprints.
:
Bearbeitet durch User
Michael S. schrieb: > Irgendwie fehlt mir halt das Verständnis, wieso es eine Gute Idee, die > Pad-Nummern mit im Symbol zu verknüpfen, wenn doch schon Symbol und > Footprint komplett unterschiedlich gemanaged werden. Naja, irgendeine Verknüpfung irgendwo brauchst du. Den Footprint jetzt nicht wie bspw. für ein SOT-23 1-2-3 zu benennen, ist ja auch keine gute Idee. So sind die (generischen) Footprints halt generisch, die Schaltplansymbole dann bspw. B-E-C oder eben abweichend. Alternative wäre wie bei BAE einen Layer dazwischen zu legen, der B-E-C auf 1-2-3 des Footprints abbildet. Einfacher ist das auch nicht. Du hast natürlich Recht, die "Vererbung" funktioniert nicht für verschiedene Pinouts. Sie ist dafür gut, dass man verschiedene Metadaten hinterlegen kann (bspw. Datenblätter).
Andreas S. schrieb: > Wenn Du unbedingt möchtest, dass sich KiCad exakt so wie EAGLE 7.7 > verhält, dann kannst Du doch einfach einen Fork erstellen und es genau > an Deine Wünsche anpassen. Natürlich werde ich das nicht machen, allein schon, weil ich es nicht kann ;) Ich würde bloß gerne die Intention verstehen. Ich fand das bei EAGLE schon ganz praktisch. Eine Bibliothek, wo man seine generischen Symbole und generischen Footprints reinlegen kann und dann über Devices die jeweilige Verknüpfung herstellt. Der Nachteil bei EAGLE ist halt, dass du dann in der Bibliothek für Dioden, für Transistoren, Spannungsregler usw. immer eine Kopie z.B. vom SOT23-3 haben musst. KiCAD bricht diese Organisierung auf, was ich mir bei EAGLE auch schon öfter gewünscht habe. Aber macht diesen Vorteil dann gleich wieder "kaputt", in dem es die Verknüpfung zum Footprint mit ins Symbol holt, wo es meiner Auffassung nach nicht hingehört. Ebenso wie Bestellnummern oder sonst was. Das hat ja erstmal nichts mit dem Symbol zutun. In meiner Vorstellung wäre also das Ideal eine Mischung von dem "EAGLE-Weg" und dem "KiCAD-Weg". Symbol-Libs zum Anlegen und Organisieren von Symbolen (Passive Bauteile, DACs, Transistoren, ...), dann Footprint-Libs für eben Footprints (DIP ICs, SMD ICs, Trafos, das ganze 0201, 0402, .. Gedöns, ...) und zusätzlich dann Part-Listen oder eben Datenbanken, die Symbol(e) mit Footprints verlinken, Bestell-/Lager-/Preis-Informationen beinhalten, Designator, Datenblatt-Links, Herstellerbezeichnung, usw. Eben alles, was spezifisch für ein Bauteil ist. Ich persönlich sehe darin nur Vorteile gegenüber beiden Tools und es ist durchaus ernst gemeint, wenn ich sage, dass ich gerne die Philosophie hinter dem "KiCAD-Weg" verstehen würde. Ich meine, hinter der Entwicklung von KiCAD sitzen ja keine Leute, die von der Materie keine Ahnung haben. Ergo suche ich erstmal den "Fehler" bei mir bzw. gehe davon aus, dass ich da was nicht verstehe. Das würde ich gerne ändern ;)
Michael S. schrieb: > Ich habe mal reingeguckt und es ist so, wie ich es bisher auch > verstanden habe. Es gibt für jede einzelne Variante ein eigenes Symbol. > Das macht die Liste in den jeweiligen Bibliotheken natürlich elend lang. > Aber durch die Suchfunktion kommt man da schon ans Ziel und mit dem > "Symbol ableiten von" kann man sich scheinbar ein bisschen Arbeit beim > erstellen der ganzen Varianten sparen. Ich meine das geht über > Spannungsregler ja hinaus. Microcontroller mit verschiedenen > Speichergrößen und Temperaturbereichen, teilweise Spannungsbereichen > aber immer gleichem Pinning. KiCad arbeitet halt grundlegend anders als Eagle. KiCad trennt halt recht strikt zwischen Symbol und Footprint. Im Schaltplaneditor benutzt Du halt Symbole, die mit dem realen Bauelement (das z.B. immer einen Footprint hat) erst mal nichts zu tun hat. Die Footprints mußt selbst zuweisen. In der Version 10, mit der ich gerade mal etwas gespielt habe, zieht man die konsequente Trennung von Symbol und Footprint offenbar nicht mehr konsequent durch. Da ist mir zumindest bei Transistoren und Dioden aufgefallen, das da schon Footprints zugewiesen werden, zumindest dann wenn es den gewählten Typ in nur einer Bauform gibt. Bei allen anderen Bauelementen Symbolen mußt Du den Footprint selbst zuweisen, bevor Du die Netzliste exportierst damit Du dann mit selbiger das PCB zeichnen kannst. Tust Du das nicht dann wird Dir beim Import der Netzliste ein Fehler angezeigt und das Bauelement erscheint (logischerweise) auch nicht im PCB Editor. Konkrete Bauelemente (bei Eagle Devices) die aus einem Schaltplansymbol und einem Footprint kennt halt KiCad nicht. In der Zuweisung bist Du auch völlig frei. Du kannst völlig problemlos einem Transistor den Footprint einer Röhre oder eines Widerstandes zuweisen. KiCad meckert das nicht an, es verbindet einfach die Pinnummern des Symbols mit den Pinnummern des Footprints. Interessant wird es wenn der Footprint weniger Anschlüsse als das Symbol hat, dann werden die betreffenden Netze einfach nicht in den PCB-Editor übertragen. Das ist zwar erst mal logisch, besser wäre es wenn man eine solche Zuordnung im Schaltplaneditor nicht zulassen würde oder zumindest eine Warnung ausgeben würde. Wenn Du von Eagle kommst dann wirst Du vermutlich die Forward-/Backwardannotation missen. Das kennt KiCad halt nicht. Mich persönlich würde das sehr stören, aber das sieht halt jeder anders. Du kannst im PCB bei KiCad auch nach Belieben Bauelemente (Footprints) komplett löschen. Daran muß man sich als Eaglenutzer auch erst mal gewöhnen, denn da geht das nicht, da kann man die Footprints lediglich austauschen. Es gibt noch eine Sache die ich in KiCad nicht besonders schön finde. Wenn man im PCB die Bauelemente verschiebt, dann reißen die Leiterzüge vom Bauelement ab. Auf die Idee das man das Bauelement markieren und die Taste "d" drücken muß damit das nicht passiert muß man auch erst mal kommen. Man muß sich halt auf das Progamm einlassen und an den komplett anderen Workflow gewöhnen. Wer die steile Lernkurve in Kauf nimmt bekommt vermutlich ein recht mächtiges Werkzeug und das Ganze zum Nulltarif. Ich persönlich kann mich mit dem Programm nicht wirklich anfreunden und werde wohl bei Eagle bleiben, das für meine privaten Zwecke völlig ausreichend ist.
Hans schrieb: > Wenn Du von Eagle kommst dann wirst Du vermutlich die > Forward-/Backwardannotation missen. Das kennt KiCad halt nicht. Inzwischen sollte doch Pin-/Gate-Swap gehen, oder? Damit auch eine Backannotation. Der Kicad-Workflow scheint an vielen Stellen von Altium inspiriert zu sein. Wundert auch nicht so sehr, wenn man bedenkt, dass CERN Altium durch Kicad abgelöst hat (wenngleich manche Teile gegenüber Altium einfacher gestrickt sind).
Michael S. schrieb: > Ich habe bei meiner > Recherche eben nichts davon gelesen, dass es möglich wäre, EIN Symbol > und EIN Footprint variabel auf mehr als eine Weise zu verknüpfen. Man hat 2 Möglichkeiten. Man legt ein Symbol mit konkreten Bauteilnamen an und verknüpft es mit dem passenden Footprint. Einmal alles komplett geprüft, passt, fertig. Oder man legt bzw. benennt ein generisches Symbol an und macht die Footprintzuweisung nicht im Symboleditor, sondern immer erst im Schaltplan. Man muss nur jedesmal sicherstellen, dass die Pinzuordnung auch wirklich passt. Also wenn man sehr oft immer die gleichen Bauteile verwendet, die unterschiedliche Pinbelegungen haben können, macht ein Anlegen aller mit Symbol und zugehörigen Footprint schon Sinn. Sonst passt irgendwann die Leiterplatte nicht zum Bauteil.
Jörg W. schrieb: > Der Kicad-Workflow scheint an vielen Stellen von Altium inspiriert zu > sein. Wundert auch nicht so sehr, wenn man bedenkt, dass CERN Altium > durch Kicad abgelöst hat (wenngleich manche Teile gegenüber Altium > einfacher gestrickt sind). Ich würde sagen, dass die reine Bedienung für das gleiche Ziel einfacher ist. Und das ist genau der Unterschied. Altium ist im Grunde mit den Tausenden Untermenüs total verkorkst und kaum bedienbar. Man kann etwas bedienbar gestalten und man kann es total verkomplizieren - für das gleiche Ziel. Wenn Altium die Menüs aufräumen würde ...
Jörg W. schrieb: > Hans schrieb: >> Wenn Du von Eagle kommst dann wirst Du vermutlich die >> Forward-/Backwardannotation missen. Das kennt KiCad halt nicht. > > Inzwischen sollte doch Pin-/Gate-Swap gehen, oder? Damit auch eine > Backannotation. In Eagle geht das definitiv. Ob das in KiCad auch funktioniert kann ich nicht beurteilen, weil ich es nicht benutze. Ich habe mir lediglich mal die 10'er Version herunter geladen und damit mal das eine oder andere probiert, allerdings konnte ich mich nicht wirklich für das Programm erwärmen. Das ist auch nicht weiter schlimm, es war halt wieder mal ein Versuch, um zu prüfen ob es für mich funktioniert. Ergebnis ist halt das ich vorerst bei Eagle bleiben werde.
Veit D. schrieb: > Altium ist im Grunde mit den Tausenden Untermenüs total verkorkst und > kaum bedienbar. Darum ging's mir nicht. In Altium hast du oft ein paar Zwischenschritte mehr. Das ist zwar umständlicher, aber beim Übernehmen der Änderungen aus dem Schaltplan ins PCB kannst du beispielsweise explizit auswählen oder abwählen, was du jetzt haben möchtest, statt gleich alles auf einmal en bloc reinzuziehen. Das war, was ich hier meinte – Workflow in vielerlei Hinsicht ähnlich (und eben grundlegend anders als Eagle), aber manchmal einfacher (als Altium). Dass die Altium-Shortcuts alle zwei Zeichen haben, ist 'ne andere Sache, aber so viel, wie inzwischen in Kicad an Funktionalität drin ist, wären 2-Zeichen-Shortcuts dort mittlerweile auch gar nicht so schlecht. Hans schrieb: >> Inzwischen sollte doch Pin-/Gate-Swap gehen, oder? Damit auch eine >> Backannotation. > > In Eagle geht das definitiv. Es ging mir aber eben um Kicad und deine Behauptung, es gäbe dort keine forward/backward annotation. Forward annotation ist ja im Prinzip schon mal der normale Workflow: ich ändere etwas im Schaltplan, und lass es danach ins PCB übernehmen. Backward annotation funktioniert zumindest dahingehend (und das nicht erst seit V10), dass ich im PCB eine Bauteilreferenz ändern kann und diese Änderung hinterher in den Schaltplan zurück übernehme, eben ausprobiert. In V10 sollte auch ein unconstrained pin swap gehen, aber irgendwie gibt es bei mir diesen Menüpunkt nicht. https://gitlab.com/kicad/code/kicad/-/merge_requests/2306 Was es nicht gibt ist irgendein Automatismus, bei dem die Änderungen sofort und ohne Mitwirkung des Benutzers zwischen beiden Seiten synchronisiert werden.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Es ging mir aber eben um Kicad und deine Behauptung, es gäbe dort keine > forward/backward annotation. Unter forward/backward annotation verstehe ich eigentlich, daß Änderungen im Schematic auch sofort im PCB ankommen, ohne daß ich erst die Netlist exportieren bzw. importieren muß. Bei meinen Versuchen mußte ich da immer die Netlist bemühen. Forward/Backward Annotation bedeutet auch, daß Schaltplan und PCB immer konsistent sind. Bei KiCad ist das nicht unbedingt gegeben. Wenn ich im Schematic ein Bauelement lösche, dann sollte dies auch im PCB (der zugehörige Footprint) gelöscht werden - wird es aber nicht. Ebenso müßte umgekehrt auch das Löschen eines Footprints im PCB das zugehörige Bauelement im Schematic löschen. Tut es aber nicht. Damit sind Schematic und PCB eben nicht mehr konsistent. Letzteres, also das Löschen eines Footprints ist im PCB-Editor von Eagle nicht möglich, weil das ja am Ende auch eine Änderung des Schaltungsdesigns hinausläuft. Einen anderen Footprint zuweisen, sofern es für das Bauelement mehrere gibt, ist hingegen problemlos möglich. So Sachen wie Bauelemente oder auch Verbindungen löschen ist halt nur im Schematic möglich und das wird dann auch sofort im PCB wirksam. Jörg W. schrieb: > Forward annotation ist ja im Prinzip schon mal der normale Workflow: ich > ändere etwas im Schaltplan, und lass es danach ins PCB übernehmen. Das ist ja der Knackpunkt, Du läßt es übernehmen. Mit anderen Worten Du mußt den Prozeß erst mal anstoßen. Eagle macht das völlig automatisch. Jörg W. schrieb: > Backward annotation funktioniert zumindest dahingehend (und das nicht > erst seit V10), dass ich im PCB eine Bauteilreferenz ändern kann und > diese Änderung hinterher in den Schaltplan zurück übernehme, eben > ausprobiert. dto. Jörg W. schrieb: > Was es nicht gibt ist irgendein Automatismus, bei dem die Änderungen > sofort und ohne Mitwirkung des Benutzers zwischen beiden Seiten > synchronisiert werden. Dieser Automatismus ist aber genau das Entscheidente, denn der sorgt dafür daß Schematic und PCB immer zusammen passen. Wenn Du z.B. im Schematic was änderst und dann Deine Arbeit erst mal beendest ohne die Änderungen ins PCB zu übertragen, dann hast Du beim nächsten Öffnen des Projektes einen Schaltplan und ein PCB die nicht zusammenpassen und Du bekommst das Ganze noch nicht einmal mit, weil es auch keinen Warnhinweis gibt.
:
Bearbeitet durch User
Hans schrieb: > Unter forward/backward annotation verstehe ich eigentlich, daß > Änderungen im Schematic auch sofort im PCB ankommen, ohne daß ich erst > die Netlist exportieren bzw. importieren muß. Bei meinen Versuchen mußte > ich da immer die Netlist bemühen. Das ist schon sehr viele Versionen her. Nur das mit dem "sofort" ist eine ausgesprochene Eagle-Eigenheit, die halt sonst niemand macht. > Forward/Backward Annotation bedeutet auch, daß Schaltplan und PCB immer > konsistent sind. Wie geschrieben, das macht nur Eagle so. In allen anderen EDA-Systemen braucht die Synchronisation eine bewusste Entscheidung des Bedieners. > Wenn Du z.B. im > Schematic was änderst und dann Deine Arbeit erst mal beendest ohne die > Änderungen ins PCB zu übertragen, dann hast Du beim nächsten Öffnen des > Projektes einen Schaltplan und ein PCB die nicht zusammenpassen und Du > bekommst das Ganze noch nicht einmal mit, weil es auch keinen > Warnhinweis gibt. Der Warnhinweis heißt "DRC". Dort steht dann klar und deutlich, was du noch nicht hast, und auch, ob die beiden auseinander gelaufen sind. Dort steht auch sonst eine ganze Menge mehr. ;-) Dass man am Ende immer einen DRC macht (trotz online DRC), das lernt man spätestens beim ersten groben Schnitzer. :-) Bei mir war das ein von einem externen Dienstleister importiertes Board in Altium, wobei der Dienstleister eine andere Version benutzt hatte als ich. Ich hatte "nur schnell noch" eine USB-Buchse ein wenig verschoben. Auf der gefertigten Platine fehlte dann die Hälfte der GND-Anbindungen … (War ein Versionsproblem zwischen beiden Altiumversionen und der Art und Weise, wie sie auf der Innenlage die GND-Pins angebunden haben, diagonal vs. horizontal/verktikal.)
Hans schrieb: > Dieser Automatismus ist aber genau das Entscheidente, denn der sorgt > dafür daß Schematic und PCB immer zusammen passen. Wenn Du z.B. im > Schematic was änderst und dann Deine Arbeit erst mal beendest ohne die > Änderungen ins PCB zu übertragen, dann hast Du beim nächsten Öffnen des > Projektes einen Schaltplan und ein PCB die nicht zusammenpassen und Du > bekommst das Ganze noch nicht einmal mit, weil es auch keinen > Warnhinweis gibt. Das stimmt. Auf der anderen Seite kann man sich die Forward/Backward Annotation auch nicht zerschießen und muss dann irgendwie frickeln, um es wieder konsistent zu bekommen ;) Jörg W. schrieb: > In V10 sollte auch ein unconstrained pin swap gehen, aber irgendwie gibt > es bei mir diesen Menüpunkt nicht. Mit KiCAD 10.0.1 habe ich schon Pins geswappt ;) du musst die beiden Pins markieren und dann Rechtsklick -> Pins tauschen. Im Schaltplan musste ich Länger suchen, bis ich die Funktion "Änderungen aus Platine in den Schaltplan übertragen" gefunden habe^^ Hans schrieb: > In der Zuweisung bist Du auch völlig frei. Du kannst völlig problemlos > einem Transistor den Footprint einer Röhre oder eines Widerstandes > zuweisen. KiCad meckert das nicht an, es verbindet einfach die > Pinnummern des Symbols mit den Pinnummern des Footprints Naja, völlig frei ja leider nicht. Ich kann einem Transistor unnützer Weise das Footprint eines Kippschalters zuweisen, aber das sinnvolle Pad-Zuweisen eines tatsächlichen Packages für Transistoren geht nur fix. Aber ich denke ich wiederhole mich. Ich fänd es cool, wenn es so geregelt wäre wie in meinem letzten Beitrag. Dass es sowas via PlugIn nicht gibt habe ich mir auch schon gedacht.
Hans schrieb: > Jörg W. schrieb: >> Hans schrieb: >>> Wenn Du von Eagle kommst dann wirst Du vermutlich die >>> Forward-/Backwardannotation missen. Das kennt KiCad halt nicht. >> >> Inzwischen sollte doch Pin-/Gate-Swap gehen, oder? Damit auch eine >> Backannotation. > In Eagle geht das definitiv. Seit wann? Bis 7.7 geht Gate Swap nur im Schaltplan und nicht im Board, wo man es braucht. Und Pin Swap funktioniert nur halb, weil nicht die Pin-Nummern vertauscht werden, sondern die Verbindungen im Schaltbild anschließend gekreuzt sind. An der Stelle spart mir die Eagle-Automatik garnichts. Oder geht das doch irgendwie?
Ein Pinswap muss doch die Netze tauschen. Pin 3 bleibt an einem IC doch immer an der selben Stelle, auch nach einem Swap. Und da die Netze getauscht sind, sind natürlich auch die Leitungen gekreuzt. Man könnte höchstens sagen, dass wenn an den zu tauschenden Pins jeweils ein Fähnchen hängt, dass dann die Netze einfach umbenannt werden und keine Kreuzung entstehen muss.. aber naja. Das hat mich nie wirklich gestört. Gate swap geht nur im Schaltplan. Wie es bei der aktuellsten Version aussieht, weiß ich nicht.
Michael S. schrieb: >> In V10 sollte auch ein unconstrained pin swap gehen, aber irgendwie gibt >> es bei mir diesen Menüpunkt nicht. > > Mit KiCAD 10.0.1 habe ich schon Pins geswappt ;) du musst die beiden > Pins markieren und dann Rechtsklick -> Pins tauschen. Hatte jetzt bei 10.0.1 auch geklappt. Vorher hatte ich es nicht gefunden – vielleicht hatte ich bei meinem Test die beiden zu tauschenden Pins nicht richtig markiert. > Im Schaltplan > musste ich Länger suchen, bis ich die Funktion "Änderungen aus Platine > in den Schaltplan übertragen" gefunden habe^^ Fand ich jetzt auch seltsam, ich glaube, früher (so ein, zwei Versionen zuvor) war das direkt unter "Update PCB from schematics" ziemlich weit oben. Vielleicht haben Leute die beiden Funktionen zu oft verwechselt – Schaltplan nach PCB ist ja regulärer Workflow, während die Backanno eher selten nötig ist. > Aber ich denke ich wiederhole mich. Ich fänd es cool, wenn es so > geregelt wäre wie in meinem letzten Beitrag. Das würde vermutlich einen kompletten Umbau des Gesamtsystems bedeuten. So, wie der Schaltplan halt immer das Primat für alle wesentlichen Änderungen an der Schaltung hat, so ist die Kategorie "Symbol" mittlerweile mehr oder weniger zu "Bauteil, komplett" verschoben worden. Daher eben auch Meta-Informationen dort wie Datenblatt oder Lieferanten-Information. Dein Vorschlag würde bedeuten, dass man die Kategorie "Symbol" als reines Schaltplansymbol hat und dann parallel eine Kategorie "Bauteil", die Symbol, Footprint und Pin-Zuordnung definiert. Wie schon geschrieben, wäre ein kompletter Umbau, für meines Erachtens vergleichsweise wenig Gewinn: es gibt ja nur wenige generische Bauteile (die sich das gleiche Schaltplansymbol teilen) mit mehr als 2 (vertauschbaren) Pins, die davon profitieren würden. Für Bauteile mit 2 vertauschbaren Pins (Widerstände, Kondensatoren) braucht man das nicht, da muss man einfach nur einen Footprint zuordnen. Für komplexere Bauteile müsste man dann jeweils ein Schaltplansymbol erzeugen und anschließend auch noch das Bauteil mit seinen Pinzuordnungen machen.
Michael S. schrieb: > Ein Pinswap muss doch die Netze tauschen. Pin 3 bleibt an einem IC doch > immer an der selben Stelle, auch nach einem Swap. Das ist eben der Fehler, er muss die Pins tauschen. Bei zwei völlig gleichwertigen Pins müssten nur die Nummern vertauscht werden (ansonsten dürften sie garnicht geswapt werden). > Man könnte höchstens sagen, dass wenn an den zu tauschenden Pins > jeweils ein Fähnchen hängt, dass dann die Netze einfach umbenannt > werden und keine Kreuzung entstehen muss.. aber naja. Aber ganz viel naja, das geht ja mal garnicht. Jörg W. schrieb: > So, wie der Schaltplan halt immer das Primat für alle wesentlichen > Änderungen an der Schaltung hat, so ist die Kategorie "Symbol" > mittlerweile mehr oder weniger zu "Bauteil, komplett" verschoben worden. Der Unterschied zu Eagle ist eigentlich nur der Begriff: Device statt Symbol. Immerhin kann man Varianten wie unterschiedliche Spannungen oder Temperaturbereiche unter einem Symbol zusammenfassen. Der Rest sind Feinheiten, vor allem, wie einfach kann der Benutzer ein Schaltzeichen mehrfach verwenden. > Daher eben auch Meta-Informationen dort wie Datenblatt oder > Lieferanten-Information. Datenblatt und Hersteller natürlich; Lieferant und Bestellnummer sollten außerhalb gespeichert werden. Lieferanten ändern sich oft und vor allen lange nach Freigabe der Platine. Für einen neuen Lieferanten will ich das Symbol nicht updaten - das wäre ja eine Revision der Platine. Ja, formal ist es das auch, aber manchmal kann man das vielleicht vermeiden.
Bauform B. schrieb: > Lieferant und Bestellnummer sollten außerhalb gespeichert werden. Dann brauchst du halt einen Link auf den entsprechenden Datenbankeintrag als Meta-Information.
Da dies hier sich langsam in eine Grundsatzdiskussion über die Architektur von EDA Software entwickelt, erlaube ich mir nach langem Mitlesen auch mal einen Kommentar einzuwerfen. Als Gründer von LibrePCB (https://librepcb.org/) habe ich mir all die möglichen Lösungsansätze für Bauteilbibliotheken und Forward/Backward Annotation vor vielen Jahren auch gemacht, also genau all die Punkte welche hier diskutiert werden. Herausgekommen ist schliesslich ein Konzept das im Grunde sehr ähnlich ist wie Eagle. Aus meiner Sicht hat der Ansatz von Eagle ganz klare Vorteile gegenüber dem KiCad Ansatz. Insbesondere was die Wiederverwendbarkeit von Bibliothekselementen und die Fehleranfälligkeit bzgl. falschen Pinouts betrifft. Aber auch Eagle hat Schwächen - diese bin ich bei LibrePCB gezielt angegangen und das Konzept entsprechend weiterentwickelt. Ich denke es würde hier den Rahmen sprengen, alle Unterschiede/Vorteile/Nachteile zu erläutern (bzw. ich vermute, es ist hier sowieso nicht erwünscht). Falls doch erwünscht, kann ich das aber gerne machen. Für die technisch Interessierten, gibt es hier ein paar detaillierte Informationen zur LibrePCB Architektur: - Vorstellung des Konzeptes, Vergleich mit Eagle & KiCad: https://archive.fosdem.org/2018/schedule/event/cad_librepcb/ - Architektur Diagramme: https://developers.librepcb.org/df/d4f/doc_library.html - Ein paar High-Level Vorteile: https://librepcb.org/features/library-concept/ Jörg W. schrieb: > Nur das mit dem "sofort" ist eine ausgesprochene Eagle-Eigenheit, die > halt sonst niemand macht. > >> Forward/Backward Annotation bedeutet auch, daß Schaltplan und PCB immer >> konsistent sind. > > Wie geschrieben, das macht nur Eagle so. In allen anderen EDA-Systemen > braucht die Synchronisation eine bewusste Entscheidung des Bedieners. LibrePCB macht es auch so. Jede Änderung am Schaltplan wird sofort und automatisch auch aufs Board angewendet. Und im Gegensatz zu Eagle ist es nicht möglich, jemals in einen inkonsistenten Zustand zu kommen - auch wenn das Board nicht geöffnet ist während man den Schaltplan editiert, wird es im Hintergrund aktuell gehalten. Es ist auch geplant, in Zukunft eine Backward-Annotation einzuführen, also dass man (optional) auch im Board Änderungen vornehmen kann welche automatisch auf den Schaltplan übernommen werden (z.B. für Reverse-Engineering von PCBs). Hierzu muss ich aber sagen, dass ich nicht das eine Konzept besser finde als das andere. Beide Varianten (automatische Forward/Backward Annotation wie Eagle/LibrePCB, und manuelle Forward/Backward Annotation wie KiCad/Altium) haben ihre Vor- und Nachteile. Es ist aus meiner Sicht eine persönliche Geschmacksfrage, mit welchem Konzept man arbeiten möchte.
Urban schrieb: >> Wie geschrieben, das macht nur Eagle so. In allen anderen EDA-Systemen >> braucht die Synchronisation eine bewusste Entscheidung des Bedieners. > > LibrePCB macht es auch so. OK, da du versuchst, den Eagle-Workflow genau so abzubilden, ist das jetzt nicht verwunderlich. Aber ich gebe zu: von LibrePCB hatte ich schon mal gehört, das aber nicht mehr auf dem Schirm. Wäre eh nicht meine Arbeitsweise. Als ich vor Jahrzehnten noch mit Eagle gearbeitet habe, hat es mich eher gestört als dass ich es nützlich fand. Aber das ist ganz sicher persönliche Geschmackssache.
Jörg W. schrieb: > Wie geschrieben, das macht nur Eagle so. In allen anderen EDA-Systemen > braucht die Synchronisation eine bewusste Entscheidung des Bedieners. Nö, ist kein Alleinstellungsmerkmal von Eagle, Pulsonix mach das auch genau so und Target 3000 macht es meines Wissens auch. Michael S. schrieb: > Das stimmt. Auf der anderen Seite kann man sich die Forward/Backward > Annotation auch nicht zerschießen und muss dann irgendwie frickeln, um > es wieder konsistent zu bekommen ;) Da gebe ich Dir recht, wenn sich das zerschossen hat, weil man das PCB oder Schematic Fenster geschlossen hat. Allerdings wird man im noch offenen Fenster sehr eindringlich gewarnt, daß man die F/B-Annotation unterbrochen hat. Das ignoriert man nur einmal. Wenn es doch passiert, kann man mit Hilfe der Sicherungskopien, die beim Speichern automatisch angelegt werden, bis zu einem konsistenten Zustand zurück gehen und ab da noch mal beginnen. Das hat sich zumindest bei mir als der einzige brauchbare Weg erwiesen. Bauform B. schrieb: > Seit wann? Bis 7.7 geht Gate Swap nur im Schaltplan und nicht im Board, > wo man es braucht. Logisch daß das nur im Schematic geht, weil es halt den Schaltplan ändert und der ist, so wie in KiCad auch, das Primäre. Bauform B. schrieb: > Und Pin Swap funktioniert nur halb, weil nicht die > Pin-Nummern vertauscht werden, sondern die Verbindungen im Schaltbild > anschließend gekreuzt sind. dto. Überlege mal warum die gekreuzt sind und warum man am Ende ein Pinswap macht. Du hast aber insofern recht es wäre gut wenn er hier die Verbindungen im Schematic gleich selbst korrigieren würde, notfalls nach Rückfrage. Bauform B. schrieb: > Michael S. schrieb: >> Ein Pinswap muss doch die Netze tauschen. Pin 3 bleibt an einem IC doch >> immer an der selben Stelle, auch nach einem Swap. > > Das ist eben der Fehler, er muss die Pins tauschen. Bei zwei völlig Nö der Michael hat hier recht. Nochmal die Frage: Warum mache ich ein Pinswap? Das mache ich, wenn ich beim Routen feststelle, daß ich mit dem Tauschen der Pins eine günstigere Leitungsführung erreiche. Damit ändere ich halt auch die Zuweisung der Netze. Zwischen den Pins im Symbol und den Pins im Footprint ist Zuordnung fest, es gibt da halt keine Bauform B :-). Bauform B. schrieb: > Jörg W. schrieb: >> So, wie der Schaltplan halt immer das Primat für alle wesentlichen >> Änderungen an der Schaltung hat, so ist die Kategorie "Symbol" >> mittlerweile mehr oder weniger zu "Bauteil, komplett" verschoben worden. > > Der Unterschied zu Eagle ist eigentlich nur der Begriff: Device statt > Symbol. Nein, Device steht bei Eagle eben nicht für ein Symbol. Ein Device ist i.d.R. die Kombination aus einem Symbol und mindestens einem Footprint. Es gibt allerdings eine Ausnahme wo der Footprint im Device fehlen darf. Das ist dann der Fall, wenn allen Signalen (Pins) des Symbols die Signalrichtung "pas" zugewiesen wird. Urban schrieb: > Herausgekommen ist schliesslich ein Konzept das im Grunde sehr ähnlich > ist wie Eagle. Aus meiner Sicht hat der Ansatz von Eagle ganz klare > Vorteile gegenüber dem KiCad Ansatz. Insbesondere was die > Wiederverwendbarkeit von Bibliothekselementen und die Fehleranfälligkeit > bzgl. falschen Pinouts betrifft. Das sehe ich ähnlich. Urban schrieb: > Aber auch Eagle hat Schwächen Das ist völlig unstrittig. Wo Licht ist ist auch Schatten. Urban schrieb: > Und im Gegensatz zu Eagle ist es > nicht möglich, jemals in einen inkonsistenten Zustand zu kommen - auch > wenn das Board nicht geöffnet ist während man den Schaltplan editiert, > wird es im Hintergrund aktuell gehalten. Da kann ich nur sagen 👍 Urban schrieb: > Es ist aus meiner Sicht > eine persönliche Geschmacksfrage, mit welchem Konzept man arbeiten > möchte. 👍
Hans schrieb: >> Der Unterschied zu Eagle ist eigentlich nur der Begriff: Device statt >> Symbol. > > Nein, Device steht bei Eagle eben nicht für ein Symbol. Ein Device ist > i.d.R. die Kombination aus einem Symbol und mindestens einem Footprint. Ist aber jetzt ein Streit um des Kaisers Bart, ab wann man das nun als "Device" bezeichnen darf. Ohne Footprint ist es halt sowas wie ein "abstraktes Device", man kann ja trotzdem erstmal einen (generischen) Schaltplan damit zeichnen. Hilfreich, wenn man vielleicht gar kein PCB machen will, der Schaltplan nur Doku ist.
Jörg W. schrieb: > Ist aber jetzt ein Streit um des Kaisers Bart, ab wann man das nun als > "Device" bezeichnen darf. Würde ich jetzt so nicht sehen. Ein Device ist schon deutlich mehr als ein Symbol. Neben dem Footprint kann ich dort auch noch andere Dinge hinterlegen, wie z.B. eine Beschreibung. Auch wie das Ganze dann im SChaltplan bezeichnet wird ist im Device hinterlegt. Zudem können in einem Device auch mehrere Symbole bzw. Symbole mehrfach hinterlegt sein. Beispiel 7400, da ist das NAND-Gatter 4x enthalten und zusätzlich noch die Symbole für die Versorgungsanschlüsse. Streiten möchte ich hier definitv nicht, aber es sollte schon ein bischen korrekt sein. Jörg W. schrieb: > Hilfreich, wenn man vielleicht gar kein PCB > machen will, der Schaltplan nur Doku ist. So ist es, beispielsweise wenn man einen Plan für seine Elektroinstallation machen will.
:
Bearbeitet durch User
Jörg W. schrieb: > Wie schon geschrieben, wäre ein kompletter Umbau, für meines Erachtens > vergleichsweise wenig Gewinn: es gibt ja nur wenige generische Bauteile > (die sich das gleiche Schaltplansymbol teilen) mit mehr als 2 > (vertauschbaren) Pins, die davon profitieren würden Ich persönlich finde das momentan das größte Hindernis/Kritikpunkt an KiCAD. Das betrifft schon Recht viele Bauteile. Die verschiedenen Transistoren (z.B. NPN/PNP bipolar, N/P-MOSFET, N/P-JFET, Darlington, IGBT) sind 8 Symbole aber damit auch insgesamt 48 Pinkombination, wenn man nur Footprints mit 3 Pads berücksichtigt. Es gibt aber auch nicht selten SO8 oder PowerSO8 mit wer weiß wie viel Kombinationen. Dann noch Dioden, Z-Dioden, TVS... Wenn man dann noch rudimentäre Bauteile wie LDOs oder so sieht, kommt man sicherlich auf einige Zehn Symbole, die durch das fixe Pinning aber auf mehrere Hundert Kopien dieser paar Symbole hinauslaufen. Gerade bei diesen generischen Bauteilen würde es sich lohnen. Für uCs ist es auch manchmal hilfreich, wenn die selben Pins in einem SOIC als auch QFN vorhanden sind. Aber da ist das "Kopie-Einsparpotential" nicht so sonderlich hoch.
Bauform B. schrieb: > Das ist eben der Fehler, er muss die Pins tauschen. Bei zwei völlig > gleichwertigen Pins müssten nur die Nummern vertauscht werden (ansonsten > dürften sie garnicht geswapt werden). Ich glaube ich verstehe das nicht so ganz. Wenn man Pin1 und Pin2 tauscht. Dann tauscht man doch die Netze. Weder ändert sich die Funktion hinter Pin1 (z.B. UART1_RX), noch wandert der Pin1 Marker auf dem Chip eine Position weiter. Ergo kann man die Pins nicht direkt tauschen. Lediglich die Netze, die an den Pins angeschlossen sind.
Michael S. schrieb: > Gerade bei diesen generischen Bauteilen würde es sich lohnen. Inwiefern "lohnt" es sich? Also was konkret wird eingespart? Die paar ASCII-Zeichen für die Kopien machen das Kraut ja nun wirklich nicht fett (vor allem nicht, wenn man die Größe der 3D-Modelle dagegen stellt). Ein wenig mehr Übersicht wäre meiner Meinung nach so ziemlich der einzige wirkliche Vorteil. Dafür wäre der Umbauaufwand meiner Schätzung nach immens, zumal er völlig inkompatibel wäre, d.h. bei einem Versionssprung müssten nicht nur die Systembibliotheken alle umgebaut werden, sondern auch alle privaten Bibliotheken der Nutzer konvertiert werden, denn du musst ja für die Trennung von "Device" und "Symbol" überall eine Schicht dazwischen legen. Meinst du immer noch, dass sich das in irgendeiner Form lohnt?
Jörg W. schrieb: > Inwiefern "lohnt" es sich? Also was konkret wird eingespart? Es wird eingespart, dass es hunderte Symbol-Kopien von immer selben Bauteilen gibt. Wie oben schon das Beispiel: wenn es mich nervt, dass das Gate bei MOSFETs mittig nach außen geführt ist, muss ich sehr viele Symbole anpassen. Ich würde schätzen, es sind mehr als 50 nicht abgeleitete Symbole. Wenn ich einen neuen Transistor anlegen will, der in einem nicht so gängigen Gehäuse kommt, muss ich wieder ein neues Symbol anlegen. Oder die vorhandenen hunderten Symbole durchgucken, wo zufällig die Pinzuweisung passt. Wäre es getrennt, lege ich mir ein neues Footprint an und nutze das vorhandene MOSFET Symbol. Oder wenn es mich bei EAGLE nerven würde, dass das Gate nicht mittig rausgeführt ist, könnte ich ein Symbol anpassen und hätte die Änderungen bei allen Transistoren, die dieses Symbol nutzen. Die Ersparnis ist nicht Datenmengen auf der Festplatte gemeint. Es wird sich nicht lohnen, KiCAD komplett umzuschreiben. Das habe ich ja auch nicht gefordert. Ich war nur neugierig, ob es nicht bereits irgendwie geht. Wie es fälschlicherweise Gemini mir erklärt hat. Ein Datenbank-Eintrag legt ja auch für KiCAD ein neues Symbol an. Nur ist das wohl eher wie, als würde man ein vorhandenes (das angegeben) Symbol ableiten. Und nicht kopieren und die Pin/Pad Zuordnung "manipulieren". Wie viel Aufwand das wäre einzubauen, habe ich keine Ahnung.
> Gate bei MOSFETs mittig nach außen geführt ist, muss ich sehr viele > Symbole anpassen. Naja, eigentlich musst du es nur einmal so zeichnen wie es dir passt, dann für die MOSFETs die du auf der Platine hast mit den Footprints verknüpfen und in deine eigenen Lib legen. So eine Aktion einmal pro verwendetes Bauteil, das muss man in Kauf nehmen beim Platine erstellen. Abgleitete Schaltplansymbole gibt es ja seit Version 10. (was mich erstmal Zeit gekostet hat rauszufinden warum ich das in meine private Lib kopierte Bauteil nicht editieren kann...) > Oder die vorhandenen hunderten Symbole durchgucken, wo > zufällig die Pinzuweisung passt. Das fand ich bei Eagle besser: da war es einfach die Symbole durch zu suchen welchen schon 100% oder zumindest so ungefähr passt, und die die Footprints hat man dabei auch schon gesehen, und konnte einen kopieren welcher auch entweder zu 100% oder zumindest so ungefähr gepasst hat. Bei KiCAD funktioniert das nur mit den Schaltplansymbolen, bei den Footprints hab ich keine so schöne Methode gefunden schnell eine lange Liste durchzuschauen. Z.B. nach "Infrarot" suchen und die Liste mit 100 Bauteilen durchsuchen ob nicht eines dabei ist das ein ähnliches oder das gleiche Gehäuse hat. Bei Eagle war das nur 100x auf Pfeil nach unten tippen, der Footprint wurde gleich angezeigt.
Georg S. schrieb: > Abgleitete Schaltplansymbole gibt es ja seit Version 10. (was mich Gab es schon vorher. @ all Ich habe das jetzt kurzerhand mit meinem KiCad 9 probiert. Ich habe statt Pinnummern, die gleiche Bezeichnung wie beim Pinnamen eingetragen. G, S, D. Das gleiche im Footprint gemacht. Schaltplan erstellt. Keine Fehler. Leiterplatte erstellt. keine Fehler. Scheint zu funktionieren. Pinnummer muss demzufolge nicht zwangsweise eine Ziffer sein. Probiert es aus.
Moin, Veit D. schrieb: > Pinnummer muss demzufolge nicht zwangsweise > eine Ziffer sein. Probiert es aus. <Ach!> Waere ja auch ziemlich doof. Vor allem bei BGA-Gehaeusen.... Gruss WK
Michael S. schrieb: > Lediglich die Netze, die an den Pins angeschlossen sind. Darauf läuft es am Ende hinaus.
Dergute W. schrieb: > Moin, > > Veit D. schrieb: >> Pinnummer muss demzufolge nicht zwangsweise >> eine Ziffer sein. Probiert es aus. > > <Ach!> Waere ja auch ziemlich doof. Vor allem bei BGA-Gehaeusen.... > > Gruss > WK Du hast nicht verstanden. Es muss nicht zwangsweise eine Ziffer voranstehen oder sonst irgendwie eine Ziffer enthalten sein. Ich meine du hättest schon lange die Chance gehabt das Problem vom TO zu lösen. Haste aber nicht. Nun leb damit.
Veit D. schrieb: > Ich meine du hättest schon lange die Chance gehabt das Problem vom TO zu > lösen. Haste aber nicht. Nun leb damit. Aber das heißt ja, ich mache ein MOSFET oder LDO Symbol, mit Text als Padnamen (G, S, D oder GND, VOUT, VIN). Also muss ich ja pro Variante ein extra Package anlegen. Dann habe ich bei 5 unterschiedlichen Aufteilungen nicht 5 verschiedene Symbole sondern z.B. 5 verschiedene Footprints, wo dann die passenden Pad-Namen an der entsprechenden Stelle sind. Damit verlagert man das Thema ja nur vom Symbol zu den Footprints. Denn die Kopplung von Symbol-Pins zu Footprint-Pads bleibt ja bestehen, unabhängig vom Namen des Pads
Michael S. schrieb: > Aber das heißt ja, ich mache ein MOSFET oder LDO Symbol, mit Text als > Padnamen (G, S, D oder GND, VOUT, VIN). Also muss ich ja pro Variante > ein extra Package anlegen. Dann habe ich bei 5 unterschiedlichen > Aufteilungen nicht 5 verschiedene Symbole sondern z.B. 5 verschiedene > Footprints, wo dann die passenden Pad-Namen an der entsprechenden Stelle > sind. Damit verlagert man das Thema ja nur vom Symbol zu den Footprints. > Denn die Kopplung von Symbol-Pins zu Footprint-Pads bleibt ja bestehen, > unabhängig vom Namen des Pads Irgendwie verstehe ich Dich jetzt nicht. Irgendwie mußt Du ja dem Symbol am Ende einen Footprint zuweisen, damit aus dem Ganzen ein reales Bauteil wird. Da führen zwei wege nach Rom entweder die Eagle- oder die KiCad-Variante. Bei ersterem machst Du das im Bibliothekseditor, wenn Du das Device erstellst. Dort tust ja den Pins des Symbols die Pads des Footprints zuweisen. Dafür muß halt jedes benutzte Symbol und jeder Footprint genau einmal in der Bibliothek vorhanden sein. Bei KiCad ist das halt anders. Wenn ich es richtig verstanden habe, werden die Pins des Symbols und die Pads des Footprints über deren Bezeichung verbunden, sobald Du dem Symbol einen Footprint zuweist. Welchen Teil Du jetzt variabel machst ist da egal. Beide Varianten haben Vor- und Nachteile.
Hans schrieb: > Da führen zwei wege nach Rom entweder die Eagle- oder die > KiCad-Variante. Oder eben mit einer Schicht dazwischen, siehe BAE. Dort sieht das dann so aus:
1 | part ne555: default dil8 {
|
2 | newattr "$comment" = "Timer" ; |
3 | newattr "$type" = "NE555" ; |
4 | pin (thr, trg, r, dc, o, cv); |
5 | xlat (thr, trg, r, dc, o, cv) |
6 | to (6, 2, 4, 7, 3, 5); |
7 | net "gnd": (1); |
8 | net "vcc": (8); |
9 | } |
Das "xlat" erledigt dort die Abbildung der Namen des Schaltplansymbols auf die Pins des Footprints. Für den Fall, dass sie gleich sind, kann man es weglassen, aber die "pin"-Zeile wird trotzdem gebraucht. Ist halt insgesamt mehr Aufwand. Das constraining für pin/gate swap erfolgt dort ebenfalls an dieser Stelle, hier beispielsweise die Definition eines 7400:
1 | part 7400 : default dil14 {
|
2 | newattr "$comment" = "Quad 2 Input NAND Gate" ; |
3 | newattr "$ttlout" = "TP" ; |
4 | pin (a,b,y) ; |
5 | net "vss" : (7) ; |
6 | net "vcc" : (14) ; |
7 | xlat ( a, b, y) |
8 | to ( 1, 2, 3) |
9 | or ( 4, 5, 6) |
10 | or ( 9,10, 8) |
11 | or (12,13,11) ; |
12 | swap ( (( 1, 2), 3), |
13 | (( 4, 5), 6), |
14 | (( 9,10), 8), |
15 | ((12,13),11) ) ; |
16 | } |
Angehängte Dateien:
Hans schrieb: >> Und Pin Swap funktioniert nur halb, weil nicht die >> Pin-Nummern vertauscht werden, sondern die Verbindungen im Schaltbild >> anschließend gekreuzt sind. > > dto. Überlege mal warum die gekreuzt sind und warum man am Ende ein > Pinswap macht. Du hast aber insofern recht es wäre gut wenn er hier die > Verbindungen im Schematic gleich selbst korrigieren würde, notfalls nach > Rückfrage. Habe ich nun gerade mal in Kicad 10 probiert. Die tauschen dann am Schaltplansymbol tatsächlich auch die Pins, siehe Anhang. PD0 bis PD7 waren da ursprünglich von oben nach unten angeordnet, nach pin swap im Board und backannotation wurden sie dann im Schaltplan getauscht.
Also meine Version in KiCAD ist so: Es gibt genau einen Footprint SOT-23. Dessen Pin-Numerierung ist zum Glück bereits vorgegeben. Will ich dies einem NMOS-FET zuweisen, habe ich ein Symbol "NMOS-GSD". Also gate=pin1, source=pin2, drain=pin3. Denselben Footprint kann ich mit dem Symbol "NPN-BEC" verknüpfen. Die pin-Numerierung ist in dem Symbol festgeschrieben, eine andere pin-Folge erfordert ein anderes Symbol.
:
Bearbeitet durch User
Hans schrieb: > Bei KiCad ist das halt anders. Wenn ich es richtig verstanden habe, > werden die Pins des Symbols und die Pads des Footprints über deren > Bezeichung verbunden, sobald Du dem Symbol einen Footprint zuweist. Quasi ja. Im Symbol sagst du, dass der Pin z.B. Vcc heißt. Und du verbindest diesen Pin z.B. mit Pad "14". Jetzt kannst du dem Symbol jedes x-beliebige Footprint zuweisen und wenn darin ein Pad "14" existiert, ist dort das Netz angeschlossen, das im Schaltplan an Vcc des Bauteils geht. Der Kern meiner Frage war eben, ob man diese Zuweisung z.B. durch Datenbank-Bibliotheken verändern kann. Man kann dort das Symbol und Footprint angeben, den Designator, ob es in der BOM auftauchen soll oder nicht, Bestellnummern... Quasi alle Eigenschaften des Symbols. Aber allen Anschein nach nicht die Zuweisung "Vcc" soll beim Footprint auf Pad "14" gehen. Ich weiß auch nicht, ob das so unmöglich bzw. soo viel Aufwand bedeutet, diese Funktion einzubauen. So wie ich das verstehe wird bei der Datenbank jede Zeile gelesen und als Bauteil/Symbol angelegt. Wie eine Ableitung vom Symbol, dass in der Zeile angegeben wurde. Danach werden alle Felder anhand der Spalten der Datenbanktabelle und der "Zuweisungsliste" *.kicad_dbl überschrieben. Was sich also ändern müsste wäre, dass das angegebene Symbol nicht abgeleitet wird, sondern kopiert und dass die Eigenschaften der Pins bearbeitet werden können (Vcc -> 14). Hans schrieb: > Irgendwie verstehe ich Dich jetzt nicht Ich wollte damit nur sagen, dass die Antwort ebenso meine Ursprungsfrage nicht beantwortet (oder eben schon, mit einem "Nein, geht nicht). Jörg W. schrieb: > Die tauschen dann am Schaltplansymbol tatsächlich auch die Pins, siehe > Anhang. PD0 bis PD7 waren da ursprünglich von oben nach unten > angeordnet, nach pin swap im Board und backannotation wurden sie dann im > Schaltplan getauscht. Was? Das ist ja prädestiniert für Fehler im Nachhinein. Dann habe ich aber deutlich lieber gekreuzte Signale im Schaltplan als die Pin-Reihenfolge beim Symbol zu ändern. Aber witzig, wie man alles diese Symbole verbiegen, ableiten oder verändern kann, außer diese verfluchte Pin/Pad Zuweisung^^
:
Bearbeitet durch User
Michael S. schrieb: > Quasi ja. Im Symbol sagst du, dass der Pin z.B. Vcc heißt. Und du > verbindest diesen Pin z.B. mit Pad "14". Jetzt kannst du dem Symbol > jedes x-beliebige Footprint zuweisen und wenn darin ein Pad "14" > existiert, ist dort das Netz angeschlossen, das im Schaltplan an Vcc des > Bauteils geht. "Pad" benutzt man normalerweise für SMD-Bauteile, "Pin" für THT. Ansonsten sind sie gleichbedeutend. Kicad nennt es "Pin name" (das, was im Symbol angezeigt wird) und "Pin number" (das, was mit dem Footprint zusammenpasst). > Ich wollte damit nur sagen, dass die Antwort ebenso meine Ursprungsfrage > nicht beantwortet (oder eben schon, mit einem "Nein, geht nicht). Doch, wurde schon: Nein, geht nicht. Bräuchte einen massiven Umbau des ganzen Konzepts. > Jörg W. schrieb: >> Die tauschen dann am Schaltplansymbol tatsächlich auch die Pins, siehe >> Anhang. PD0 bis PD7 waren da ursprünglich von oben nach unten >> angeordnet, nach pin swap im Board und backannotation wurden sie dann im >> Schaltplan getauscht. > > Was? Das ist ja prädestiniert für Fehler im Nachhinein. Welche Fehler können daraus im Nachhinein entstehen?
> Jörg W. schrieb: >> Die tauschen dann am Schaltplansymbol tatsächlich auch die Pins, siehe >> Anhang. PD0 bis PD7 waren da ursprünglich von oben nach unten >> angeordnet, nach pin swap im Board und backannotation wurden sie dann im >> Schaltplan getauscht. > > Was? Das ist ja prädestiniert für Fehler im Nachhinein. Das ist aber sicherlich graphisch weit schwieriger zu automatisieren dass die Kreuzung immer so gezeichnet wird dass sie nicht mit anderen Leitungen und Schaltplanelementen kollidiert.
Hans schrieb: > Irgendwie mußt Du ja dem Symbol > am Ende einen Footprint zuweisen, damit aus dem Ganzen ein reales > Bauteil wird. > > Da führen zwei wege nach Rom entweder die Eagle- oder die > KiCad-Variante. Bei ersterem machst Du das im Bibliothekseditor, wenn Du > das Device erstellst. Dort tust ja den Pins des Symbols die Pads des > Footprints zuweisen. Dafür muß halt jedes benutzte Symbol und jeder > Footprint genau einmal in der Bibliothek vorhanden sein. Ich persönlich bevorzuge die unflexieble Eagle Methode. Dann klickt man icht bei jedem Schaltplan neu auf das falsche Footprint: SOP-8 in schmal oder breit, TSSOÜ14 oder SSOP-14, oder QFN mit 0,5 oder 0,4mm Padabstand und unterschiedlichen Größen des Exposed Pad. Ich suche einmal das passende Gehäuse raus und gut ist. Weil bei KiCAD muss man bei jedem Schaltplan erneut das Risiko eingehen dass man falsch klickt und ein subtil anderes Gehäuse hat als das was passen würde. Wenn ich ICs in KiCAD anlege, dann weise ich einen Footprint zu und sperre die Footprint-Auswahl im Schaltplan. Außer wenn es ausnahmsweise mal Sinn macht.
Georg S. schrieb: > Ich persönlich bevorzuge die unflexieble Eagle Methode. Dann klickt man > icht bei jedem Schaltplan neu auf das falsche Footprint: SOP-8 in schmal > oder breit, TSSOÜ14 oder SSOP-14, oder QFN mit 0,5 oder 0,4mm Padabstand > und unterschiedlichen Größen des Exposed Pad. Ich suche einmal das > passende Gehäuse raus und gut ist. Ich bevorzuge persönlich auch die Eaglemethode, weil ich da eher das Gefühl habe mit einem realen Bauelement zu arbeiten. Beim Entwickeln bzw. Zeichnen des Schaltplanes wähle ich, wie Du auch, halt das Symbol mit einem passenden Gehäuse (Footprint) aus. Allerdings ist das nicht in Stein gemeißelt. Sollte ich beim Routen feststellen das ein anderer Footprint für die reale Umsetzung besser geeignet ist, dann ist der ja im PCB Editor schnell gewechselt, der Schaltplan bleibt davon unberührt, da sich dort ja nix ändert. Ich komme so gut zurecht, andere mögen das anders sehen. Ich persönlich tue mich mit dem Workflow von KiCad halt schwer. Am Ende kann man sich sicherlich auch an diesen gewöhnen, aber solange Eagle noch läuft besteht für mich kein Grund zum Wechsel. Welches ECAD es wird, wenn ich mal wechseln muß kann ich jetzt noch nicht sagen. Da ich das fürs Hobby nutze, sollte es bezahlbar sein. Target hat mir bis jetzt ganz gut gefallen, allerdings sind die Einschränkungen der freien Version und Lightversion schon erheblich und die kommerziellen Versionen schlagen finanziell schon erheblich zu Buche - 629€ für limitierte 1000 Pins und 2 Lagen liegt schon deutlich über der Schmerzgrenze was man für so ein Programm ausgeben möchte. LibrePCB habe ich mir mal kurz angeschaut und das würde schon eher in meine Richtung gehen.
Michael S. schrieb: > Aber das heißt ja, ich mache ein MOSFET oder LDO Symbol, mit Text als > Padnamen (G, S, D oder GND, VOUT, VIN). Also muss ich ja pro Variante > ein extra Package anlegen. Dann habe ich bei 5 unterschiedlichen > Aufteilungen nicht 5 verschiedene Symbole sondern z.B. 5 verschiedene > Footprints, wo dann die passenden Pad-Namen an der entsprechenden Stelle > sind. Damit verlagert man das Thema ja nur vom Symbol zu den Footprints. > Denn die Kopplung von Symbol-Pins zu Footprint-Pads bleibt ja bestehen, > unabhängig vom Namen des Pads Nicht Text im Pinnamen - in der Pinnummer! Footprints muss man sowieso für alle Pinbelegungsvarianten einer Gehäuseform anlegen. Aber das Symbol einen Mosfets muss nur einmal angelegt werden, wenn man Text in der Pinnummer verwendet. > Denn die Kopplung von Symbol-Pins zu Footprint-Pads bleibt ja bestehen, > unabhängig vom Namen des Pads Das ist doch der Sinn dahinter. Aber soll jeder machen wie er möchte. Ich mach das alles sauber, wenn es erforderlich ist, neues Symbol und neuen Footprint, dass wird in den Symboleigenschaften verknüpft und mit konkreten Bauteilnamen gespeichert. Dann gibt es bei der Auswahl keine Zweifel. Dann kann auch jeder irgendwann ins Datenblatt des Bauteiles schauen und die Pinnummern stimmen überein ohne Rätselraten.
:
Bearbeitet durch User
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.