Gibt es Standards, die beschreiben nach welchen Regeln Schaltungselemente bzw. Bauteile zu annotieren sind: "In schematic world, references have rules. A reference cannot be anything you like. This is a link to simulators, footprint editors, BOM generators... Please respect them." (Statement eines KiCad Entwicklers auf Launchpad: https://bugs.launchpad.net/kicad/+bug/1657911). In der KiCad-Doku habe ich dazu nichts gefunden. Hintergrund - KiCad akzeptiert seit Version 5.1.5 Annotationen wie "Rl_02" und "Rl_2" nicht mehr nebeneinander (in älteren Versionen war das problemlos möglich) - der ERC stolpert über "multiple Item" und bleibt stehen. Offensichtlich wird die führende Null in der Referenz "Rl_02" beim Schreiben der .sch Datei entfernt. N.B.: Das Design hat zwei symmetrische Verstärkerkanäle. Annotiert hätte ich diese gerne mit einem Suffix _l/_r; geht leider nicht, da Referenzen in KiCad aber mit einer Ziffer enden müssen (nicht dokumentiert).
Burkhard K. schrieb: > Gibt es Standards, die beschreiben nach welchen Regeln > Schaltungselemente bzw. Bauteile zu annotieren sind Nö, eigentlich nicht. Das Wichtigste ist eigentlich, daß man einen Stromlaufplan und einen Bestückungsplan gut lesen kann und daß Name und Wertbezeichner möglichst verwechselungssicher auf dem Zeichnungsblatt angeordnet sind. Da habe ich schon vielen Bockmist gesehen: Namen viel zu weit weg vom Bauteil, Bezeichner in allen möglichen Himmelsrichtungen, Bezeichner mehrerer BE übereinander auf derselben Stelle usw. Ansonsten sind Namen eigentlich wahlfrei. Ob man nun den ersten Widerstand, den man plaziert hat nun 'R1' nennt oder 'Karlheinz', sollte dem EDA egal sein. Hauptsache es ist in sich konsistent. Allerdings sehe ich durchaus, daß Leerzeichen oder (je nach EDA) evtl. auch Sonderzeichen in den Namen wohl zu Problemen führen können - was bei dir offenbar zutrifft. Aber das betrifft eben nur dein EDA. Etwas anderes sind womöglich Pinbezeichnungen: bei Eagle kann man sowas wie GND.1 GND.2 AGND usw. schreiben, die man ohne einen ERC-Fehler zu machen alle auf GND legen kann. Was Kicad da treibt, erschließt sich mir hingegen nicht. W.S.
W.S. schrieb: > evtl. auch > Sonderzeichen in den Namen wohl zu Problemen führen können Falls Du den Unterstrich meinst - der ist harmlos (noch). Problematisch war die Kombination "02" - was im Schaltplan aber erstmal nicht auffällt. W.S. schrieb: > wie GND.1 GND.2 AGND usw. schreiben, die man ohne einen ERC-Fehler zu > machen alle auf GND legen kann. Bei KiCad wird gemeckert - zum Verbinden von GND und AGND kann man "Ties" nehmen (Bibliothek: "Oddities"). Ties sind (relativ große) Pseudo-Bauteile. Ich spar mir das und lege die verbindende Leiterbahn als letzten Schritt von Hand. KiCad fehlt ganz offensichtlich ein Check der Benutzereingabe gegen die "erlaubten" Regeln. Wer unwissentlich davon abweicht, rennt spätestens beim ERC oder der Footprintzuordung gegen die Wand - zum Teil mit ziemlich obskuren Fehlermeldungen.
Es gibt dafür tatsächlich Standards, z.B.: https://www.noao.edu/ets/Mechanical/Policies/ANSI%20Y32.16-1975.pdf Grundsätzlich finde ich es zwar gut, dass es dafür Standards gibt, aber ich stimme mit dem Ersteller des Bug-Reports überein, dass es nicht die Aufgabe von KiCad sein sollte, die Einhaltung der Standards zu erzwingen. (Mal abgesehen davon, dass sich KiCad auch nicht daran hält. Es gibt da z.B. auch eine Regel "Numbers assigned to items which have been deleted shall not be reused."). Ein optionaler Check im ERC/DRC wäre aber sicher nett. Gruß, Bernd
Danke für den Link. https://en.wikipedia.org/wiki/Reference_designator nennt als Nachfolgestandard ASME Y14.44-2008, der leider nicht frei erhältlich ist. Interessanterweise nennt das Dokument von 1975 "Location Coding" und "Sequential Coding" als gleichberechtigte Methoden; die vom Ersteller des Bug-Reports verwendete Annotation könnte also sehr wohl "standardkonform" gewesen sein.
Burkhard K. schrieb: > Interessanterweise nennt das Dokument von 1975 "Location Coding" und > "Sequential Coding" als gleichberechtigte Methoden; die vom Ersteller > des Bug-Reports verwendete Annotation könnte also sehr wohl > "standardkonform" gewesen sein. In dem IEEE Std 200-1975 ANSI Y32.16-1975 wird für sich wiederholende Baugruppen bspw. für einen Kondensator C1 einfach N1C1, N2C1 usw. empfohlen, wobei mit Nx die Baugruppen gekennzeichnet werden (S.12 4.1.5.6 Repeated-use Circuits).
Burkhard K. schrieb: > W.S. schrieb: >> evtl. auch >> Sonderzeichen in den Namen wohl zu Problemen führen können > Falls Du den Unterstrich meinst - der ist harmlos (noch). Problematisch > war die Kombination "02" - was im Schaltplan aber erstmal nicht > auffällt. Ich kann es durchaus verstehen, wenn ein EDA-System die Zeichen für Bauteilnamen irgendwie einschränkt, wenn es dafür wirklich sinnvolle Gründe gibt. Normalerweise sollten alle Zeichen außer Leerzeichen (und ggf. mathematischen oder rechentechnischen Zeichen) in Bauteil-Namen harmlos sein. Bei Eagle, was ja skriptfähig ist, ist das eben wegen der Skriptfähigkeit vom Prinzip her verständlich. Hat Kicad überhaupt ne eingebaute Skriptsprache? Wenn man aber nun ein Bauteil Emil_020 und ein anderes Emil_20 benennt, dann sind das eben zwei verschiedene Namen. Punkt. Und das EDA-System sollte das korrekt handhaben können. Kann Kicad offenbar nicht. Mein Beispiel weiter oben war ja nicht für die Namen von Bauteilen, sondern für die Pins der Bauteile, was etwa Anderes ist. Und das ist auch dringend nötig: Man denke mal an die Pins eines üblichen µC. Dort hat man heutzutage fast immer mehrere GND und mehrere VCC und alle diese Rail-Pins müssen an ein einheitliches Netz GND bzw. VCC angeschlossen werden. Offenbar baut Kicad bei den Bauteilnamen Mist, weil es versucht, den Text von Bauteilnamen zu parsen. Wozu eigentlich? Ich schätze mal, das ist ein Teil irgend eines anderweitigen Workarounds innerhalb von Kicad, weil Kicad wegen Fehlens von Bauteilen (hat ja nur Symbole+Footprints) eine Lücke in der Organisation der verwendeten Bauteile hat. Tja, falsch gelegte Fundamente bewirken eben Folgeprobleme. Und so muß man sich als Benutzer offenbar auch noch daran gewöhnen, daß man selbst in der Namensgebung von Bauteilen sich um die dort aufgespannten Fallstricke auch noch herumlavieren muß. Ist echter Komfort, gelle? Wirklich, je mehr ich von Kicad lese, desto mehr wird mir klar, was für eine Steißgeburt Kicad realiter ist. Mir scheint, der Fortschritt bei Kicad besteht zu etwa 90% aus Workarounds, mit denen man die Kollateralschäden vorheriger Workarounds ausbügeln will. Was also kommt als nächstes zutage? W.S.
W.S. schrieb: > Eagle, was ja skriptfähig ist, ist das eben wegen der Skriptfähigkeit > vom Prinzip her verständlich Da kann man aber freie Namen nehmen ( ohne Leerzeichen und alles Großbuchstaben). Manchmal bei Testschaltungen nützlich R_VOR1 oder so. W.S. schrieb: > Wirklich, je mehr ich von Kicad lese, desto mehr wird mir klar, was für > eine Steißgeburt Kicad realiter ist. Selber finde ich KIcad ein tolles Projekt. Der Fangemeinde Stände aber gut zu Gesicht mit Fehlern und Einschränkungen so umzugehen wie es die meisten anderen machen. Autodesk Eagle hat da den "Heimvorteil" das diese Firma sich eh nicht um Sympathiepunkte bewirbt ;-).
Toby P. schrieb: > Autodesk Eagle hat da den "Heimvorteil" das diese Firma sich eh nicht um > Sympathiepunkte bewirbt ;-). Autodesk hat mit der Skriptsprache oder der Bauteilbennenung bei Eagle nun wirklich wenig zu tun.
Aber mit Eagle könnte man die strikten Regeln von kicad einhalten und die Koordinaten-Schreibweise verwenden. Also >NAME wie in kicad gefordert und ein Attribute für die Koordinaten. Was dann wo gedruckt wird, lässt sich über die Layerauswahl steuern. Etwas ähnliches sollte doch in kicad auch möglich sein.
Bauform B. schrieb: > könnte man die strikten Regeln von kicad einhalten Wenn Sie denn irgendwo dokumentiert wären. Die Reference-Manuals (https://docs.kicad-pcb.org/) sagen dazu nichts. Im Ref-Manual für Eeschema wird lediglich das Annotation-Tool erwähnt. Offensichtlich wird darauf vertraut, dass Benutzer für die Annotation immer dieses Tool benutzen - und so gar nicht erst auf "dumme" Ideen kommen.
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.