Erfahrungen mit KiCAD von Eagle-Wechslern

[Noob A. (strippenzieher)]

Ich möchte das einfach mal loswerden, und auch andere animieren zu 
berichten...

Ich habe mich vor einiger Zeit durchgerungen Eagle mal beiseite zu legen 
und KiCAD mal wirklich anzutesten und mittlerweile habe ich schon ein 
paar Leiterplatten damit gemacht.
Anfänglich tat ich mich schwer mit der Bedienung, die ist doch deutlich 
unterschiedlich: Scrollen, Footprints zuweisen, Netzlisten, Gerberdaten, 
dass der Cursor nach dem Editieren wieder an die Ausgangsposition 
zurückspringt...
Alles Kleinigkeiten die mir am Anfang als unerträglich nervig vorkamen.

Nach 2 kleinen Projekten hatte ich mich aber an den Workflow gewöhnt und 
auch die ab und zu komisch anmutende Benutzung nervt nicht mehr 
wirklich.
Ich hab durchgehalten und seitdem nix mehr mit Eagle gemacht!
Halt, stimmt nicht ganz: einmal eine 7.6. Freeware Version installiert 
um die alten 5er Dateien in das neue Format zu konvertieren damit KiCAD 
das importieren kann.
Ging erstaunlich glatt, ich wollte allerdings nur die Bauteile und habe 
deswegen weder Schaltplan noch Layout wirklich überprüft. Sah auf den 
ersten Blick allerdings recht komplett aus. Ein paar Sachen waren auf 
dem falschen Layer gelandet, aber nichts was man in tagelanger Arbeit 
hätte anpassen müssen

Aber das Beste ist: Ich hab heute ein altes Eagle-Projekt wieder 
anfassen müssen, und was soll ich sagen, nun kommt mir dort die 
Bedienung sehr sehr komisch und nur wenig intuitiv vor lach
Ich musste suchen um die Löschen-Funktion zu finden. Und warum gibt es 
unterschiedlich Knöppe für Leiterbahn löschen und Andere Sachen löschen?

Fazit: beide Programm habe Ihre Eigenheiten! Meine Projekte konnte ich 
immer realisieren egal ob Eagle oder KiCad.
Zugegeben sind es immer minder-komplexe Angelegenheiten gewesen!

Aber ich kann jedem der keine Lust mehr auf Eagle hat oder die 
Beschränkungen der Gratis-Version umgehen möchte nur dazu raten mal 
KiCAD anzutesten. Zeit zur Umgewöhnung sollte man mitbringen, aber ich 
denke das ist bei jedem Wechsel so.
Und ja, ich schreibe vielleicht etwas überschwänglich und möglicherweise 
nicht ganz objektiv aber das ich eben in Eagle nicht zurechtkam war 
einfach ein schönes Aha-Erlebnis das ich gerne teilen wollte...

Würde mich freuen mal ein paar Erfahrungen von Anderen zu lesen (die 
mehr als mal eine Stunde mit KiCAD rumgespielt haben).
Sehr interessieren würden mich Erfahrungen von aufwändigeren Projekten!

Viele Grüße,
Bob

[Rene K. (xdraconix)]

Bob A. schrieb:
> Würde mich freuen mal ein paar Erfahrungen von Anderen zu lesen (die
> mehr als mal eine Stunde mit KiCAD rumgespielt haben).

Ich habe mir das gerade mal angetan. Ca. ne Stunde... Und was soll ich 
sagen - bin relativ enttäuscht.

Ich habe mir das aktuelle stable geladen, welches sich dann mit ca. 
3.2GB auf die Platte legt.

Gestartet und nach Frage ein Projekt angelegt. Der Schaltplaneditor ist 
noch relativ intuitiv gehalten. Rechts halt die Symbole und das Symbol 
zum hinzufügen der Bauelemente. Ich hab was ganz leichtes gemacht, zwei 
2xPinheader jeweils mit einem GND und einem 12V versehen. Da stieß ich 
schon auf das erste Problem: Beim verschieben der Bauelemente auf dem 
Feld (und da waren ja bloß zwei!) ruckelte es wie die Hulle.

Am Rechner kann es eigentlich nicht liegen, ein i7  32GB  GTX980, 
wahrscheinlich eine Treibersache - was anderes kann ich mir nicht 
erklären - jedoch das Bauteil dann irgendwo dorthin zu treffen wo es 
soll war mehr als schwierig.

Nun... okay... das Layout stand und ich wollte daraus ein PCB machen und 
öffnete dafür PCBNEW über das Hauptfenster: Joar... aber wie und wo und 
womit bekomme ich da meine Bauteile nun auf meine Platine die ich im 
Layout habe?! Ich habe (intuitiv) keine Möglichkeit gesehen dies dort 
einzufügen.

Entschuldigt bitte, aber bei allen anderen ECAD die mir so über den Weg 
gelaufen (Eagle, Target, Altium) sind öffne ich den PCB Editor und finde 
halt meine Bauteile da irgendwo auf dem Blatt die ich mir dann 
zurechtrücke und ich sie verbinden kann.

Nach ca. ner Stunde insgesamt hab es dann erstmal wieder ausgemacht und 
sein lassen.

Ohne sich vorher erstmal in Tutorials einzulesen werde ich 
wahrscheinlich erstmal noch nicht warm mit KiCAD. Wenn ich mal etwas 
Zeit und Muse habe - dann werde ich mir wohl mal nen Beginner-Tut von 
KiCad zu Gemüte führen. Solange werde ich wohl noch bei Eagle bleiben - 
wo alles irgendwie "flüssiger" ist.

[Noob A. (strippenzieher)]

Danke für deinen Bericht.

Jaa, die steile Lernkurve am Anfang hatte ich auch. Da ich mittlerweile 
fließend damit arbeiten kann habe ich das aber irgendwie verdrängt. Das 
hätte in der Tat in meinen Bericht mit rein gehört!

Man gewöhnt sich dran nachdem der Schaltplane erstellt ist, die Bauteile 
erstmal einem Footprint zuzuordnen und dann die Netzliste zu erstellen 
und in pcbnew einzulesen.

Dass es keinen Automatismus dafür gibt ist mir schleierhaft und 
sicherlich eine der größten Hürden beim antesten / einlernen.
Die ganze Bedienung scheint mir von einem streng linearen workflow 
auszugehen. Wenn die Schaltung fertig ist entscheidet man sich für die 
Bauformen der Komponenten und macht dann das Layout. Änderungen 
erfordern immer weider das erstellen der Netzliste im Schaltplan-Editor 
und diese muss dann in pcbnew eingelesen werden.
Hat man das mal raus geht es in 1-2 Sekunden die paar Klicks 
durchzuexerzieren aber ja, intuitiv ist anders!

Ich habe aktuell die beta von Version 5, da gibt es "Update PCB from 
Shematic" in Schaltplan-Editor und Layout-Editor, ist trotzdem noch 
etwas Rumgeklicke und kein Automatismus...

[Karl (Gast)]

Haters will Always hate.

Was soll das gebashe. Bleibt doch beim Adler wenn der so geil ist.

Man kann mit kicad arbeiten. Und es ist kostenlos. Den Rest entscheidet 
die persönliche Flexibilität.

[Peter (Gast)]

Rene K. schrieb:
> Entschuldigt bitte, aber bei allen anderen ECAD die mir so über den Weg
> gelaufen (Eagle, Target, Altium) sind öffne ich den PCB Editor und finde
> halt meine Bauteile da irgendwo auf dem Blatt die ich mir dann
> zurechtrücke und ich sie verbinden kann.

Also von Altium kenne ich das nicht, hier hole ich die Änderungen immer 
über Design/Import Changes in die PCB.
Für mich war diese Auto-Annotation (nennt man das so?) immer eine 
Eigenheit von Eagle.

[Noob A. (strippenzieher)]

Karl schrieb:
> Was soll das gebashe

Wieso Gebashe?

Ich empfinde das alles noch als legitime Kritik und Meinungsäußerung.

Mein Punkt ist einfach: Weder Eagle noch KiCAd sind wirklich intuitiv!
Ich habe das erst bemerkt nachdem ich im Wechsel mit beiden gearbeitet 
habe.

Man gewöhnt sich lediglich an die Eigenheiten "seines" Programms...

[Vancouver (Gast)]

Ich kann den Eindruck des TO voll bestätigen. Nach dem Wechsel auf KiCAD 
durchläuft man erst mal eine Lernkurve und es geht alles etwas 
lamgsamer. Aber beim zweiten oder dritten Layout hat man das im Griff, 
und dann ist KiCAD ein vollwertiger Ersatz für den Adler.

Wie es bei sehr großen Designs aussieht, kann ich nichts dazu sagen. Ich 
vermute mal, ich wollte kein Kuchenblech mit 12 Layern und 10k Vias 
damit designen. Aber mit Eagle wollte ich das auch nicht.

Hat jemand schon mal KiCAD für ein richtig komplexes Design verwendet?

[Noob A. (strippenzieher)]

wäre halt schon cool wenn man wüsste was die beim CERN damit 
anstellen...

[Michael R. (Firma: Brainit GmbH) (fisa)]

Peter schrieb:
> Für mich war diese Auto-Annotation (nennt man das so?) immer eine
> Eigenheit von Eagle.

Hmmm... auch ich überlege, den Adler ins ewige noShow zu verbannen... 
doch das mit dem "anderen" Workflow schreckt mich wirklich ab.

zB PinSwap / GateSwap benutze ich sehr häufig, wenn ich beim Layouten 
draufkomme dass es andersrum einfacher wäre... muss ich dann Schaltplan 
und Layout "halbmanuell" synchronisieren?

[Noob A. (strippenzieher)]

Michael R. schrieb:

> zB PinSwap / GateSwap benutze ich sehr häufig, wenn ich beim Layouten
> draufkomme dass es andersrum einfacher wäre... muss ich dann Schaltplan
> und Layout "halbmanuell" synchronisieren?

Ich befürchte ja, wobei das wirklich flott geht.
Was ich nicht weiß ist ob es die Möglichkeit gibt Änderungen im Layout 
in den Schaltplan zu übernehmen?
Mein Erfahrungsschatz bei eagle und KiCad ist eben doch recht 
beschränkt...

[Chris D. (myfairtux) (Moderator)]

Bob A. schrieb:
> Man gewöhnt sich dran nachdem der Schaltplane erstellt ist, die Bauteile
> erstmal einem Footprint zuzuordnen und dann die Netzliste zu erstellen
> und in pcbnew einzulesen.
>
> Dass es keinen Automatismus dafür gibt ist mir schleierhaft und
> sicherlich eine der größten Hürden beim antesten / einlernen.

Wie sollte der Automatismus aussehen? Woher soll der Automatismus 
wissen, ob Du 0805 oder 1206 als Widerstandsbauform haben möchtest?

Übrigens kann man einem Schaltplanbauteil problemlos direkt im "Field 
properties"-Dialog mit "Assign footprint" (wer hätte das gedacht ;-) 
einen Footprint suchen und fix zuordnen - so wie bei Eagle (siehe 
Screenshot).

Man hat also beide Möglichkeiten, je nach persönlichem Geschmack. Ich 
selbst habe lieber übersichtliche Schaltplanbibliotheken und weise dann 
per Annotation-Dialog zu. Fixe Zuordnungen habe ich nur bei 
entsprechenden ICs, bei denen es nur einen sinnvollen Footprint gibt.

Ansonsten: ein doch relativ komplexes Programm nach nicht einmal einer 
Stunde zu beurteilen halte ich für wenig zielführend. Natürlich muss 
man sich da einarbeiten, insbesondere wenn man schon auf ein anderes 
Programm fixiert war. Wer noch nie mit ECAD-Software zu tun hatte, tut 
sich da meiner Erfahrung nach erheblich leichter, einfach weil er nicht 
auf auf einen bestimmten Ablauf geprägt ist.

[Stefan (Gast)]

> Man gewöhnt sich dran nachdem der Schaltplane erstellt ist, die Bauteile
> erstmal einem Footprint zuzuordnen und dann die Netzliste zu erstellen
> und in pcbnew einzulesen.

Ich finde es interessant dass ausgerechnet Eagle User so vorgehen und 
sogar meinen es sei normal in Kicad die FPs erst später zuzuweisen. Kann 
man zwar so machen, finde ich aber ungeschickt.

Inzwischen benutze ich Kicad seit gut einem Jahr, mittlerweile auch 
beruflich (Eagle: 15 Jahre). Ich bin es von Eagle her so gewohnt das 
Symbole und Packages bereits verknüpft sind wenn ich ein Bauteil im 
Schaltplan einfüge.
In Kicad arbeite ich ähnlich. Wenn ich z.B. einen Widerstand einfüge, 
dann ist es für mich normal dem Bauteil einen Wert und ein FP zu 
geben. Das geht sogar während das Teil noch am Mauszeiger hängt.
Und da die meisten Widerstände ohnehin das gleiche Package haben, füge 
ich nicht jeden Widerstand aus der Lib einzeln ein sondern kopiere einen 
vorhandenen und ändere ggf. den Wert. Mache ich auch mit Eagle so.

Dieses CvPCB Tool benutze ich nicht. Alle Teile haben bereits ihren FP.

Netzlisten erstellen und einlesen muß man inzwischen auch nicht mehr. 
Einfach im Schaltplaneditor "F8" drücken und das Board wird 
aktualisiert.
Nein, Backannotation wie Eagle es kann geht nicht. Ist imho für die V6 
geplant.

Aktuell benutze ich Eagle kaum noch. Meine Einstellung zu den beiden 
Programmen hat sich inzwischen umgekehrt. So hatte ich mich vor ca. 1 
Jahr noch über diverse Merkwürdigkeiten von Kicad geärgert ("in Eagle 
könnte ich jetzt einfach..."). Jetzt ärgere ich mich über Eagle ("Boah, 
ist das umständlich"). Ich sollte aber vielleicht anmerken dass ich das 
aktuelle Eagle V8 nur kurz angetestet habe. Da hat sich ja einiges 
getan. Ich vergleiche hier Eagle V6.6 mit Kicad nightly.

Meiner Meinung nach reicht es nicht aus in einem ECAD Programm etwas 
herumzuklicken um sich eine Meinung dazu zu bilden. Dazu sind diese 
Systeme zu komplex. Man sollte sich schon die Mühe machen ein komplettes 
Design durchzuziehen. Dazu muss man auch in der Lage (und bereit) sein 
seine Komfortzone zu verlassen. Sonst kann man es gleich lassen.

[Rene K. (xdraconix)]

Also

Stefan schrieb:
> Meiner Meinung nach reicht es nicht aus in einem ECAD Programm etwas
> herumzuklicken um sich eine Meinung dazu zu bilden. Dazu sind diese
> Systeme zu komplex.

Ja keine Ahnung, aber genau so habe ich Eagle gelernt: mit klicken und 
probieren. Da müsste sogar der Thread hier noch irgendwo rumhuschen.

Ja das mit den FP ist halt so eine Sache. In Eagle suche ich mir ja mein 
Bauteil incl. FP und setze ihn auf. Das man dies im Nachhinein macht ist 
halt eine Umgewöhnung, ohne Frage.

Hab heut nochmal ne halbe Stunde "rumgespielt" und nun auch die FP 
zugewiesen und diese Liste ins PCB übernommen - da kam dann mein 
nächstes Problem: Wie zum Geier verschiebt man auf der Platine ein 
Bauteil?! Mit links und ziehen, geht nicht. Mit Rechts und "Verschieben" 
ploppt dann ein Fenster auf und sagt ich solle eine Referenz eingeben.

Heute Nachmittag mach ich mal ein Tut durch.

Ich denke aber auch das das anlernen ohne jegliche Vorkenntnisse 
wesentlichen einfacher ist als ein Umstieg.

Peter schrieb:
> Also von Altium kenne ich das nicht, hier hole ich die Änderungen immer
> über Design/Import Changes in die PCB.

Altium müsste ich lügen, dafür isses zu lange her. Aber bei Target ist 
es jedenfalls so. Gut, kann man nicht vergleichen.

Zum Thema Backanotation in Eagle: Ja gut, kann man sich wahrscheinlich 
drüber streiten: In meinen Augen ist es Segen und Fluch zugleich.

[KiCadSuperman (Gast)]

Vancouver schrieb:
> Hat jemand schon mal KiCAD für ein richtig komplexes Design verwendet?

Ja das geht ohne Probleme! Mit 12 Lagen mit und ohne Sacklöcher und mit
einen Platzierungsfaktor von 0,7. (1 = Platine voll bedeckt mit 
Bauteilen)
Das Problem ist nur man muss den richtigen Fertiger finden der das 
zufriedenstellen hinbekommt.

Bob A. schrieb:
> Aber das Beste ist: Ich hab heute ein altes Eagle-Projekt wieder
> anfassen müssen, und was soll ich sagen, nun kommt mir dort die
> Bedienung sehr komisch und nur wenig intuitiv vor lach
> Ich musste suchen um die Löschen-Funktion zu finden.

Das ist sehr amüsant zu lesen.

Ich kann mir vorstellen da wechseln jetzt Leute die hätten vor 1 Jahr
noch jeden KiCad Prediger auf dem Scheiterhaufen verbrannt :-(

[Chris D. (myfairtux) (Moderator)]

Rene K. schrieb:
> Wie zum Geier verschiebt man auf der Platine ein
> Bauteil?! Mit links und ziehen, geht nicht. Mit Rechts und "Verschieben"
> ploppt dann ein Fenster auf und sagt ich solle eine Referenz eingeben.

Siehe Kontext-Menu (Rechtsklick über dem Bauteil), und dort sind im 
Submenü die "Bewegungsarten" mit Hotkeys aufgelistet:

"M" (move) bewegt das Bauteil
"G" (drag) bewegt mit Leiterbahnen
usw.

Ja, ist anders, aber nicht schlechter - spätestens nach ein paar 
Platinen auf jeden Fall deutlich schneller als per Kontextmenü.

> Heute Nachmittag mach ich mal ein Tut durch.

Ja, das hilft sehr :-)

> Ich denke aber auch das das anlernen ohne jegliche Vorkenntnisse
> wesentlichen einfacher ist als ein Umstieg.

Da bin ich ziemlich sicher. Ähnliches habe ich auch beim Umstieg von 
Leuten von Windows auf Linux beobachtet.

[Max G. (l0wside)]

Bob A. schrieb:
> Aber das Beste ist: Ich hab heute ein altes Eagle-Projekt wieder
> anfassen müssen, und was soll ich sagen, nun kommt mir dort die
> Bedienung sehr sehr komisch und nur wenig intuitiv vor lach
> Ich musste suchen um die Löschen-Funktion zu finden. Und warum gibt es
> unterschiedlich Knöppe für Leiterbahn löschen und Andere Sachen löschen?

Ich habe vor einer Weile ein Projekt mit zwei Leiterplatten gemacht. 
Eine in KiCAD, die andere aus historischen Gründen noch in Eagle. Wenn 
man beides fast parallel benutzt, macht man sich echt einen Knoten ins 
Hirn.

Was in Eagle besser gelöst ist, ist die Anlage von irgendwelchen 
Kupferflächen (z.B. für Touchflächen). In KiCAD suche ich die geniale 
Lösung noch. Beim Highlighting hat beides seine Stärken und Schwächen.

Die Library-Konzepte sind in beiden Systemen eher mittelprächtig toll.

Insgesamt habe ich den Wechsel nicht bereut. Aber ich muss in jedem Fall 
Chris D. recht geben: nach einer Stunde kann man das nicht beurteilen. 
Mir half es enorm, ein bestehendes und bekanntes Eagle-Projekt zu 
importieren und daran weiterzuarbeiten.

[Rene (Gast)]

Stefan schrieb:
> Dazu sind diese
> Systeme zu komplex.

Da frage ich mich immer: Muß das sein? Für eine simple Platine könnte es 
so einfach sein. Aus einem ausreichenden Bauteilfundus Bauelemente auf 
die Platine ziehen, verbinden, fertig! In dieser Hinsicht lernte ich 
Eagle früher spielend. Für KiCad brauchts unbedingt Tutorials. Freilich, 
die Komplexität kommt auch mit den vielen Möglichkeiten. Aber: Das nicht 
unmittelbar benötigte muß doch nicht gleich so brachial in den 
Arbeitsablauf eingreifen daß man den mindestens halben Funktionsumfang 
schon am Anfang in einer steilen Lernkurve nehmen muß! KiCad ist in 
seinem Arbeitsablauf schon sehr festgelegt. Man muß sehr vieles gleich 
zu Beginn wissen um überhaupt zu einer simplen Platine zu gelangen. Was 
mich auch stört ist der altbackene Gerber-Output mit vielen Files. Das 
mag ja Industrie-Standard sein, aber warum geht das nicht einfach in 
einer einzigen Layout-Datei wie bei Eagle? So wie diese Frage gibt es 
derer viele. Man hat oft den Eindruck so ein System wird nicht aus 
Anwendersicht geschaffen sondern Entwickler gestalten ganz nach ihren 
Mitteln und Fähigkeiten.

[Noob A. (strippenzieher)]

Chris D. schrieb:
> "D" (drag) bewegt mit Leiterbahnen

klappt bei mir nicht, wünsche ich mir aber öfters :(

[Noob A. (strippenzieher)]

Rene schrieb:
> warum geht das nicht einfach in
> einer einzigen Layout-Datei

Ich bin mir fast sicher: würde KiCAD z.Bsp. eine .zip-Datei mit den 
Gerbers ausspucken, da würden dann Andere mosern...

[Max G. (l0wside)]

Rene schrieb:
> Was
> mich auch stört ist der altbackene Gerber-Output mit vielen Files. Das
> mag ja Industrie-Standard sein, aber warum geht das nicht einfach in
> einer einzigen Layout-Datei wie bei Eagle?

???
Gerber ist nun mal ein Satz an Dateien. Wenn ein Hersteller eine .brd 
akzeptiert, übernimmt er die Umwandlung von .brd nach Gerber für dich.
Es gibt genauso Hersteller, die auch .kicad_pcb akzeptieren. Versuche 
mal OSHPark.

[Chris D. (myfairtux) (Moderator)]

Rene schrieb:

> Was
> mich auch stört ist der altbackene Gerber-Output mit vielen Files. Das
> mag ja Industrie-Standard sein, aber warum geht das nicht einfach in
> einer einzigen Layout-Datei wie bei Eagle?

Wenn Dich die paar Dateien (von denen Du auch wählen kannst, welche 
überhaupt erzeugt werden sollen) stören, kannst Du sie doch einfach in 
eine ZIP-Datei packen. So werden die auch problemlos von Elecrow etc. 
akzeptiert.

Und genau aus dem von Dir genannten Grund gibt es bei KiCad Gerber: weil 
es eben Industriestandard ist und wirklich jeder Leiterplattenfertiger 
damit etwas anfangen kann.

Niemand benötigt noch ein proprietäres Format - es gibt eh schon mehr 
als genug.

[Jan L. (ranzcopter)]

Rene K. schrieb:
> nächstes Problem: Wie zum Geier verschiebt man auf der Platine ein
> Bauteil?! Mit links und ziehen, geht nicht. Mit Rechts und "Verschieben"
> ploppt dann ein Fenster auf und sagt ich solle eine Referenz eingeben.

...also nach der ersten Platine hatte ich irgendwann gemerkt, dass man 
"richtig" mit links in ein Bauteil klicken kann, um es danach mit links 
zu verschieben. Und das "richtig" heisst einfach, dass man zwar im 
Bereich des Bauteils klicke muss, aber ohne eines der Bestandteile wie 
"Referenz" oder "Silk" zu treffen. Erkennt man dann am "highlighting", 
geht oft nur bei passendem Zoomlevel, hab' mich a aber dran gewöhnt. Der 
Weg über Rechtsklick ist natürlich "sicherer", aber es sind halt ein 
paar Klicks mehr.

Btw, so richtig warm geworden bin ich mit Kicad erst nach dem Wechsel 
auf die "Nightlies".

Macken gibt's aber m.E. durchaus noch einige, und seien es nur die 
diversen Dateidialoge, die sich mal an "Normen" halten, und mal nicht.

[Michael R. (Firma: Brainit GmbH) (fisa)]

Weril ich mich aktuell grad wieder (mit Eagle) ärgere: Wie ist das 
Handling von Bauteilen mit unterschiedlichem pitch in Kicad?

Das raster umschalten geht in Eagle ja schnell, was ich mir wünsche wäre 
den "Raster-Nullpunkt" mal schnell auf die Mitte eines ICs zu 
verschieben, wenn ich in diesem Umfeld route. In Eagle plag ich mich da 
immer mit kgv-Rechnern, "move (>0 0) (62.5 125)" und ohne Taschenrechner 
daneben geht sowieso gar nix...

[Chris D. (myfairtux) (Moderator)]

Bob A. schrieb:
> Chris D. schrieb:
>> "D" (drag) bewegt mit Leiterbahnen
>
> klappt bei mir nicht, wünsche ich mir aber öfters :(

Ach Sorry, ist auch nicht "D", sondern "G" (siehe Kontext-Menü).

[Noob A. (strippenzieher)]

Chris D. schrieb:
> Bob A. schrieb:
>> Chris D. schrieb:
>>> "D" (drag) bewegt mit Leiterbahnen
>>
>> klappt bei mir nicht, wünsche ich mir aber öfters :(
>
> Ach Sorry, ist auch nicht "D", sondern "G" (siehe Kontext-Menü).

Nö, geht leider auch nicht...
Ist das in der 5.0er rausgeflogen? Da hat sich ja einiges geändert.

[Felix F. (wiesel8)]

Chris D. schrieb:
> Bob A. schrieb:
>> Chris D. schrieb:
>>> "D" (drag) bewegt mit Leiterbahnen
>>
>> klappt bei mir nicht, wünsche ich mir aber öfters :(
>
> Ach Sorry, ist auch nicht "D", sondern "G" (siehe Kontext-Menü).

Doch, 'd' ist für Drag bei Leiterbahnen. Funktioniert aber nur wenn du 
auch im "Leiterbahn verlegen Modus" bist (im OpenGl Canvas).

mfg

[Chris D. (myfairtux) (Moderator)]

Bob A. schrieb:
> Nö, geht leider auch nicht...
> Ist das in der 5.0er rausgeflogen? Da hat sich ja einiges geändert.

Hmmm, gute Frage, kann ich mir aber nicht vorstellen. Wir arbeiten hier 
noch mit 4.0.6.

Ich installiere nachher mal die neue parallel.

[Felix F. (wiesel8)]

Ich kann dieses Tutorial für Neueinsteiger empfehlen: 
http://docs.kicad-pcb.org/4.0.5/de/getting_started_in_kicad.pdf

Vorher dachte ich auch Kicad ist sche*ße. Danach war waren mir die 
Grundlagen klar und fand es deutlich besser als Eagle.

mfg

[Karl (Gast)]

Bob A. schrieb:
> Wieso Gebashe?

Das war nicht auf dich bezogen.

Rene K. schrieb:
> Ich habe mir das gerade mal angetan.

Rene K. schrieb:
> ruckelte es wie die Hulle.
> Am Rechner kann es eigentlich nicht liegen,

Rene K. schrieb:
> Entschuldigt bitte, aber bei allen anderen ECAD die mir so über den Weg
> gelaufen (Eagle, Target, Altium) sind öffne ich den PCB Editor und finde
> halt meine Bauteile da irgendwo auf dem Blatt die ich mir dann
> zurechtrücke und ich sie verbinden kann.
> Nach ca. ner Stunde insgesamt hab es dann erstmal wieder ausgemacht und
> sein lassen.

Rene K. schrieb:
> Ohne sich vorher erstmal in Tutorials einzulesen

Mimimi. Das meine ich. Ein CAD, egal ob E oder M, kann nicht intuitiv zu 
bedienen sein. Dafür ist die Sache zu komplex. Die Qualität zeigt sich 
dann an anderer Stelle, z.b. Tastaturshortcuts für alles wichtige. Oder 
einen p&s Router. Oder oder oder.

Die Diskussion über den gewohnten Workflow ist so lächerlich dass mir 
kein Wort dafür einfällt.

Andererseits fragt der Faden nach Erfahrungen... Bitte entschuldigt 
mich.
Wahrscheinlich bin ich voreingenommen weil kicad >> Eagle. Arbeite damit 
in der Arbeit. Gerade an 8 Lagen.

[Rene K. (xdraconix)]

Karl schrieb:
> Tastaturshortcuts für alles wichtige. Oder
> einen p&s Router.

Nuja gut, Tastaturshortcuts gibt es bei beiden - einstellbar - und P&S 
hat ja nun auch endlich bei Eagle Einzug gehalten. Das ist nun wirklich 
beides kein Kriterium das für oder wieder eines der beiden Systeme 
spricht.

Für mich es ist es schon wichtig das es einen gewissen Workflow gibt, 
das hat auch nichts mit "Mimimi" zu tun. Und ganz ehrlich, bis jetzt 
empfinde ich halt Eagle noch "einfacher" als halt KiCad - einfach weil 
es selbstklärender ist. Wie schon oben erwähnt wurde, muss solch ein 
ECAD nicht völlig überfüllt von Möglichkeiten sein - und ein separates 
Netzlisten System welches eigentlich nur dafür da ist von Programm A 
(EESHEMA) zu Programm B (PCBNew) zu übergeben ist halt ein Punkt der den 
Workflow nicht gerade zuträglich ist.

Dagegen steht dann aber wiederum bei EAGLE das, wenn ich ein FP eines 
Teiles ändere (Was übrigens bei Wechsel von z.b. 0805 auf 0603 ganz 
genau zwei Klicks sind) - das das Bauteil dann sofort wieder außerhalb 
des PCB platziert wird. Das ist dann bei Eagle wiederum nervig ohne 
Ende.


Karl schrieb:
> Die Qualität zeigt sich
> dann an anderer Stelle

Wenn ein CAD auf einer Workstation ruckelt? Qualitativ unwichtig? Eine 
hohe Einstiegshürde und enorme Lernkurve = Kosten für ein Unternehmen? 
Qualitativ unwichtig? Ein Programm aus vielen Einzelprogrammen gebastelt 
- wo man Paramterlisten übergeben muss? Qualitativ unwichtig? Kein 
fester Support? Qualitativ unwichtig?

Genau da sind die Punkte und nicht bei Shortcuts die man auch noch 
selbst belegen kann. P&S ließe ich natürlich bis V7 gelten, aber in der 
8er gibt es das ja nun.

Bis jetzt war es eine sachliche Diskussion über den Umstieg, den 
sicherlich einige gehen werden, auch ich. Belasse es bitte dabei. Es 
gibt schon genügend "EAGLE-KiCad-Bash-Threads" lass dich bitte dort aus.

[Franz R. (Gast)]

Ganz ehrlich KiCad und Eagle sind beide Scheisse.

Trotzdem benutze ich sie mangels Alternativen.
Es gibt halt nix besseres was Kostenfrei ist.

[Karl (Gast)]

Rene K. schrieb:
> Nuja gut, Tastaturshortcuts gibt es bei beiden - einstellbar - und P&S
> hat ja nun auch endlich bei Eagle Einzug gehalten. Das ist nun wirklich
> beides kein Kriterium das für oder wieder eines der beiden Systeme
> spricht.

Stimmt. Mein Umstieg ist schon länger her. Eagle 4.6 war das damals. 
Also auch noch bevor kicad push and shove konnte. Damals war es halt der 
online DRC.

Rene K. schrieb:
> Für mich es ist es schon wichtig das es einen gewissen Workflow gibt,
> das hat auch nichts mit "Mimimi" zu tun.

Doch genau das hat es. Du willst "deinen" Workflow behalten. OK. Bleib 
dabei. Aber Kreide es nicht einem anderen CAD an, dass es nicht Eagle 
ist...

Rene K. schrieb:
> einfach weil es selbstklärender ist

Das muss und will es nicht sein.

Rene K. schrieb:
> Wenn ein CAD auf einer Workstation ruckelt? Qualitativ unwichtig?
Nein. Deine Ausdrucksweise nervt mich.
Eine
> hohe Einstiegshürde und enorme Lernkurve = Kosten für ein Unternehmen?
> Qualitativ unwichtig?
Bla bla. Warum hat es mich damals genau zehn Minuten gekostet das erste 
Projektchen zusamnenzuklicken? Mit weniger Tutorials. Weil ich es lernen 
wollte. Das ist der Unterschied zu "eine Stunde lustlos rumklicken".
 Ein Programm aus vielen Einzelprogrammen gebastelt
> - wo man Paramterlisten übergeben muss? Qualitativ unwichtig?
Bla. Das sind zwei Mausklicks und drei Mal enter.
 Kein
> fester Support? Qualitativ unwichtig?
Durchaus nicht. Wer auf Support angewiesen ist, vergleicht nicht 
unbedingt Eagle mit kicad. Das ist doch eher Hobby und 
Gelegenheitsarbeit, bei der sich ein Profi CAD nicht lohnt.

Rene K. schrieb:
> Bis jetzt war es eine sachliche Diskussion über den Umstieg, den
> sicherlich einige gehen werden, auch ich. Belasse es bitte dabei.

?Nö. In jedem thread das gleiche Lied. Eagle ist nicht kicad aber ich 
habs auch nicht ernsthaft probiert. So geht der Refrain.

[W.S. (Gast)]

Rene schrieb:
> Man hat oft den Eindruck so ein System wird nicht aus
> Anwendersicht geschaffen sondern Entwickler gestalten ganz nach ihren
> Mitteln und Fähigkeiten.

Tja, meine Rede seit langem.



Chris D. schrieb:
> "M" (move) bewegt das Bauteil
> "G" (drag) bewegt mit Leiterbahnen
> usw.
>
> Ja, ist anders, aber nicht schlechter

Nö.

Ist anders UND schlechter.

Wenn man auch jetzt noch mit dem Move die Netze und Leiterzüge abreißt, 
WOZU soll dieses Kommando dann eigentlich gut sein? Zum Stiften von 
Designfehlern? Mein Vorschlag: das M Kommando entfernen und das G 
Kommando in M umbenennen. Hätte schon längst erledigt sein können.

Nein Chris, ich lese hier wenn es um Kicad geht, immer wieder, daß es ja 
SOOO komplex sei und man genau DESHALB zuerst ganz viel lernen müsse, 
bis man in der Lage ist, es zu benutzen. Im Klartext heißt das ganze 
Geschafel von der steilen Lernkurve, daß das Produkt eben bloß schlecht 
konstruiert ist. Das ist alles, was man dazu noch sagen kann.

Genau DAS ist eben mal wieder die eingeschränkte Sicht der 
Programmierer, die ihr Produkt eben nicht aus Sicht des Benutzers sehen 
bzw. sehen wollen. Ich sag dazu nur eines: Im Grunde soll die Maschine 
dem Menschen dienen und nicht umgekehrt. Und dazu soll ein Programm eben 
nach den bedürfnissen des benutzers konstruiert sein und nicht der 
Benutzer nach den Bedürfnissen eines Programmes.


Bob A. schrieb:
> wäre halt schon cool wenn man wüsste was die beim CERN damit
> anstellen...

Da kann ich nen Beitrag liefern: Die benutzen Kicad und zugleich auch.. 
- nun bei einem Treffen vor geraumer Zeit hat einer meiner 
Ex-Kommilitonen sich heftig über die miserable Qualität der deutschen 
Leiterplattenhersteller beklagt. Die lieferten ihm nie das, was er an 
realer Leiterplatte haben wollte. So war das.

Nun, bei meinen LP beachte ich die Constraints der Hersteller und bin 
bislang immer gut bedient worden. So verschieden kann das sein.

W.S.

[Ralf G. (ralg)]

Rene K. schrieb:
> Dagegen steht dann aber wiederum bei EAGLE das, wenn ich ein FP eines
> Teiles ändere (Was übrigens bei Wechsel von z.b. 0805 auf 0603 ganz
> genau zwei Klicks sind) - das das Bauteil dann sofort wieder außerhalb
> des PCB platziert wird. Das ist dann bei Eagle wiederum nervig ohne
> Ende.
Da wechselt man auf dem Board nur das Package. Da wird nichts 
verschoben!?

[Chris D. (myfairtux) (Moderator)]

W.S. schrieb:
> Nö.
> Ist anders UND schlechter.
> Wenn man auch jetzt noch mit dem Move die Netze und Leiterzüge abreißt,
> WOZU soll dieses Kommando dann eigentlich gut sein? Zum Stiften von
> Designfehlern? Mein Vorschlag: das M Kommando entfernen und das G
> Kommando in M umbenennen. Hätte schon längst erledigt sein können.

Es kommt durchaus vor, dass man die Leiterbahnen gerne so liegen lassen 
möchte wie sie waren und von den "abgerissenen" Enden selbst 
weiterrouten möchte (hatte ich bei unserem letzten PCB) . Nur weil man 
selbst es nicht benötigt ist ein Feature nicht direkt sinnlos.

Die beiden Kommandos sind also durchaus sinnvoll.

Wenn es Dich stört, ist die Änderung nun wirklich einfach. Du änderst 
den Hotkey für Drag einfach von "G" auf "M" und löscht den von Move und 
speicherst die Änderungen ab. Wo ist das Problem?

W.S. schrieb:
> Nein Chris, ich lese hier wenn es um Kicad geht, immer wieder, daß es ja
> SOOO komplex sei und man genau DESHALB zuerst ganz viel lernen müsse,
> bis man in der Lage ist, es zu benutzen. Im Klartext heißt das ganze
> Geschafel von der steilen Lernkurve, daß das Produkt eben bloß schlecht
> konstruiert ist. Das ist alles, was man dazu noch sagen kann.

Dass es komplex sei und man so viel lernen müsse, liest man nur von 
denjenigen, die das hier schreiben. Das ist aber immer so: die, die zu 
meckern haben, tun das deutlich lauter als die, die zufrieden sind.
Und wer die negativen Berichte über Eagle hier zählt, muss das für eine 
grottenschlechte Software halten. Was genau so falsch ist.

Das ist also kein Maßstab - insbesondere, wenn man vorher Eagle 
benutzte.
Da hat man nämlich auch nicht einfach so angefangen (ich weiß das noch 
gut von mir selbst), sondern die Lernkurve war entsprechend steinig.

Aber: man wollte es und hatte auch keine andere Wahl, denn es gab kaum 
andere Software.

Jetzt ist das anders: man hat Eagle, kommt damit zurecht, und probiert 
eine neue Software aus, aber nicht weil man muss sondern weil man 
einfach mal gucken möchte oder die beschränkte Platinengröße der 
kostenlosen Version nicht mehr reicht.

Zusätzlich ist man vom Ablauf her auf Eagle geprägt.

Natürlich schmeisst man da eher hin und denkt: "Mist!".

Der OP beschreibt das Phänomen ja selbst sehr gut:

Bob A. schrieb:
> Aber das Beste ist: Ich hab heute ein altes Eagle-Projekt wieder
> anfassen müssen, und was soll ich sagen, nun kommt mir dort die
> Bedienung sehr sehr komisch und nur wenig intuitiv vor lach
> Ich musste suchen um die Löschen-Funktion zu finden. Und warum gibt es
> unterschiedlich Knöppe für Leiterbahn löschen und Andere Sachen löschen?

Man sieht - das gibt es auch genau anders herum - von einem ehemaligen 
Eagle-Nutzer.

> Genau DAS ist eben mal wieder die eingeschränkte Sicht der
> Programmierer, die ihr Produkt eben nicht aus Sicht des Benutzers sehen
> bzw. sehen wollen. Ich sag dazu nur eines: Im Grunde soll die Maschine
> dem Menschen dienen und nicht umgekehrt. Und dazu soll ein Programm eben
> nach den bedürfnissen des benutzers konstruiert sein und nicht der
> Benutzer nach den Bedürfnissen eines Programmes.

Wir kommen hier seit vielen Jahren problemlos mit KiCad zurecht und 
setzen es professionell ein, es erfüllt also durchaus die Bedürfnisse 
seiner Nutzer.

Man muss den Umstieg aber auch wirklich wollen - das ist der Grund, 
warum die meisten Leute meckern und hinschmeißen.

(Das ist dasselbe wie beim Wechsel von MS Office zu bspw. OpenOffice. OO 
kann dasselbe wie MS Office, aber manche Dinge werden eben anders 
gemacht. Ebenso Windows -> Linux.  Da muss man sich umstellen. Habe ich 
damals gemacht und es funktioniert sehr gut. Und ich habe dadurch 
mittlerweile einen Haufen Geld gespart - bei gleicher oder mehr 
Leistung.)

Man gewöhnt sich an Dinge, die KiCad schon einige Zeit bietet (P&S, 
differential Routing, Echtzeit-3D-Darstellung usw.). Diese Dinge 
ersparen einfach sehr viel Zeit und hier damit Geld. Es ist schon länger 
einfach Stand der Technik, dass man ein 3D-Modell seiner Platine hat und 
das einfach in sein CAD-System übernehmen kann, um direkt das Gehäuse zu 
designen (oder umgekehrt).

Ich bin damals allerdings zu KiCad gewechselt, weil Eagle keine 
hierarchischen Schaltpläne beherrschte - und auch wegen der 
Versionspolitik von CadSoft. Immer wieder wurde man vertröstet und es 
passierte: nix. Wann kamen dann Schaltplanhierarchien? Sehr viele Jahre 
später. Gut, dass ich nicht gewartet hab. Und wie man hier gut nachlesen 
kann, passierte in den letzten Versionen vor der Übernahme außer neuen 
Icons nicht wirklich viel.

Eagle zieht mir schon zu lange immer nur (äußerst schleppend) nach.

Warum also sollte jemand bei Eagle bleiben oder auch dahin wechseln, 
wenn der Funktionsumfang bei KiCad zumindest gleich bzw. deutlich höher 
ist und ich es kostenfrei und unbegrenzt nutzen kann, egal ob AutoDesk 
Pleite geht, es einstampft oder irgendwelche Server ausfallen?

Ich habe mir gerade mal die Lizenzbedingungen für das Abo angesehen, 
weil hier immer von der Premium-Version die Rede war. Das ist eine 
Einzelplatzlizenz mit Single-User-Zugriff. Das heisst, ich würde hier 
mindestens zwei Lizenzen benötigen,d h. doppelte Kosten.

Das Geld stecke ich dann doch lieber in neue Maschinen, Messgeräte und 
günstigere Preise gegenüber der proprietär lizenzierten Konkurrenz :-)

Ich sehe bei Eagle schlicht keinen Mehrwert gegenüber KiCad.

Bezüglich des OP kann ich sagen:
Ja, der Umstieg von Eagle nach KiCad ist gut machbar, aber man muss es 
auch wollen und nicht nur mal eben installieren und etwas rumklicken.

[Noob A. (strippenzieher)]

W.S. schrieb:
>> wäre halt schon cool wenn man wüsste was die beim CERN damit
>> anstellen...
>
> Da kann ich nen Beitrag liefern: Die benutzen Kicad und zugleich auch..
> - nun bei einem Treffen vor geraumer Zeit hat einer meiner
> Ex-Kommilitonen sich heftig über die miserable Qualität der deutschen
> Leiterplattenhersteller beklagt. Die lieferten ihm nie das, was er an
> realer Leiterplatte haben wollte. So war das.
>
> Nun, bei meinen LP beachte ich die Constraints der Hersteller und bin
> bislang immer gut bedient worden. So verschieden kann das sein.
>
> W.S.

Ist da etwas Text im ewigen Daten-Nirvana verloren gegangen?

und zugleich auch was?? Kaffeemaschinen? Abisolierzangen? 
V8-betriebene Smoothie-Maker? ;-))

Wo ist da der Bezug zur Leiterplattenherstellung? Das kommt irgendwie 
abrupt aus dem Nichts...
Aber: schön wenn Du alles richtig machst, hat das dein Ex-Kommilitone 
nicht? Oder gibt es evtl. einen anderen Grund für die Diskrepanz 
Layoutdaten <-> reelle Leiterplatte?

Wenige Sätze, viele Fragen...

[Karl (Gast)]

Chris D. schrieb:
> Warum also sollte jemand bei Eagle bleiben oder auch dahin wechseln,
> wenn der Funktionsumfang bei KiCad zumindest gleich bzw. deutlich höher
> ist

Also mal Butter bei die Fische: Kann ich in Kicad für ein Bauteil auf 
dem Board im Boardeditor das Footprint ändern, und das wird ins 
Schematic übernommen, so dass auch Kopien dieses Bauteils dann dieses 
Footprint haben? Werden geänderte Bauteilbezeichnungen, Bauteilwerte vom 
Board ins Schematic übernommen?

Meines Wissen wurde FB-Anno lange abgelehnt wegen "brauch mer nich".

[Possetitjel (Gast)]

Karl schrieb:

> Also mal Butter bei die Fische: Kann ich in Kicad
> für ein Bauteil auf dem Board im Boardeditor das
> Footprint ändern, und das wird ins Schematic
> übernommen, so dass auch Kopien dieses Bauteils
> dann dieses Footprint haben?

Kannst Du im Restaurant das von Dir bestellte Steak
nachwürzen, so dass dann alle anderen Exemplare
dieses Gerichtes auch nachgewürzt sind?


> Werden geänderte Bauteilbezeichnungen, Bauteilwerte
> vom Board ins Schematic übernommen?

Wird die neue Würzmischung automatisch in das Rezept
übernommen, das der Koch befolgt?


> Meines Wissen wurde FB-Anno lange abgelehnt wegen
> "brauch mer nich".

Bist Du sicher?
Mein Ablehungsgrund wäre "grausames Bedienkonzept".

[Michael R. (Firma: Brainit GmbH) (fisa)]

Possetitjel schrieb:
> Kannst Du im Restaurant das von Dir bestellte Steak
> nachwürzen, so dass dann alle anderen Exemplare
> dieses Gerichtes auch nachgewürzt sind?

das ist jetzt aber schon sehr sehr an den Haaren herbeigezogen, oder?

ich persönlich würde FB-Anno vermissen, und halte es NICHT für ein 
grausames Bedienkonzept, ganz im Gegenteil.

[Possetitjel (Gast)]

Michael R. schrieb:
> Possetitjel schrieb:
>> Kannst Du im Restaurant das von Dir bestellte Steak
>> nachwürzen, so dass dann alle anderen Exemplare
>> dieses Gerichtes auch nachgewürzt sind?
>
> das ist jetzt aber schon sehr sehr an den Haaren
> herbeigezogen, oder?

Findest Du? :)


> ich persönlich würde FB-Anno vermissen, und halte
> es NICHT für ein grausames Bedienkonzept, ganz im
> Gegenteil.

Zugestanden.

Der Punkt ist: Jedem konkreten Arbeitsablauf liegt
immer auch eine (implizite oder explizite) Vorstellung
über die Dinge zu Grunde, die in diesem Ablauf
bearbeitet werden.
Manche dieser Vorstellungen widersprechen sich logisch;
deswegen sind die Arbeitsabläufe dann nicht wirklich
kompatibel.

Der Programmierer hat jetzt zwei Möglichkeiten: Entweder
er entscheidet sich für ein Universum, dann kann er das
konsistent implementieren, aber er schließt die Abläufe
m.o.w. aus, die damit nicht kompatibel sind.
Oder er entscheidet sich nicht für ein Universum, sondern
versucht, eine Obermenge zu implementieren, die mit allem
kompatibel ist, dann wird sein Programm ein mehr oder
weniger unsortierter Werkzeugkasten, mit dem alles
"irgendwie", aber nix wirklich gut geht.

Wer sich für die erste Variante entscheidet, ist deswegen
nicht dümmer oder rückständiger als andere Leute -- er hat
einfach nur eine andere Meinung zum Thema!

Deswegen hat die Kritik, Programm X verfüge nicht über
Funktion Y, für mich immer den Anstrich von kleinkindlichem
Gestänkere, denn die wirklich wichtigen Fragen
- Verfolgt Programm X eine bestimmte Bedienphilosophie?
- Ist Funktion Y mit dieser Philosophie verträglich?
- Warum benötige ich Funktion Y?
- Ist mein Arbeitsablauf mit Programm X verträglich?
werden weder gestellt noch beantwortet.

Sollte sich nämlich herausstellen, dass ich Funktion Y
benötige, weil ich einen Arbeitsablauf bevorzuge, der dem
Konzept von Programm X widerspricht, dann könnte ich die
Schuld ja nicht auf Programm X abschieben -- und DAS geht
ja nun GAR NICHT! :/

[Karl (Gast)]

Possetitjel schrieb:
> Kannst Du im Restaurant das von Dir bestellte Steak
> nachwürzen, so dass dann alle anderen Exemplare
> dieses Gerichtes auch nachgewürzt sind?

Kannst Du ein noch bekloppteres Beispiel finden?

Ich habe eine Baugruppe. Beim Routing stelle ich fest, dass sich andere 
Gehäuseformen sinnvoller machen, zum Beispiel ein Widerstand im RM15 
statt RM10, um noch ein paar Leitungen durchzubekommen oder 
Isolationsabstände einzuhalten.

Natürlich will ich diese Änderungen auch im Schaltplan haben, und wenn 
ich diese Baugruppe kopiere, sollen alle Bauteile der neuen Baugruppe 
auch die geänderten Footprints haben.

Ich verwende oft Schaltungsteile woanders wieder, oder erstelle eine 
neue Version einer Schaltung. Da will ich nicht jedesmal wieder die 
Footprints neu zuweisen müssen.

Das ist so diese typische "works for me" Denke: Was ich nicht brauche, 
brauchen andere auch nicht.

[Noob A. (strippenzieher)]

Karl schrieb:
> Natürlich will ich diese Änderungen auch im Schaltplan haben

Na dann mach die Änderung doch dort...

Karl schrieb:
> und wenn
> ich diese Baugruppe kopiere, sollen alle Bauteile der neuen Baugruppe
> auch die geänderten Footprints haben.

Wo ist das Problem? Ich kann mir kein Programm vorstellen dass beim 
Kopieren Teile der Daten auf einen vorherigen Stand zurücksetzt...
Wirkt mir auch wie ein bescheidenes Beispiel deinerseits ;-)

Karl schrieb:
> Ich verwende oft Schaltungsteile woanders wieder, oder erstelle eine
> neue Version einer Schaltung. Da will ich nicht jedesmal wieder die
> Footprints neu zuweisen müssen.

Außer ich irre mich, ist das gerade bei KiCad durchaus elegant gelöst. 
Habe das zwar noch nicht selber ausprobiert, mich aber etwas eingelesen. 
Vielleicht kann das jemand mit mehr Erfahrung bestätigen?

Karl schrieb:
> Das ist so diese typische "works for me" Denke: Was ich nicht brauche,
> brauchen andere auch nicht.

Geht auch so: Was ich bevorzuge, müssen auch andere toll finden.

Frage: Hast Du schonmal ernsthaft mit KiCad versucht zu arbeiten?
Ich hab mich am Anfang genau so schwer getan und stur gestellt, 
mittlerweile bin ich froh dass ich dran geblieben bin!

[Karl (Gast)]

Bob A. schrieb:
> Na dann mach die Änderung doch dort...

Das man ein Bauteil beim Layouten direkt im Boardeditor ändert, und 
nicht erst auf den Schaltplaneditor wechselt, das Bauteil sucht, ändert, 
und die Änderung wieder in den Boardeditor übernimmt ist sooo abwegig?

Workflow?

[Possetitjel (Gast)]

Karl schrieb:

> Possetitjel schrieb:
>> Kannst Du im Restaurant das von Dir bestellte Steak
>> nachwürzen, so dass dann alle anderen Exemplare
>> dieses Gerichtes auch nachgewürzt sind?
>
> Kannst Du ein noch bekloppteres Beispiel finden?

Falls Dir das wichtig sein sollte, kann ich es
versuchen.


> Ich habe eine Baugruppe. Beim Routing stelle ich fest,
> dass sich andere Gehäuseformen sinnvoller machen, zum
> Beispiel ein Widerstand im RM15 statt RM10, um noch ein
> paar Leitungen durchzubekommen oder Isolationsabstände
> einzuhalten.

Okay.


> Natürlich will ich diese Änderungen auch im Schaltplan
> haben, und wenn ich diese Baugruppe kopiere, sollen
> alle Bauteile der neuen Baugruppe auch die geänderten
> Footprints haben.

Stop.

Erste Bemerkung: Wenn ich eine Größe, die in den Schalt-
plan gehört, ändern will, dann gehe ich in den Schaltplan-
editor und ändere sie dort. Ich verlange nicht, dass ich
den SCHALTplan mit dem LAYOUTeditor modifizieren kann.

Zweite Bemerkung: Der Footprint hat (logisch) gar nix
im Schaltplan zu suchen; das ist eine Angabe, die in die
STÜCKLISTE gehört.
Aus mir rätselhaften Gründen gibt es weite Teile der
EDA-Welt, die sich standhaft weigern, die Stückliste als
gleichberechtigte Fertigungsunterlage neben z.B. dem
Schaltplan und dem Layout anzusehen.


> Ich verwende oft Schaltungsteile woanders wieder, oder
> erstelle eine neue Version einer Schaltung. Da will
> ich nicht jedesmal wieder die Footprints neu zuweisen
> müssen.

Das verstehe und akzeptiere ich.

Komponenten rekursiv aus anderen Komponenten zusammen-
zusetzen führt auf eine Baumstruktur oder eine Halb-
ordnung. Bäume bilden Hierarchien ab.

Du meckerst über fehlende feedback annotation, beschreibst
aber hierarchisches Schaltplandesign. Findest Du das
logisch?


> Das ist so diese typische "works for me" Denke: Was
> ich nicht brauche, brauchen andere auch nicht.

Möchtest Du diesen Vorwurf vielleicht nochmal überdenken?

[Possetitjel (Gast)]

Karl schrieb:

> Das man ein Bauteil beim Layouten direkt im Boardeditor
> ändert, und nicht erst auf den Schaltplaneditor wechselt,
> das Bauteil sucht, ändert, und die Änderung wieder in
> den Boardeditor übernimmt ist sooo abwegig?

Deine Idee ist keineswegs abwegig.

Aber nicht alles, was "nicht abwegig" ist, ist deswegen
schon gleich sinnvoll.

[Noob A. (strippenzieher)]

Karl schrieb:
> Das man ein Bauteil beim Layouten direkt im Boardeditor ändert, und
> nicht erst auf den Schaltplaneditor wechselt, das Bauteil sucht, ändert,
> und die Änderung wieder in den Boardeditor übernimmt ist sooo abwegig?

Nö, aber nicht wirklich logisch.
Der Layout-Editor ist dazu da die Teile zu platzieren und zu verbinden.
Wäre für mich "nice to have", aber sicher kein Ausschlusskriterium.

Komischerweise lese ich von den Gegner nie was zu tatsächlichen 
Schwächen (gibt einige...) von KiCad, sondern nur irgendwas was eagle 
kann und KiCad nicht...

[Possetitjel (Gast)]

Bob A. schrieb:

> Karl schrieb:
>> und wenn ich diese Baugruppe kopiere, sollen alle
>> Bauteile der neuen Baugruppe auch die geänderten
>> Footprints haben.
>
> Wo ist das Problem? Ich kann mir kein Programm vorstellen
> dass beim Kopieren Teile der Daten auf einen vorherigen
> Stand zurücksetzt...

Das nicht -- aber es kann andere Daten kopieren, als der
Nutzer GLAUBT, das kopiert werden...


> Wirkt mir auch wie ein bescheidenes Beispiel deinerseits ;-)

Nein, nicht unbedingt.

Vielleicht ist das nicht exakt das Gleiche, aber ich hatte
solche Probleme vor vielen Jahren auch mit OrCAD: Änderungen
sind aus für mich nicht nachvollziehbaren Gründen nicht in
abgeleitete Versionen der Baugruppe übernommen worden. Ich
habe nie wirklich verstanden, wann welche Änderung in welches
Exemplar übernommen wird.
Letztlich hatte ich nicht begriffen, wie die Projektverwaltung
dort funktioniert. (Später habe ich dann gelernt, dass mein
Vorgänger genau dieselben Schwierigkeiten hatte.)

[Karl (Gast)]

Possetitjel schrieb:
> Aber nicht alles, was "nicht abwegig" ist, ist deswegen
> schon gleich sinnvoll.

Ich fand es jetzt 18 Jahre lang sinnvoll.

Der Witz ist doch: Ich habe einfach gefragt: Gibt es diese Möglichkeit 
in Kicad inzwischen? Und statt einfach zu sagen, nein es geht nicht, 
wird mir lang und breit erklärt, warum ich das nicht brauche.

[Noob A. (strippenzieher)]

Ok, bei dem Thema sollte ich mich dann besser ausklinken weil ich derlei 
noch nie selber genutzt habe.
Sorry wenn ich da jetzt aus Unwissen blöd reingegrätscht habe

[Noob A. (strippenzieher)]

Karl schrieb:
> Der Witz ist doch: Ich habe einfach gefragt: Gibt es diese Möglichkeit
> in Kicad inzwischen? Und statt einfach zu sagen, nein es geht nicht,
> wird mir lang und breit erklärt, warum ich das nicht brauche.

Vielleicht weil es jemand Anderem schwer fällt nachzuvollziehen wieso 
diese Funktion ein Ausschlusskriterium für ein durchaus brauchbares 
Alternativprogramm sein soll?

[Karl (Gast)]

Possetitjel schrieb:
> Komponenten rekursiv aus anderen Komponenten zusammen-
> zusetzen führt auf eine Baumstruktur oder eine Halb-
> ordnung. Bäume bilden Hierarchien ab.

Nein, ich übernehme nicht Komponenten rekursiv. Ich übernehme Baugruppen 
als eigenständige Kopie und Änderungen in dieser Kopie bleiben auch in 
dieser Kopie.

Warum soll ich einen gern verwendeten Schaltregler nebst Beschaltung 
jedesmal neu zeichnen, wenn ich ihn in einem anderen Projekt einsetzen 
will. Und warum sollte ich ihm dann jedesmal die Footprints neu 
zuweisen, die passende Spule und Diode raussuchen...

Oder ATmegas mit Standardbeschaltung: Quarz, Abblockkondensatoren, 
SPI-Stecker werden einfach übernommen und die zum Projekt passende 
Peripherie drumrumgebaut. Da muss ich nicht jedesmal mit einem weissen 
Blatt anfangen. Praktisch, das Board wird auch übernommen und enthält 
gleich Standardmaße, Standardbohrungen.

[Noob A. (strippenzieher)]

Karl schrieb:
> Ich übernehme Baugruppen
> als eigenständige Kopie und Änderungen in dieser Kopie bleiben auch in
> dieser Kopie.

Nun bin ich doch verwirrt... wolltest Du vorhin nicht dass sich die 
Kopie mitändert?

Das Konzept an sich finde ich super!

[Michael R. (Firma: Brainit GmbH) (fisa)]

Possetitjel schrieb:
> Zweite Bemerkung: Der Footprint hat (logisch) gar nix
> im Schaltplan zu suchen; das ist eine Angabe, die in die
> STÜCKLISTE gehört.

ich würde sie mehr im Layout sehen als in der Stückliste; aber sie ist 
durchaus auch im Schaltplan relevant, sogar sehr: Der Footprint gibt 
nämlich auch Eigenschaften (zB Rth, Leistung) vor, welche bereits im 
Schaltplan definiert werden (müssen).

> Aus mir rätselhaften Gründen gibt es weite Teile der
> EDA-Welt, die sich standhaft weigern, die Stückliste als
> gleichberechtigte Fertigungsunterlage neben z.B. dem
> Schaltplan und dem Layout anzusehen.

In welcher (EDA-)Welt lebst du? ich kenne niemanden der Stücklisten 
ignoriert; irgendwo müssen die bauteile ja auch herkommen (aka bestellt 
werden)

[Possetitjel (Gast)]

Karl schrieb:

> Possetitjel schrieb:
>> Aber nicht alles, was "nicht abwegig" ist, ist deswegen
>> schon gleich sinnvoll.
>
> Ich fand es jetzt 18 Jahre lang sinnvoll.

Ist ja in Ordnung; das sei Dir zugestanden.


> Der Witz ist doch: Ich habe einfach gefragt: Gibt es
> diese Möglichkeit in Kicad inzwischen? Und statt einfach
> zu sagen, nein es geht nicht, wird mir lang und breit
> erklärt, warum ich das nicht brauche.

Nun, nicht ganz.

Zum einen:
Du hast zwar gefragt, ob es das gibt, dann aber mit der
Bemerkung geschlossen:

  > Meines Wissen wurde FB-Anno lange abgelehnt wegen
  > "brauch mer nich".

Das "brauch mer nich" unterstellt den KiCAD-Leuten durchaus
eine gewisse Ignoranz gegenüber berechtigten Wünschen der
Nutzer. Das war der Seitenhieb, der mich getriggert hat.

Zum anderen:
Ich bedauere, aber ich halte Dich und Deine Wünsche nicht
für den Nabel der Welt. Ich habe Dir nicht erklären wollen,
warum DU das nicht brauchst.
Ich habe eine alternative Erklärung vorschlagen wollen,
warum die KiCAD-Leute es nicht implementiert haben:
Vielleicht waren sie ganz einfach der Meinung, es füge
sich nicht logisch in das Bedienkonzept von KiCAD ein?

Wäre das denkbar?

[Possetitjel (Gast)]

Karl schrieb:

> Ich übernehme Baugruppen als eigenständige Kopie und
> Änderungen in dieser Kopie bleiben auch in dieser
> Kopie.

Ja; ich glaube, ich habe Dich verstanden.

Der Punkt ist: Sobald Baugrauppen nicht AUSSCHLIESZLICH
aus aus Bauteilen bestehen müssen, sondern auch Baugruppen
als Bestandteile enthalten können, IST das rekursiv.
Es ENTSTEHT eine Hierarchie -- ob Dir das gefällt oder
nicht.


> Warum soll ich einen gern verwendeten Schaltregler
> nebst Beschaltung jedesmal neu zeichnen, wenn ich ihn
> in einem anderen Projekt einsetzen will. Und warum
> sollte ich ihm dann jedesmal die Footprints neu
> zuweisen, die passende Spule und Diode raussuchen...

Nein -- warum solltest Du das müssen?

Ich verstehe nur nicht, was das mit feedback annotation
zu tun hat.
Der Wunsch, Baugruppen aus (selbstentwickelten oder von
außen übernommenen) Teilbaugruppen zusammensetzen zu
wollen, ist mir völlig verständlich, und natürlich
müssen alle zur vollständigen Beschreibung der "Muster-
baugruppe" notwendigen Daten (Stückliste, Schaltplan,
Layout) gemeinsam übernommen werden.

Wieso ist es dazu zwingend erforderlich, den Footprint
im Layouteditor zu ändern?


> Oder ATmegas mit Standardbeschaltung: Quarz,
> Abblockkondensatoren, SPI-Stecker werden einfach
> übernommen und die zum Projekt passende Peripherie
> drumrumgebaut. Da muss ich nicht jedesmal mit einem
> weissen Blatt anfangen. Praktisch, das Board wird
> auch übernommen und enthält gleich Standardmaße,
> Standardbohrungen.

Ja, ich verstehe, was Du erreichen möchtest. Ich sehe
nur den Zusammenhang zur fehlenden feedback annotation
nicht. (Wahrscheinlich haben die Begriffe bei Eagle
eine bestimmte Bedeutung, die ich nicht kenne.)

[Possetitjel (Gast)]

Michael R. schrieb:

> Possetitjel schrieb:
>> Zweite Bemerkung: Der Footprint hat (logisch) gar nix
>> im Schaltplan zu suchen; das ist eine Angabe, die in die
>> STÜCKLISTE gehört.
>
> ich würde sie mehr im Layout sehen als in der Stückliste;
> aber sie ist durchaus auch im Schaltplan relevant, sogar
> sehr: Der Footprint gibt nämlich auch Eigenschaften (zB
> Rth, Leistung) vor, welche bereits im Schaltplan definiert
> werden (müssen).

Hmmja... ich mag Dir nicht direkt widersprechen, aber ich
sehe (schon seit längerem) die Gefahr, dass der Schaltplan
(aus alter Gewohnheit) mit zahlreichen Daten überfrachtet
wird, die sich im Schaltplan nicht optimal abbilden lassen.

Ich würde z.B. die zulässige Verlustleistung als "nicht-
funktionale Eigenschaft" eines Widerstandes ansehen, die
deswegen nicht in den Schaltplan gehört, weil sie nicht
die Schaltungsfunktion unmittelbar beeinflusst, sondern
"nur" die Überlebensdauer des Bauteiles selbst.

Auch z.B. für hochintegrierte Bauteile wie Mikrocontroller
ist der Schaltplan suboptimal. Das ist aber ein weites
Feld, und man muss meine Meinung nicht teilen.


>> Aus mir rätselhaften Gründen gibt es weite Teile der
>> EDA-Welt, die sich standhaft weigern, die Stückliste als
>> gleichberechtigte Fertigungsunterlage neben z.B. dem
>> Schaltplan und dem Layout anzusehen.
>
> In welcher (EDA-)Welt lebst du?

Ich bin ein Außerirdischer, der auf der Erde Fuß zu fassen
versucht.


> ich kenne niemanden der Stücklisten ignoriert; irgendwo
> müssen die bauteile ja auch herkommen (aka bestellt
> werden)

Nein, "ignorieren" nicht -- aber ich bin schon der Meinung,
dass das Thema umfassend unterschätzt wird.
Der Schwerpunkt "Bauteildatenbank" ist im Prinzip genauso
groß und genauso wichtig wie der Schaltplan oder das
Layout; die reine Stückliste ist nur ein Teilaspekt davon.

[Karl (Gast)]

Possetitjel schrieb:
> Ich sehe
> nur den Zusammenhang zur fehlenden feedback annotation
> nicht. (Wahrscheinlich haben die Begriffe bei Eagle
> eine bestimmte Bedeutung, die ich nicht kenne.)

FB heisst Forward-Backward-Annotation: Änderungen im Schaltplan werden 
sofort im Layout sichtbar, Änderungen im Layout (Footprints, Namen, 
Bauteilwerte) werden sofort in den Schaltplan übernommen.

Zum Beispiel gibt es die Möglichkeit, im Layout sämtliche Bauteile der 
Position nach umzunummerieren, so dass man sie leichter findet. Diese 
geänderten Namen müssen natürlich auch in den Schaltplan übernommen 
werden. Eine Funktion, die ich zugegeben nur bei größeren Platinen 
nutze.

Für mich entscheidend: Board und Schematic müssen konsistent sein. Es 
geht nicht, dass ich im Board ein anderes Footprint habe als im 
Schematic.

[KiCadSuperman (Gast)]

Karl schrieb:
> Das man ein Bauteil beim Layouten direkt im Boardeditor ändert, und
> nicht erst auf den Schaltplaneditor wechselt, das Bauteil sucht, ändert,
> und die Änderung wieder in den Boardeditor übernimmt ist sooo abwegig?

Ja es ist abwegig (Punkt)
Der Schaltplan stellt immer die Wuzel eines Designs dar, und da hat 
keiner
von hinten (durch du Brust) drein zu pfuschen.
Das gilt besonders dann wenn Designer und Layouter 2 Personen sind.
Back-Annotation ist Teufelszeug.

Die Lösung ist doch ganz einfach (für den Fall das Designer und Layouter
die gleiche Person ist):
Man stellt da mindestens 2 große Monitore nebeneinander auf (besser 
drei) lädt auf dem Linken den Schaltplan in der Mitte das Layout und 
rechts bei Bedarf den Rest. (Datasheets, Checklisten, BOMs usw.)
Änderungen werden dann immer händisch im Schaltplan durchgeführt
(am jeweiligen Symbol) und nirgendwo anders !
Das betrifft in der Hauptsache Footprint, Disti Bestellnummer,
Eigene Teile Nummer, Notizen u.s.w.
Die weiteren Schritte wie DRC,  Netzliste generieren und im Layout 
einlesen
geht doch ratz fatz - null Problemo.

Was mir in den Diskussionen zu kurz kommt sind die Checklisten.
Die ersparen einem mindestens einen Leiterplatten Durchgang.

Auch die leidige Lagerliste wäre ein Thema.

Mal sehen wenn es zeitlich mal wieder  klappt werd ich
unter einem andern Synonym was vorstellen.

[Karl (Gast)]

KiCadSuperman schrieb:
> Man stellt da mindestens 2 große Monitore nebeneinander auf...

Ich habe zwei große Monitore nebeneinander.

> Änderungen werden dann immer händisch im Schaltplan durchgeführt
> (am jeweiligen Symbol) und nirgendwo anders !

Und das ist jetzt besser als einfach im Layout auf das Bauteil zu 
klicken und ihm einen anderen Footprint zuzuweisen? Dass ich das jeweils 
im Schaltplan suche, ändere, einen DRC mache, eine Netzliste generiere 
und dann das Layout aktualisiere, und dann erst sehe, ob es passt.

Wenn das so ist, dann könnte ihr das behalten. Das geht vielleicht für 
eure Arduino Bastelplatinen mit 15 Bauteilen.

[Noob A. (strippenzieher)]

Karl schrieb:
> Für mich entscheidend: Board und Schematic müssen konsistent sein.

Diese Forderung beinhaltet nicht dass eine Änderung in einem bestimmten 
Programmteil gemacht werden muss...

[Possetitjel (Gast)]

Karl schrieb:

> Possetitjel schrieb:
>> Ich sehe
>> nur den Zusammenhang zur fehlenden feedback annotation
>> nicht. (Wahrscheinlich haben die Begriffe bei Eagle
>> eine bestimmte Bedeutung, die ich nicht kenne.)
>
> FB heisst Forward-Backward-Annotation: [...]

Ahh okay, danke.


> Zum Beispiel gibt es die Möglichkeit, im Layout sämtliche
> Bauteile der Position nach umzunummerieren, so dass man
> sie leichter findet. Diese geänderten Namen müssen
> natürlich auch in den Schaltplan übernommen werden.

Selbstverständlich. Das ist ja der wesentliche
Identifikator für die Bauteile.


> Für mich entscheidend: Board und Schematic müssen
> konsistent sein. Es geht nicht, dass ich im Board
> ein anderes Footprint habe als im Schematic.

Naja, es tut mir leid, aber für meinen schwachen Verstand
ist nicht nachvollziehbar, wieso ein Bauteil im Schaltplan
ÜBERHAUPT einen Footprint haben sollte.

Der Schaltplan ist eine abstrakte Darstellung der elektrischen
Funktion der Schaltung. Angaben, die mit der elektrischen
Funktion der Schaltung nicht direkt zu tun haben, gehören
nicht in den Schaltplan. Das ist für mich einfach eine Frage
des hinterliegenden Datenmodelles.

Niemand diskutiert darüber, wie man die Farbe eines
bedrahteten Widerstandes im Schaltplan abbildet, obwohl alle
bedrahteten Widerstände, die ich kenne, tatsächlich eine Farbe
haben -- aber die ist irrelevant, weil für die elektrische
Funktion der Schaltung nicht wichtig.
Dasselbe gilt für den Preis, die Länge der Anschlussdrähte,
die Bestellnummer oder die Verlustleistung.

Die Zuordnung von abstrakten elektrischen Eigenschaften
zu konkreten, kaufbaren, bestellbaren Bauteilen macht die
Stückliste (lies: SOLLTE die Stückliste machen).

[Noob A. (strippenzieher)]

Karl schrieb:
> Wenn das so ist, dann könnte ihr das behalten. Das geht vielleicht für
> eure Arduino Bastelplatinen mit 15 Bauteilen.

Nö, geht auch problemlos bei über 250 Bauteilen (mehr hab ich noch nicht 
in einem KiCAD-Projekt gehabt)

[KiCadSuperman (Gast)]

Karl schrieb:
> Und das ist jetzt besser als einfach im Layout auf das Bauteil zu
> klicken und ihm einen anderen Footprint zuzuweisen?

In KiCad wird das eben nicht sofort im Schaltplan ersetzt,
und das ist gut so!
Man hätte als Benützer eigentlich keine Kontrolle aus welchem "Pretty" 
Pool er das zumischt.
Das ist für mich Kontrollverlust und nicht akzeptabel.
Aus gutem Grund gibt es in PCBnew nur die Forward Annotation - 
Möglichkeit.

[Possetitjel (Gast)]

Karl schrieb:

>> Änderungen werden dann immer händisch im Schaltplan
>> durchgeführt (am jeweiligen Symbol) und nirgendwo
>> anders !
>
> Und das ist jetzt besser als einfach im Layout auf
> das Bauteil zu klicken und ihm einen anderen Footprint
> zuzuweisen?

???

Wovon reden diese Leute?

Können wir uns für die Zwecke der laufenden Diskussion
auf zwei Thesen einigen?

Erstens: Daten können von vielen Stellen aus gelesen
und von vielen Stellen aus geändert werden, aber sie
werden programmintern nur an genau EINER Stelle
gespeichert.

Zweitens: Das, was man im GUI sieht, ist NICHT zwingend
mit der Struktur identisch, in der die Daten programm-
intern gespeichert werden.


Wert, Baugröße, Footprint, Prüfspannung, Verlustleistung,
Preis, Bestellnummer, ... sind Attribute eines Bauteils;
die Gesamtheit dieser Attribute legt fest, um welches
Bauteil es sich handelt. Jedes Bauteil hat eine ID, die
projektweit eindeutig ist.

Bauteile werden intern in der Stückliste gespeichert.

Der Zusammenhang zwischen Stückliste, (Bauteildatenbank, )
Schaltplan und Layout wird durch die Bauteil-ID hergestellt.

Ein Klick auf ein bestimmtes Bauteil -- egal in welchem
"Fenster" -- bezieht sich somit immer auf eine bestimmte
Bauteil-ID, die dann z.B. in allen anderen "Fenstern"
selektiert werden kann ("Target3001" macht das so).

Die Attribute eines selektierten Bauteils können natürlich
auch geändert werden. Selektiert werden kann von überhall
her; geändert wird in dem Fenster, das zuständig ist. Wo
ist das Problem?


So, jetzt zur Kernfrage: Was ist forward-backward-annotation?

[Possetitjel (Gast)]

KiCadSuperman schrieb:

> In KiCad wird das eben nicht sofort im Schaltplan
> ersetzt,

Das beantwortet meine Frage nicht: Was hat der Footprint
im Schaltplan zu suchen?

[KiCadSuperman (Gast)]

Possetitjel schrieb:
> Naja, es tut mir leid, aber für meinen schwachen Verstand
> ist nicht nachvollziehbar, wieso ein Bauteil im Schaltplan
> ÜBERHAUPT einen Footprint haben sollte.
>
> Der Schaltplan ist eine abstrakte Darstellung der elektrischen
> Funktion der Schaltung. Angaben, die mit der elektrischen
> Funktion der Schaltung nicht direkt zu tun haben, gehören
> nicht in den Schaltplan. Das ist für mich einfach eine Frage
> des hinterliegenden Datenmodelles.

Wir reden hier von KiCad oder Eagle und nicht von Mentor, Cadance und co 
:-(


Possetitjel schrieb:
> Die Zuordnung von abstrakten elektrischen Eigenschaften
> zu konkreten, kaufbaren, bestellbaren Bauteilen macht die
> Stückliste (lies: SOLLTE die Stückliste machen).

Mach mich nicht schwach:
Wie bitte  sollen all die nützlichen Sachen in die Stückliste
rein kommen? händisch ?

[Lars R. (lrs)]

Possetitjel schrieb:
> KiCadSuperman schrieb:
>
>> In KiCad wird das eben nicht sofort im Schaltplan
>> ersetzt,
>
> Das beantwortet meine Frage nicht: Was hat der Footprint
> im Schaltplan zu suchen?

meine Vermutung/mein Verständnis:
Das Dateiformat wurde ursprünglich so angelegt, dass das so sein muss 
und wegen dem Dateiformat ist bisher auch keine back-annotation möglich. 
Die gesamte Bedienung/Funktionalität wurde um das einmal festgelegte 
Dateiformat herum entwickelt und musste sich dieser bedingungslos 
unterordnen.
Entsprechend wurde argumentiert:
"Was mit dem Dateiformat nicht geht, das hast Du nicht zu brauchen. 
Backward Annotation? Ok, aufgrund der uns verliehen Gnade darfst Du den 
Footprint vom PCB ins Schematic annotaten. Damit ist das Thema Backward 
annotation aber jetzt abgeschlossen"
....Jahre später: "Ok, Pin swap, mmhhh. Kann das denn Eagle oder ein 
anderes Schrott-Tool? mhhhh."

Bzgl. des Footprint ist es nicht schlimm, die Info auch im Schematic zu 
haben. Mein Eindruck ist jedoch, bedingt durch das bisherige Dateiformat 
muss das dort gemacht werden (bzw. historisch wegen dem Format so 
gewachsen).


Bei, bzw. ab der 5er Version soll es Veränderungen am Format geben.

Sehr unschön ist das unterschiedliche Verhalten und die 
unterschiedlichen Funktionalitäten der Anzeigemodi (Default und OpenGL).

Besser als Kicad ist DesignSpark PCB. Allerdings empfehle ich nicht, 
heute neu damit anfangen, falls es nicht sein muss.

[KiCadSuperman (Gast)]

Possetitjel schrieb:
> Das beantwortet meine Frage nicht: Was hat der Footprint
> im Schaltplan zu suchen?

Ich werde mit dir keinen Glaubenskrieg anfangen.
Ich vermute mal, dass weitere Diskussionen mit dir nich
viel bringen werden. (und auch nicht für die Mitleser)

siehe hier:

Possetitjel schrieb:
> Naja, es tut mir leid, aber für meinen schwachen Verstand
> ist nicht nachvollziehbar, wieso ein Bauteil im Schaltplan
> ÜBERHAUPT einen Footprint haben sollte.

im Übrigen ist dein "TARGET 3001" nicht das mass der Dinge.
das kannst du am Stellenwert hier im Platinen-Forum fesstellen.

[Michael R. (Firma: Brainit GmbH) (fisa)]

Possetitjel schrieb:
> aber die ist irrelevant, weil für die elektrische
> Funktion der Schaltung nicht wichtig.
> Dasselbe gilt für den Preis, die Länge der Anschlussdrähte,
> die Bestellnummer oder die Verlustleistung.

Die Verlustleistung ist für die elektrische Funktion der Schaltung nicht 
wichtig? Ich denke doch die ist sehr wichtig.

Possetitjel schrieb:
> Wert, Baugröße, Footprint, Prüfspannung, Verlustleistung,
> Preis, Bestellnummer, ... sind Attribute eines Bauteils;
> die Gesamtheit dieser Attribute legt fest, um welches
> Bauteil es sich handelt. Jedes Bauteil hat eine ID, die
> projektweit eindeutig ist.

Das ist so leider nicht richtig. Die Welt ist leider viel viel 
komplizierter...

Ein Widerstand im Schaltplan ist erstmal nur ein Widerstand => Footprint 
irrelevant. Bestellnummer irrelevant, das macht die Supply Chain. 
Hersteller irrelevant, das macht die Supply Chain.

Es sei denn er muss eine gewisse Leistung aushalten... uuups, plötzlich 
ist der Footprint doch relevant...

Es sei denn es gibt eine AML (Approved Manufacturers List)... uuups... 
Hersteller plötzlich doch relevant.

Ja, das sind Ausnahmen. Der Regelfall mag durchaus so laufen wie in 
deiner Welt. Aber du weisst ja... den Regelfall abzubilden kostet 90% 
der zeit. Und die Ausnahmen dann die anderen 90% ;-)

[Lars R. (lrs)]

Michael R. schrieb:
> Es sei denn er muss eine gewisse Leistung aushalten... uuups, plötzlich
> ist der Footprint doch relevant...

nein, ist er nicht. Die Verlustleistung wohl, aber der Footprint nicht.

Entsprechend Deiner Argumentation müsste auch die Leiterbahnbreite und 
der Stackaufbau und die Lage der Leiterbahn zwingend in's Schematic, um 
beispielsweise die Impedanz fest zu spezifizieren.

[Simon (Gast)]

Michael R. schrieb:
> Ja, das sind Ausnahmen. Der Regelfall mag durchaus so laufen wie in
> deiner Welt. Aber du weisst ja... den Regelfall abzubilden kostet 90%
> der zeit. Und die Ausnahmen dann die anderen 90% ;-)

Genau Diese Ausnahmen gibt es. Und eigentlich ist dies nach meinem 
Verständnis eben ein Argument GEGEN FB Annotation.

Der Schemadesigner entwickelt die Schaltung und fügt da, wo er es für 
nötig hält, Attribute wie z.B. eben den Footprint hinzu.

Dann kommt die Schnittstelle zum Layouter. Da kann man z.B. 
zusammensitzen, wobei der Layouter dann sagt: Ich hätte am liebsten 
durchgehend 0402 Hühnerfütter. Gut, dann legt man für alle Bauteile, bei 
den übrigen (meisten) Rs und Cs einen 0402er an.

Was ich jetzt aber ganz sicher nicht möchte, ist, dass der Layouter 
findet, dass der 1210er auf dem Board jetzt aber doch viel zu viel Platz 
benötigt und deswegen diesem ebenfalls einen 0402er zuordnet.

Selbst wenn ICH der Layouter UND der Schemazeichner bin, möchte ich das 
nicht. Wenn ich mich während des Layouts entscheide, dass ich einen 
Footprint ändern möchte, möchte ich das dort tun, wo ich die 
Entscheidung ursprünglich gemacht habe.

Ja, es ist einfacher, dies im Layout zu tun. Ja, wenn man es im KiCad 
könnte, würde ich es wohl auch oft so machen. Nein, es ist kein 
Weltuntergang, dies halt doch im Schematool zu machen. Ja, man macht 
könnte dadurch durchaus erkennen, dass es sehr wohl Sinn machte, den 
Footprint so zu definieren, wie er definiert war.

Ich halte FB Annotation nicht für Teufelszeug. Aber auch nicht für den 
Heiligen Gral. Es macht wohl die Arbeit oft einfacher, verleitet aber 
auch zu Fehlern.

[Lars R. (lrs)]

Simon schrieb:
> Michael R. schrieb:
>> Ja, das sind Ausnahmen. Der Regelfall mag durchaus so laufen wie in
>> deiner Welt. Aber du weisst ja... den Regelfall abzubilden kostet 90%
>> der zeit. Und die Ausnahmen dann die anderen 90% ;-)
>
> Genau Diese Ausnahmen gibt es. Und eigentlich ist dies nach meinem
> Verständnis eben ein Argument GEGEN FB Annotation.
>
> Der Schemadesigner entwickelt die Schaltung und fügt da, wo er es für
> nötig hält, Attribute wie z.B. eben den Footprint hinzu.

Footprint ist kein Attribut. Es gibt ein Symbol und es gibt einen 
Footprint. Beide haben (irgendwann im Laufe des Designs) die selben 
Attribute. = Bauteil.

>
> Dann kommt die Schnittstelle zum Layouter. Da kann man z.B.
> zusammensitzen, wobei der Layouter dann sagt: Ich hätte am liebsten
> durchgehend 0402 Hühnerfütter. Gut, dann legt man für alle Bauteile, bei
> den übrigen (meisten) Rs und Cs einen 0402er an.

Genau. Sämtliche Bestückeroptionen und Eigenschaften des PCB im 
Schematic festlegen.


> Was ich jetzt aber ganz sicher nicht möchte, ist, dass der Layouter
> findet, dass der 1210er auf dem Board jetzt aber doch viel zu viel Platz
> benötigt und deswegen diesem ebenfalls einen 0402er zuordnet.

Und anders herum sagt dann der PCB-Entwickler, wie der SChaltplan 
auszusehen hat? Oder das dann nicht? Warum nicht?

Wer bestückt es denn eigentlich? Der Schematic-Zeichner nach Schematic 
oder was?

>
> Selbst wenn ICH der Layouter UND der Schemazeichner bin, möchte ich das
> nicht. Wenn ich mich während des Layouts entscheide, dass ich einen
> Footprint ändern möchte, möchte ich das dort tun, wo ich die
> Entscheidung ursprünglich gemacht habe.

Ich bin auch dafür, dass wir Schematic und PCB endlich zusammen legen, 
damit ich nicht ständig umzeichnen muss. Ich hätte gern die Netzvergabe 
und Annotations im PCB gehabt. Aber wenn dafür die gesamte 
PCB-Funktionalität ins Schematic soll, so wie Du das vor schlägst, so 
soll mir das auch recht sein.

[Simon (Gast)]

Lars R. schrieb:
> Footprint ist kein Attribut. Es gibt ein Symbol und es gibt einen
> Footprint. Beide haben (irgendwann im Laufe des Designs) die selben
> Attribute. = Bauteil.

Bei Kicad ist ein Attribut des Schemasymbols.

Lars R. schrieb:
> Genau. Sämtliche Bestückeroptionen und Eigenschaften des PCB im
> Schematic festlegen.

Nein. Aber die für den Layouter relevanten. Da kann man auch in KiCad 
noch einiges machen (Netzattribute etc.)

Lars R. schrieb:
> Aber wenn dafür die gesamte
> PCB-Funktionalität ins Schematic soll, so wie Du das vor schlägst, so
> soll mir das auch recht sein.

Wo habe ich das vorgeschlagen?
In einer mechanischen Zeichnung werden alle Masse etc. vermerkt. Wie 
genau das Teil gefräst/gedreht/gegossen/gespritzt/gedruckt werden soll, 
weiss der Fertiger selber besser als ich. ABER wenn eine Fläche aus 
welchem Grund auch immer mit einem speziellen Fräser geschlichtet werden 
muss, dann wird das in der mechanischen Zeichnung spezifiziert.

[Lars R. (lrs)]

Hab vorletzte Woche einen FPGA-Adapter mit Kicad realisiert.

Links Buchsenleiste (Zusatzplatine). Rechts Buchsenleiste 
(Zusatzplatine).

In der Mitte Buchsenleiste (FGPA).


Ich lege also mit Kicad das Schematic an:
. 3 Buchsenleisten
. Für Buchsenleiste links und Buchsenleiste rechts kann ich im Schematic 
Netznamen an den Pins vergeben. Eigentlich ist das überflüssig, aber 
soweit kann ich den Workflow machen.

Dann layoute ich, wie es am besten passt. Dh, ich ziehe von den äußeren 
Buchsenleisten zur inneren die Leitungen, ohne mit den Pins der 
mittleren Buchsenleiste zu verbinden. Ich würde gern auch von der 
inneren aus zu den äußeren ziehen, aber das würde später schief gehen, 
weil diese Leitungen im Moment noch keinen Netz-Namen haben.

Wenn ich fertig bin, gehe ich ins Schematic. Nun weiß ich, welcher Pin 
der mittleren Buchsenleiste welches Netz bekommt. Ich weise das so zu, 
wie ich im PCB die Leitungen heran gezogen habe. Dafür muss ich immer 
wieder ins PCB gehen zum Nachschauen.

So geht es mir mit dem Design mit FPGA oder mit RAM oder mit 
Konfigurierbaren IOs von uCs.


Dann kommen die "Spezialisten" und erklären: Genau so muss das sein. Das 
ist die ideale Arbeitsweise und deshalb lassen wir nichts anders zu.

Die Entwickler dürfen realisieren, was sie wollen. Aber erspart uns 
endlich diese BS-Argumentation.

[Possetitjel (Gast)]

Michael R. schrieb:

> Possetitjel schrieb:
>> aber die ist irrelevant, weil für die elektrische
>> Funktion der Schaltung nicht wichtig. Dasselbe gilt
>> für den Preis, die Länge der Anschlussdrähte,die
>> Bestellnummer oder die Verlustleistung.
>
> Die Verlustleistung ist für die elektrische Funktion der
> Schaltung nicht wichtig?

Hmm.

SPICE simuliert doch die elektrische Funktion der Schaltung,
nicht wahr?
Wo muss ich in den SPICE-Files die Verlustleistung des
Widerstandes angeben?


> Ich denke doch die ist sehr wichtig.

Auf einer bestimmten Abstraktionsebene - ja.
Auf ein einer anderen - nein.

Es geht mir ja gerade darum, die verschiedenen Abstraktions-
ebenen auch für den Nutzer erkennbar im Programm zu unter-
scheiden!

> Das ist so leider nicht richtig. Die Welt ist leider viel
> viel komplizierter...
>
> Ein Widerstand im Schaltplan ist erstmal nur ein Widerstand
> => Footprint irrelevant. Bestellnummer irrelevant, das macht
> die Supply Chain. Hersteller irrelevant, das macht die
> Supply Chain.
>
> Es sei denn er muss eine gewisse Leistung aushalten... uuups,
> plötzlich ist der Footprint doch relevant...
>
> Es sei denn es gibt eine AML (Approved Manufacturers List)...
> uuups... Hersteller plötzlich doch relevant.
>
> Ja, das sind Ausnahmen.

Nein, ganz im Gegenteil: Das ist der Regelfall -- genauer: Es
sind unterschiedliche Stadien dieses Regelfalles.


> Der Regelfall mag durchaus so laufen wie in
> deiner Welt.

Ich denke, wir missverstehen uns.

(Reale) Dinge lassen sich abstrakt als Kombinationen von
Attributen (bzw. Attributwerten) beschreiben.
Umgekehrt entspricht aber durchaus nicht jede Kombination
von abstrakten Attributwerten einem realen Ding.

Es hat überhaupt keinen Sinn, einfach den Hersteller eines
Präzisionswiderstandes auf einen zugelassenen Hersteller zu
ändern, wenn dieser zugelassene Hersteller den gewünschten
Widerstand überhaupt nicht herstellt!
Es hat daher keinen Sinn, im Programm einfach an beliebigen
Stellen irgendwelche Attributwerte ändern zu können, weil
das Programm schließlich die Realität (im weitesten Sinne)
abbilden soll.

Soll heißen: Man kann natürlich Schaltplan und Layout als
getrennte Dinge ansehen, die jeweils irgendwelche Elemente
mit bestimmten Attributen enthalten. So lange die Attribute
der Schaltplanelemente wenig oder nix mit den Attributen
der Layoutelementen zu tun haben, ist das kein Problem.

Sobald man aber anfängt, Konsistenzbedingungen für diese
Attribute zu fordern, ist man SEHR gut beraten, sich
Gedanken über das hinterliegende Datenmodell zu machen.

Wenn man das tut, stellt man fest, dass die forward-
backward-annotation eine Chimäre ist, die sich bei näherer
Betrachtung in Luft auflöst: Ist gibt (lt. Definition) in
einem bestimmten Projekt nur (höchstens) EINEN Widerstand
mit der ID "R42" (weil diese ID die Rolle eines Schlüssels
spielt). R42 hat (in diesem Projekt) GENAU EINEN Footprint.

Es ist absolut irrelevant, in welchem Fenster man was
sieht oder wann man worauf klickt -- die Zuordnung zwischen
Bauteil(-ID) und Footprint ist projektweit eindeutig. Da
ist überhaupt nichts forward oder backward zu annotieren,
weil in einem vernünftigen Datenmodell i.d.R. jedes
wesentliche Datum nur an GENAU EINER Stelle gespeichert
wird, und zwar als Attribut des Objektes, dem es gehört.

[Possetitjel (Gast)]

KiCadSuperman schrieb:

> Possetitjel schrieb:
>> Das beantwortet meine Frage nicht: Was hat der
>> Footprint im Schaltplan zu suchen?
>
> Ich werde mit dir keinen Glaubenskrieg anfangen.

Sollst Du auch gar nicht. Es genügt, wenn Du eine
Antwort auf die Frage oben geben kannst. Versuche
einfach, die Frage ernst zu nehmen.


> Ich vermute mal, dass weitere Diskussionen mit dir
> nich viel bringen werden. (und auch nicht für die
> Mitleser)

Sehr lahmer Versuch der Stimmungsmache.

[Michael R. (Firma: Brainit GmbH) (fisa)]

Lars R. schrieb:
> Entsprechend Deiner Argumentation müsste auch die Leiterbahnbreite und
> der Stackaufbau und die Lage der Leiterbahn zwingend in's Schematic, um
> beispielsweise die Impedanz fest zu spezifizieren.

Hab ich irgendwo "zwingend" gesagt?

Und ja, Leiterbahn-Breiten sollen (auch) im Schematic definiert werden 
können (Netzklassen).

Lars R. schrieb:
> Footprint ist kein Attribut. Es gibt ein Symbol und es gibt einen
> Footprint. Beide haben (irgendwann im Laufe des Designs) die selben
> Attribute. = Bauteil.

Bauteil setzt sich nicht nur aus Symbol + Footprint zusammen. Es gibt 
viele Parameter, die schlussendlich zu einem (konkreten) Bauteil führen, 
welches bestellt (und später bestückt) werden kann. Und einige dieser 
Parameter kommen weder aus dem Schematic noch aus dem Layout. Andere 
Parameter entweder/oder.

Und es ist nicht einfach "nur eine Frage des Datenmodells", und das 
Datenmodell ist keinesfalls einfach (ich hatte vor Jahren das 
zweifelhafte Vergnügen, viele Daten von Nortel zu übernehmen, da durfte 
ich lernen wie komplex solche Datenmodelle sein können, und dass sie es 
nicht ohne Grund sind)

Es spricht doch nichts dagegen, die Möglichkeit zu bieten, gewisse 
Parameter in beiden Design-Welten (also Schaltplan und Layout) zu 
definieren, und FB-Anno hilft, die synchron zu halten. Ob man das dann 
zulässt und verwendet, ist eine andere Frage.

Aber ein System, welches das eben nicht zulässt, hat eine 
(Design-)Schwäche.

[KiCadSuperman (Gast)]

Lars R. schrieb:
> Dann kommen die "Spezialisten" und erklären: Genau so muss das sein. Das
> ist die ideale Arbeitsweise und deshalb lassen wir nichts anders zu.
>
> Die Entwickler dürfen realisieren, was sie wollen. Aber erspart uns
> endlich diese BS-Argumentation.

Komm mal runter.

Dein Kritik ist mit deiner textuellen Beschreibung ohne Bilder kaum 
nachvollziehbar.

Einen Weg den wir beschreiten bei ähnlichen Gegebenheiten ist
folgender:
Wir rufen  vor dem Schaltplan zeichnen ganz zwangslos den PCBnew
auf und platzieren alle  relevanten Bauteile.
Dazu mergen wir noch  die 3d-Modelle.
Wir überlegen uns dabei die Leiterführung, Bauteilgröße die beste 
Platzierung, und lassen diese Erkenntnis dann im eigentlichen Schaltplan 
einfließen und starten so unsere Projekte.

Deine oben beschriebenen Probleme kennen wir so nicht.

[Possetitjel (Gast)]

Lars R. schrieb:

> Possetitjel schrieb:
>> KiCadSuperman schrieb:
>>
>>> In KiCad wird das eben nicht sofort im Schaltplan
>>> ersetzt,
>>
>> Das beantwortet meine Frage nicht: Was hat der Footprint
>> im Schaltplan zu suchen?
>
> meine Vermutung/mein Verständnis:
> Das Dateiformat wurde ursprünglich so angelegt, dass das
> so sein muss und wegen dem Dateiformat ist bisher auch
> keine back-annotation möglich.
> Die gesamte Bedienung/Funktionalität wurde um das einmal
> festgelegte Dateiformat herum entwickelt und musste sich
> dieser bedingungslos unterordnen.

Hmm. Okay. Das klingt logisch.

Das kann ich nachvollziehen; das habe ich bei einem
privaten Miniprojekt auch schon erlebt. Danke für
den Denkanstoß.

[Possetitjel (Gast)]

Michael R. schrieb:

> Und es ist nicht einfach "nur eine Frage des Datenmodells",

Naja, doch.


> und das Datenmodell ist keinesfalls einfach

DAS hat auch niemand ernsthaft behauptet.


> (ich hatte vor Jahren das zweifelhafte Vergnügen, viele
> Daten von Nortel zu übernehmen, da durfte ich lernen
> wie komplex solche Datenmodelle sein können, und dass
> sie es nicht ohne Grund sind)

Ja: Ein Grund ist häufig, dass die Dinge, die im Computer
abgebildet bzw. modelliert werden sollen, entstanden sind,
bevor es den Begriff "Datenmodell" überhaupt gab :)

Beim E-CAD ist die Sachlage insofern anders, als dass das
eine relativ junge Sparte ist, die sich erst entwickelt.
Wir haben also jetzt die Möglichkeit, neue Begriffe und
Konventionen zu schaffen, und diese können konsistent oder
widersprüchlich sein, je nachdem.

> Es spricht doch nichts dagegen, die Möglichkeit zu bieten,
> gewisse Parameter in beiden Design-Welten (also Schaltplan
> und Layout) zu definieren, und FB-Anno hilft, die synchron
> zu halten.

Doch, es spricht etwas dagegen: Die Normalformtheorie.

Wenn man an der Idee der Schlüsselattribute festhält, und
die Bauteil-ID als ein solches auffasst, dann erschließt sich
mir nicht, warum es möglich sein sollte, DEMSELBEN Bauteil
mit DERSELBEN ID zwei UNTERSCHIEDLICHE Footprints zuordnen
zu können.

DASSELBE Bauteil hat doch auch in der Realität nur EINEN
Footprint! GENAU einen!

Ich spreche nicht vom GUI, nicht davon, in welchem Fenster
man worauf klickt. Ich spreche vom Datenmodell.


> Aber ein System, welches das eben nicht zulässt, hat eine
> (Design-)Schwäche.

Ich vermag nicht einzusehen, wieso ein System, das KEINE
widersprüchlichen Daten zulässt, eine DesignSCHWÄCHE hat.

[Lars R. (lrs)]

Michael R. schrieb:
> Lars R. schrieb:
> Es spricht doch nichts dagegen, die Möglichkeit zu bieten, gewisse
> Parameter in beiden Design-Welten (also Schaltplan und Layout) zu
> definieren, und FB-Anno hilft, die synchron zu halten. Ob man das dann
> zulässt und verwendet, ist eine andere Frage.
>
> Aber ein System, welches das eben nicht zulässt, hat eine
> (Design-)Schwäche.

Auf jeden Fall. Aber so lang noch nicht einmal mal Netznamen den Weg vom 
PCB ins Schematic finden können...


KiCadSuperman schrieb:
> Lars R. schrieb:
>> Dann kommen die "Spezialisten" und erklären: Genau so muss das sein. Das
>> ist die ideale Arbeitsweise und deshalb lassen wir nichts anders zu.
>>
>> Die Entwickler dürfen realisieren, was sie wollen. Aber erspart uns
>> endlich diese BS-Argumentation.
>
> Dein Kritik ist mit deiner textuellen Beschreibung ohne Bilder kaum
> nachvollziehbar.

Was gibt es da nicht zu verstehen? Ich beispielsweise 100 
Signalleitungen und die müssen möglichst günstig (wenig Vias) geroutet 
werden. Das geht im PCBnew am realen Footprint ganz einfach, aber ohne 
Netznamen lässt sich da nichts verbinden.
Zusätzlich schlecht ist, dass die im PCBnew bereits gezogenen Leitungen 
bei einer Netznamen-Änderung im schematic mit forward-annotation den 
geänderten Namen des Pins nicht mitnehmen.


> Einen Weg den wir beschreiten bei ähnlichen Gegebenheiten ist
> folgender:
> Wir rufen  vor dem Schaltplan zeichnen ganz zwangslos den PCBnew
> auf und platzieren alle  relevanten Bauteile.
> Dazu mergen wir noch  die 3d-Modelle.
> Wir überlegen uns dabei die Leiterführung, Bauteilgröße die beste
> Platzierung, und lassen diese Erkenntnis dann im eigentlichen Schaltplan
> einfließen und starten so unsere Projekte.


> Deine oben beschriebenen Probleme kennen wir so nicht.

Weil ihr nicht ernsthaft designt.


Wenn Du FPGA nicht verstehst, verstehst Du RAM?

Ein RAM habe die Pins RAM_DATA0-RAM_DATA15. Der RAM soll an einem uC 
angeschlossen werden. Dieser hat die Pins uC_DATA0-uC_DATA15.

Wie Du die Pins nun miteinander verbindest (zB. RAM_DATA0 mit uC_DATA15) 
ist egal. Die Schaltung funktioniert trotzdem. Ja donnerwetter. Das ist 
ja zauberei.

Kannst Du Dir nun vorstellen, dass das einen Unterschied macht bzgl. 
Anzahl Vias, Anzahl Lagen und Signalqualität?


Jetzt nicht 16 Leitungen, sondern 100 (100 ist ein kleines Beispiel). 
Zwei Lagen oder acht?

[Wühlhase (Gast)]

Lars R. schrieb:
> Michael R. schrieb:
>> Es sei denn er muss eine gewisse Leistung aushalten... uuups, plötzlich
>> ist der Footprint doch relevant...
>
> nein, ist er nicht. Die Verlustleistung wohl, aber der Footprint nicht.
>
> Entsprechend Deiner Argumentation müsste auch die Leiterbahnbreite und
> der Stackaufbau und die Lage der Leiterbahn zwingend in's Schematic, um
> beispielsweise die Impedanz fest zu spezifizieren.
Das kann anderswo auch so gemacht werden.

Ich möchte den Thread hier aber nicht unnötig weiter ins OT treiben, da 
ich mich eigentlich als stiller Mitleser über zahlreiche "Ich mach jetzt 
auch KiCad und Eagle ist ja wirklich ein Graus"-Beiträge gefreute habe. 
;)

[Karl (Gast)]

Lars R. schrieb:
> Und anders herum sagt dann der PCB-Entwickler, wie der SChaltplan
> auszusehen hat? Oder das dann nicht? Warum nicht?

Ja. Natürlich. Wenn ich im Layout sehe, dass es besser wäre OPV A und B 
zu tauschen, dann ändere ich das. Wenn ich sehe, dass ich einige 
Leiterbahnkreuzungen sparen kann, indem ich die Pins an einem µC anders 
belege, dann lege ich die um. Und wenn ich aus einer Zweilagen- eine 
Einlagenplatine machen kann, indem ich ein paar 0-ohm-Widerstände 
einfüge - da muss der Schaltplan durch.

[Possetitjel (Gast)]

Lars R. schrieb:

> Dann layoute ich, wie es am besten passt. Dh, ich ziehe
> von den äußeren Buchsenleisten zur inneren die Leitungen,
> ohne mit den Pins der mittleren Buchsenleiste zu verbinden.
> Ich würde gern auch von der inneren aus zu den äußeren
> ziehen, aber das würde später schief gehen, weil diese
> Leitungen im Moment noch keinen Netz-Namen haben.
>
> Wenn ich fertig bin, gehe ich ins Schematic. Nun weiß ich,
> welcher Pin der mittleren Buchsenleiste welches Netz bekommt.
> Ich weise das so zu, wie ich im PCB die Leitungen heran
> gezogen habe. Dafür muss ich immer wieder ins PCB gehen
> zum Nachschauen.
>
> So geht es mir mit dem Design mit FPGA oder mit RAM oder
> mit Konfigurierbaren IOs von uCs.

"Konfigurierbar". Das merken wir uns.


> Dann kommen die "Spezialisten" und erklären: Genau so muss
> das sein. Das ist die ideale Arbeitsweise und deshalb lassen
> wir nichts anders zu.
>
> Die Entwickler dürfen realisieren, was sie wollen. Aber
> erspart uns endlich diese BS-Argumentation.

Du hast Recht -- aber Du schüttest das Kind mit dem Bade aus.
Die Entwickler sind einfach betriebsblind. Sieh es ihnen nach.

Das Problem ist meiner Ansicht nach wesentlich grundsätzlicherer
Natur: Der (klassische) Schaltplan ist für vielpolige programmier-
bare bzw. konfigurierbare Bauteile kein sinnvolles Beschreibungs-
mittel mehr.

[Possetitjel (Gast)]

Karl schrieb:

> Lars R. schrieb:
>> Und anders herum sagt dann der PCB-Entwickler, wie
>> der SChaltplan auszusehen hat? Oder das dann nicht?
>> Warum nicht?
>
> Ja. Natürlich. Wenn ich im Layout sehe, dass es besser
> wäre OPV A und B zu tauschen, dann ändere ich das.

...und bekommst anschließend Schläge, weil Du natürlich
nicht einen schnellen bipolaren OPV mit einem Elektrometer-
FET-Opamp tauschen darfst...

[W.S. (Gast)]

Chris D. schrieb:
> Es kommt durchaus vor, dass man die Leiterbahnen gerne so liegen lassen
> möchte wie sie waren und von den "abgerissenen" Enden selbst
> weiterrouten möchte (hatte ich bei unserem letzten PCB)

Ist dir eigentlich klar, daß du mir ständig ausweichst?

Ich schreibe vom Schematics und nicht vom Layout. Da gibt es keine 
Leiterbahnen zu routen. Abgesehen ist es ein Mumpitz, solchen Befehlen 
derartig irreführende Bezeichnungen zu geben. Ist dasselbe wie "typedef" 
bei C. Wennschon, hätte man sowas "cutout" oder nen ähnlich klingenden 
denglischen Namen geben müssen. Das ist genau so, als ob du ständig 
RECHTS sagst, wenn du LINKS meinst.

Chris D. schrieb:
> Dass es komplex sei und man so viel lernen müsse, liest man nur von
> denjenigen, die das hier schreiben.

Jetzt werd ich so langsam sauer.
Ich hatte beim Ausprobieren von Kicad nicht nur einen derartigen Bug 
bereits binnen der ersten 10 Minuten gesehen. Denke mal an das seltsame 
Verhalten im Schematics, wo man zuerst irgendwo ins Schematics klicken 
muß und dann erst sich ein Bauteil auswählen kann, das dann aber nicht 
an der Maus klebt, sondern an dem zuvor angeklicktten Ort. Ist so etwas 
in deinen Augen etwa auch sinnvoll?

Es gibt noch ne Menge anderer Abstrusitäten in Kicad und es widert mich 
so langsam an, von dessen Fans immer nur lesen zu müssen "das ist ein 
großartiges Feature!" Nee, ist es eben nicht und es wäre einfach mal 
angebracht, den Kopf zu senken und zuzugeben, daß es damit im Argen 
liegt. Einfach mal den Mist ZUGEBEN !!!


Chris D. schrieb:
> Das ist also kein Maßstab - insbesondere, wenn man vorher Eagle
> benutzte.
> Da hat man nämlich auch nicht einfach so angefangen (ich weiß das noch
> gut von mir selbst), sondern die Lernkurve war entsprechend steinig.
>
> Aber: man wollte es und hatte auch keine andere Wahl, denn es gab kaum
> andere Software.

Das mag auf dich zutreffen - aber nicht auf mich. Ich hatte zu der Zeit 
PADS und wollte eigentlich zu Seto wechseln, ging aber nicht, weil das 
kurz zuvor von Mentor aufgekauft wurde (war ne ähnliche Situation wie 
heuer die mit Eagle8). Also, es gab zu der Zeit eine Menge anderer 
Programme und falls du zu dieser Zeit ein Greenhorn warest, dann 
solltest du nicht versuchen, dies auch bei anderen vorauszusetzen.

W.S.

[Simon (Gast)]

Das Beispiel mit dem FPGA und den vielen (beliebigen) Pads, die zu 
vielen (beliebigen) Pads geroutet werden müssen, ist in der Tat 
einleuchtend. Als ganz grosser Kicad-Fan muss ich ganz klar zugeben: Es 
wäre in manchen Fällen schön, wenn man das so machen könnte.
Eine ganz unqualifizierte Anmerkung dazu: Vor laaaaaanger Zeit, als ich 
im Studium mal mit Protel (später Altium) gearbetet habe, wurde mir 
richtiggehend eingetrichtert, die FB-Annotation NIE NIE NIE zu 
verwenden, weil das Gift für die Datenkonsistenz sei. Aber wie gesagt: 
Unqualifizierte Anmerkung. Ob die Warnung berechtigt war und ob das auf 
für Eagle gilt, kann  ich nicht sagen. Sauber programmiert sollte das ja 
eigentlich schon gehen.

Meine Sicht der Dinge ist nach wie vor, dass das Schema der Ursprung ist 
und sich das Layout diesem unterzuordnen hat. Nur im von Dir erwähnten 
Beispiel sehe ich, dass man sich da viel Arbeit ersparen könnte. 
Andererseits - das ist aber ein reines,vielleicht falsches, Bauchgefühl 
- würde ich selbst da ungern zulassen, dass das Schematool mir Leitungen 
im Schema verändert oder Labels umbenennt. Ich will z. B. auch nicht, 
dass irgendein Tool, z.B. gerade in diesem Kontext, meinen Sourcecode 
für den Prozessor verändert, so dass das Label "GPIO_LED5" nun auf 
"GPIOA_3" verändert wird. Der Sourcecode ist der Chef. Wenn sich im 
Verlauf des Layouts ergibt, dass ein anderer GPIO besser wäre, dann 
mache ich das im Sourcecode. Und halt eben im Schema. Es wäre viel 
praktischer und schneller, wenn das Layouttool das macht. Aber ich 
möchte es trotzdem selber machen.

Aber soweit ich mich erinnere, hatte Eagle bis vor einiger Zeit keinen 
Online-DRC. Mit aktivem Online-DRC ist so etwas aber schlicht nicht 
möglich, denn man KANN die Tracks gar nicht so ziehen, dass sie dem 
Schema widersprechen. Wie ist denn das in Eagle gelöst? Muss man dazu 
den Online-DRC ausschalten?

[W.S. (Gast)]

Possetitjel schrieb:
> Zweite Bemerkung: Der Footprint hat (logisch) gar nix
> im Schaltplan zu suchen; das ist eine Angabe, die in die
> STÜCKLISTE gehört.
> Aus mir rätselhaften Gründen gibt es weite Teile der
> EDA-Welt, die sich standhaft weigern, die Stückliste als
> gleichberechtigte Fertigungsunterlage neben z.B. dem
> Schaltplan und dem Layout anzusehen.

Du hast dich verstiegen, ganz einfach verstiegen.

Zuerst mal eins: eine automatische V/R-Annotation ist etwas 
essentielles weil nur dadurch von der EDA-Soft gesichert ist, daß 
Schematic und Leiterplatte tatsächlich konsistent sind - und Konsistenz 
zwischen beiden ist so überragend wichtig, daß ich kein anderes Wort als 
eben überragend wichtig dafür finde.

Was meinst du, in was für eine Katastrophe du hineinsteuerst, wenn das 
auseinander driftet? Die Kundendienstler werden dir dafür den Hintern 
versohlen - und zu Recht! Obendrein die Fertigung und der Einkauf. Noch 
schlimmer wird's, wenn die Fertigung ausgelagert ist.

Und sowas Wichtiges willst du freiwillig dem persönlichen Zufall 
überlassen - in einer Welt, wo V/R-Annotation dank leistungsfähiger PC's 
überhaupt kein Problem mehr ist?

Und Stücklisten sind Nachbereitung.
Der Entwickler hingegen hat sich auf seine Funktionalität zu 
konzentrieren - und dazu zählt eben auch, daß er für die Bauteile, die 
er in seiner Schaltung sehen will, bereits vor dem benutzen des 
EDA-Programms die passenden Baugrößen und damit den Footprint auswählt.

DAS ist das Wichtige. In die Stückliste kommt später dann nur noch, ob 
der Widerstand von Beyschlag oder Isabellenhütte oder anonym per Distri 
und dessen Katalognummer bezogen wird. Das interessiert den Entwickler 
und Layouter hingegen garnicht, der will lediglich einen 4k7 in 0603 
dort haben.

W.S.

[Simon (Gast)]

Simon schrieb:
> dass das Schematool mir Leitungen
> im Schema verändert oder Labels umbenennt

Sollte natürlich "Layouttool" heissen

[Simon (Gast)]

W.S. schrieb:
> Zuerst mal eins: eine automatische V/R-Annotation ist etwas
> essentielles weil nur dadurch von der EDA-Soft gesichert ist, daß
> Schematic und Leiterplatte tatsächlich konsistent sind - und Konsistenz
> zwischen beiden ist so überragend wichtig, daß ich kein anderes Wort als
> eben überragend wichtig dafür finde.

automatische V/R-Anntotation ist aber keine Voraussetzung für 
Datenkonsistenz. Der Maschinencode ist, wenn man die Toolchain sauber 
verwendet, immer konsistent mit dem Sourcecode, obwohl ich nicht im 
Hex-Editor eine Zahl ändern kann, und das dann automatisch den 
Sourcecode verändert.

[W.S. (Gast)]

Simon schrieb:
> Andererseits - das ist aber ein reines,vielleicht falsches, Bauchgefühl
> - würde ich selbst da ungern zulassen, dass das Schematool mir Leitungen
> im Schema verändert oder Labels umbenennt.

Huch?
Also erstens ist es die Aufgabe des Schematic-Editors, Änerungen am 
Schematic zu machen. Dafür ist dieser Teil des Systems gedacht.

Zweitens bist DU es, der diesen Editor benutzt und dort Änderungen 
vollzieht.

Aber betrachte mal das Layouten:
Da hast du dir im Schematic eine Schaltung ausgedacht und dabei die 
Bauteile so verwendet, wie es dir am sinnvollsten erschien. Dabei eben 
auch die OpV's in einem oder mehreren 4fach-OpV's oder die Gatter in 
einem 7400 oder die Widerstände in einem Widerstandsarray so 
verschaltet, daß sie die gewünschte Schaltung ergeben.

Schön soweit.

Aber beim Layouten stellst du fest, daß es wohl besser wäre, die im 
Schematic vorgenommene Aufteilung etwas anders vorzunehmen. Jetzt kannst 
du dir die Änderungen auf einen Notizzettel schreiben, ins Schematics 
wechseln, dort die Änderungen machen, die Netzliste exportieren, diese 
dann ins Layout importieren und gucken, ob du es dir so richtig gedacht 
hast. Finde ich umständlich. Sowas hatte man früher notgedrungen 
gemacht, als die PC's noch winzig im Vergleich zu heute waren.

Du kannst bei einem V/R-Anno fähigen System aber auch mit Pinswap und 
Gateswap es gleich im Layout machen, schauen ob das nun besser ist und 
ggf mit Undo es wieder rückgängig machen, wenn es dir mißfällt. Das ist 
weitaus effizienter, als der oben skizzierte umständliche Weg.

Ich sehe da eine Einschränkung: Wenn jemand beim Dienstleister sitzt und 
dort vorgegebene Schaltungen layoutet, ohne ein Mitspracherecht zu 
haben, dann ist jegliche Annotation sinnlos. Aber auf wie viele Leute 
trifft dieses zu? Wohl doch die Wenigsten.

W.S.

[Lars R. (lrs)]

Simon schrieb:
> Das Beispiel mit dem FPGA und den vielen (beliebigen) Pads, die zu
> vielen (beliebigen) Pads geroutet werden müssen, ist in der Tat
> einleuchtend. Als ganz grosser Kicad-Fan muss ich ganz klar zugeben: Es
> wäre in manchen Fällen schön, wenn man das so machen könnte.
> Eine ganz unqualifizierte Anmerkung dazu: Vor laaaaaanger Zeit, als ich
> im Studium mal mit Protel (später Altium) gearbetet habe, wurde mir
> richtiggehend eingetrichtert, die FB-Annotation NIE NIE NIE zu
> verwenden, weil das Gift für die Datenkonsistenz sei. Aber wie gesagt:
> Unqualifizierte Anmerkung. Ob die Warnung berechtigt war und ob das auf
> für Eagle gilt, kann  ich nicht sagen. Sauber programmiert sollte das ja
> eigentlich schon gehen.

Vielleicht war die in der gerade verwendeten Version kaputt. Gerade die 
manuelle Backward-Annotation war in diversen Tools...naja... Langjährige 
Nutzer beherrschten es, aber einmal falsch geklickt und der Datensatz 
des Designs ist Schrott.

Possetitjel schrieb:
> Das Problem ist meiner Ansicht nach wesentlich grundsätzlicherer
> Natur: Der (klassische) Schaltplan ist für vielpolige programmier-
> bare bzw. konfigurierbare Bauteile kein sinnvolles Beschreibungs-
> mittel mehr.

Doch schon, zur Beschreibung des Ist-Zustandes einer realisierten 
Schaltung. Nur sollte er mindestens teilweise aus dem PCB-Tool erzeugt 
werden. Dh, Netznamenvergabe und Pinzuweisung im PCB-Tool und per 
Backannotation erscheint der (ggf neue) Netzname im Schematic am 
richtigen Symbol am richtigen Pin. Das ist der Ist-Zustand (jedoch nicht 
bei Kicad)


Fortschrittlich wäre es, wenn das Schematic komplett automatisch erzeugt 
würde. Gerade bei kleineren Schaltungen und bei Einmann-Projekten ist 
das sehr gut.
Wenn ich einen Footprint ins PCB ziehe und Netznamen an die Pins gebe, 
dann soll er halt automatisch das (ggf aus mehren Teil-Symbolen 
bestehende) Symbol im Schematic anlegen und die Pins benetzen.

Warum muss oder soll ich heute überhaupt noch Schematic-Symbole malen?

Merging von Netzen im PCB/Layout-Tool auf Nachfrage. Gibt es seit 
Jahrzehnten (natürlich nicht bei Kicad).

Demgegenüber ist das Gezerre bei Kicad manchmal schon unglaublich. Die 
sind konservativer und restriktiver als Intel, Texas und Siemens 
zusammen. Hauptsache klick-bunti.

[Possetitjel (Gast)]

Simon schrieb:

> Meine Sicht der Dinge ist nach wie vor, dass das
> Schema der Ursprung ist und sich das Layout diesem
> unterzuordnen hat.

Du scheinst mit dieser Sicht ja nicht ganz allein
dazustehen -- aber Diskussionen wie diese haben ja
auch den Zweck, mal die Frage zu stellen: Was würde
passieren, wenn man mal eine andere Sicht der Dinge
einnimmt?


> Nur im von Dir erwähnten Beispiel sehe ich, dass man
> sich da viel Arbeit ersparen könnte.

Nicht nur in diesem Beispiel.

Eine der wenigen Schaltungen, für die ich mal ein Layout
gemacht habe, war eine Prüfschaltung mit einem Mikro-
controller.
Dort genau dieselbe Scheisse: Massenhaft Pins sind im
Prinzip gleichwertig, weil man ohnehin in der Software
definiert, welcher I/O-Pin was macht -- aber die
Layoutsoftware bietet keinerlei Hilfestellung für
diesen Fall.


> Andererseits - das ist aber ein reines,vielleicht
> falsches, Bauchgefühl - würde ich selbst da ungern
> zulassen, dass das Schematool mir Leitungen im Schema
> verändert oder Labels umbenennt.

Nein -- das Bauchgefühl ist schon richtig: Software soll
sich vorhersagbar verhalten.

Auf der anderen Seite: Wenn man Bauteile und Verbindungen
in den Schaltplan einfügen und auf Knopfdruck die Daten
an den Layouteditor übergeben kann -- warum sollte man
dann nicht auch Bauteile und Verbindungen ins Layout
einfügen und die Daten per Knopfdruck an den Schaltplan-
editor übergeben können? Da ist doch nix Magisches dabei.

[W.S. (Gast)]

Lars R. schrieb:
> Fortschrittlich wäre es, wenn das Schematic komplett automatisch erzeugt
> würde. Gerade bei kleineren Schaltungen und bei Einmann-Projekten ist
> das sehr gut.
> Wenn ich einen Footprint ins PCB ziehe und Netznamen an die Pins gebe,
> dann soll er halt automatisch das (ggf aus mehren Teil-Symbolen
> bestehende) Symbol im Schematic anlegen und die Pins benetzen.

Ach?

Also du ziehst dir nen QFP64 ins Board und erwartest von der 
EDA-Software, daß sie deine Gedanken lesen kann und das richtige Symbol 
ins Schematic packt. O ha. War das nun ein Mikrocontroller oder ein CPLD 
oder ein Audiocodec oder was ganz anderes?

Nee, deine Gedanken sind wirr. Bei ein wenig Nachdenkens wäres du von 
selber auf den immanenten Unsinn gekommen.

Aber auch das Gegenteil ist Nonsense: In eine Schaltung zeichnet man 
Symbole, aber die stehen für einen Teil eines real existierenden 
Bauteils und dieses nun hat einen Footprint.

Nochmal zur Klarheit: Ein Symbol hat KEINEN Footprint. Das Haben eines 
Footprints ist das alleinige Privileg eines echten Bauteils - und dieses 
Bauteil kann seinerseits mit einem oder mehreren (im Prinzip beliebig 
vielen) Symbolen in der Schaltung beschrieben werden.

W.S.

[Michael R. (Firma: Brainit GmbH) (fisa)]

Possetitjel schrieb:
> Ja: Ein Grund ist häufig, dass die Dinge, die im Computer
> abgebildet bzw. modelliert werden sollen, entstanden sind,
> bevor es den Begriff "Datenmodell" überhaupt gab :)

Ach... Nortel hat vermutlich schon Datenmodelle gemacht, da warst du 
noch nicht auf der Welt...

> Beim E-CAD ist die Sachlage insofern anders, als dass das
> eine relativ junge Sparte ist, die sich erst entwickelt.
> Wir haben also jetzt die Möglichkeit, neue Begriffe und
> Konventionen zu schaffen, und diese können konsistent oder
> widersprüchlich sein, je nachdem.

ECAD jung? Ach...

>> Es spricht doch nichts dagegen, die Möglichkeit zu bieten,
>> gewisse Parameter in beiden Design-Welten (also Schaltplan
>> und Layout) zu definieren, und FB-Anno hilft, die synchron
>> zu halten.
>
> Doch, es spricht etwas dagegen: Die Normalformtheorie.

Ach ach ach...

W.S. hat es auf den punkt gebracht: Du hast dich verstiegen. Schlaf mal 
drüber...

[Possetitjel (Gast)]

W.S. schrieb:

> Possetitjel schrieb:
>> Zweite Bemerkung: Der Footprint hat (logisch) gar nix
>> im Schaltplan zu suchen; das ist eine Angabe, die in die
>> STÜCKLISTE gehört.
>> Aus mir rätselhaften Gründen gibt es weite Teile der
>> EDA-Welt, die sich standhaft weigern, die Stückliste als
>> gleichberechtigte Fertigungsunterlage neben z.B. dem
>> Schaltplan und dem Layout anzusehen.
>
> Du hast dich verstiegen, ganz einfach verstiegen.

Natürlich.

Und so lange ich keine guten Sachgründe sehe, von meiner
Meinung abzurücken, rücke ich nicht ab. (Du machst das
ja schließlich auch nicht anders, oder?)

Die bloße ständig wiederholte Behauptung, ich hätte
Unrecht, überzeugt mich nicht davon, dass ich Unrecht habe.


> Zuerst mal eins: eine automatische V/R-Annotation ist
> etwas essentielles [...]

Nein. Du setzt unhinterfragt voraus, was gerade geklärt
werden soll: Es wird wie immer diskussionslos voraus-
gesetzt, DASS es zwei Datenobjekte gibt, die konsistent
gehalten werden müssen.

Ich halte -- zum wiederholten Male -- entgegen: Innerhalb
eines Projektes gibt es nur EINEN EINZIGEN R42; datenbank-
technisch gesprochen ist die ID "R42" ein Schlüssel.
Das ist auch sinnvoll, weil es auf der fertigen Leiterplatte
AUCH NUR EINEN EINZIGEN R42 gibt.

Dieser R42 hat ein Schaltplansymbol, einen Wert, ein Gehäuse,
einen Footprint (und vielleicht noch weitere Attribute).
Den internen Container, in dem die EDA-Software solcherart
Zuordnungen speichert, nenne ich "Stückliste".

Und ich wiederhole verzeifelt meine Frage: WAS soll da
forward und backward annotiert werden, um es konsistent
zu halten? Es gibt da nichts konsistent zu halten, weil
die Zuordnung nur ein einziges Mal gespeichert wird!

Und sie wird nur ein einziges Mal gespeichert, weil es
nur einen einzigen R42 GIBT !

Im Schaltplaneditor ist R42 ein Fremdschlüssel, über den
der Widerstandswert und z.B. das Symbol aus der Datenbank
namens "Stückliste" abgerufen werden können.
Im Layouteditor ist R42 auch ein Fremdschlüssel, über den
der Footprint aus der Datenbank namens "Stückliste" abgerufen
werden können.

Was ist daran so kompliziert?

Ich bin -- auch wenn es nicht so scheinen mag -- durchaus
lernwillig, aber dafür gibt es eine Bedingung: Wer meine
Gedanken durch Anwendung passender Argumente ändern möchte,
der möge sich BITTE auf das oben von mir skizzierte Modell
einlassen und mir zeigen, warum es nicht praxisgerecht ist.

Die bloße Behauptung "Das ist Schwachsinn" oder "in Eagle
geht das ganz anders" genügt nicht.

(Ach so, nur zur Klarstellung: Mir ist bewusst, dass die
übliche EDA-Software nicht dem oben skizzierten Modell
folgt. Genau das halte ich ja auch für den fundamentalen
Fehler der üblichen EDA-Software.)

[Karl der erste von oben (Gast)]

W.S. schrieb:
> Zuerst mal eins: eine automatische V/R-Annotation ist etwas essentielles.....

Nur wenn man Änderungen im Layout machen kann, die man besser wo anders 
gemacht hätte.

Bleibt doch beim Adler. Aber hört bitte endlich auf, dessen 
Designentscheidungen als das einzig wahre zu predigen. Ist ja wie in der 
Kirche hier. Im Mittelalter. Kreuzzüge inkl.

[Lars R. (lrs)]

W.S. schrieb:
> Lars R. schrieb:
>> Fortschrittlich wäre es, wenn das Schematic komplett automatisch erzeugt
>> würde. Gerade bei kleineren Schaltungen und bei Einmann-Projekten ist
>> das sehr gut.
>> Wenn ich einen Footprint ins PCB ziehe und Netznamen an die Pins gebe,
>> dann soll er halt automatisch das (ggf aus mehren Teil-Symbolen
>> bestehende) Symbol im Schematic anlegen und die Pins benetzen.
>
> Ach?
>
> Also du ziehst dir nen QFP64 ins Board und erwartest von der
> EDA-Software, daß sie deine Gedanken lesen kann und das richtige Symbol
> ins Schematic packt.


Ja genau. Entweder es wird ein Symbol (Bauteil) ausgewählt oder ein 
neues Symbol erstellt. Bei QFP64 ist klar, wie viele Pins an jeder der 4 
Seiten des Package sind. Je nach Nutzereinstellung soll er schon mal 
standardmäßig ein 4-teiliges Symbol machen. Vielleicht reicht mir das ja 
schon und nach dem Erstellen des PCB ist auch das Schematic fertig.

Auf jeden Fall will ich nicht die Vierecke des Symbols malen und die 
Pins in einem bestimmten Abstand einzeln anlegen. Auch nicht 
parametrisiert. Denn das Symbol verwendet dann ein bestimmtes 
Pin-Raster. Und für ein anderes Pin-Raster male ich ein neues Symbol. 
Das ist überhaupt nicht erforderlich und stammt aus einer Zeit, als die 
Rechner zu dumm waren, um ein Viereck zu zeichnen.

Teilweise gibt schließlich bereits Funktionen, um Powerpins in einem 
Teilsymbol automatisch zusammen zu fassen.

Die Eingabe der Pinbezeichner eines Symbols sollte prinzipiell über 
CSV-Dateien erfolgen (falls überhaupt). Warum soll ich dafür in einer 
GUI herum klicken und mir die Arbeit machen, die Striche zurecht zu 
rücken?

[Possetitjel (Gast)]

Michael R. schrieb:

> Possetitjel schrieb:
>> Ja: Ein Grund ist häufig, dass die Dinge, die im Computer
>> abgebildet bzw. modelliert werden sollen, entstanden sind,
>> bevor es den Begriff "Datenmodell" überhaupt gab :)
>
> Ach... Nortel hat vermutlich schon Datenmodelle gemacht,
> da warst du noch nicht auf der Welt...

Ja - und?

Ich kenne Dich eigentlich als sachlichen Teilnehmer und
diskutiere gern mit Dir; könntest Du bitte wieder auf die
Sachebene zurückfinden?

>> Beim E-CAD ist die Sachlage insofern anders, als dass das
>> eine relativ junge Sparte ist, die sich erst entwickelt.
>> Wir haben also jetzt die Möglichkeit, neue Begriffe und
>> Konventionen zu schaffen, und diese können konsistent oder
>> widersprüchlich sein, je nachdem.
>
> ECAD jung? Ach...

Natürlich.

Der Siegeszug des Drehstromes begann WIMRE 1898. Anlass für
die Entwicklung der Vierpoltheorie war u.a. die Entwicklung
des Telephonnetzes; ich habe jetzt nicht gegurgelt, aber
Feldtkeller und Co. müssen so um 1920 herum aktiv gewesen
sein.

Wo war da ECAD?

ECAD kann frühestens in den 70ern weitere Kreise gezogen
haben -- passend zur Feier "100 Jahre Elektrotechnik".

>>> Es spricht doch nichts dagegen, die Möglichkeit zu bieten,
>>> gewisse Parameter in beiden Design-Welten (also Schaltplan
>>> und Layout) zu definieren, und FB-Anno hilft, die synchron
>>> zu halten.
>>
>> Doch, es spricht etwas dagegen: Die Normalformtheorie.
>
> Ach ach ach...
>
> W.S. hat es auf den punkt gebracht: Du hast dich verstiegen.
> Schlaf mal drüber...

Du machst mich echt wütend.

Wenn Du ein Sachargument hast, dann sollte ich als Dein
Diskussionspartner es Dir doch wert sein, dass Du es hier
auch darstellst. (Oder habe ich Dich irgendwo herabgesetzt
oder beleidigt? Das war nicht meine Absicht.)

Dauernd wird hier beschworen, dass Daten konsistent gehalten
werden müssen -- aber nirgendwo wird für mich nachvollziehbar
erklärt, warum man sie überhaupt mehrfach speichern muss!

[Possetitjel (Gast)]

Lars R. schrieb:

>> Also du ziehst dir nen QFP64 ins Board und erwartest
>> von der EDA-Software, daß sie deine Gedanken lesen
>> kann und das richtige Symbol ins Schematic packt.
>
> Ja genau.

Wie soll das gehen?

Schließlich gibt es hunderte ganz verschiedene Bauteile
im QFP64.

[Lars R. (lrs)]

Possetitjel schrieb:
> Lars R. schrieb:
>
>>> Also du ziehst dir nen QFP64 ins Board und erwartest
>>> von der EDA-Software, daß sie deine Gedanken lesen
>>> kann und das richtige Symbol ins Schematic packt.
>>
>> Ja genau.
>
> Wie soll das gehen?
>
> Schließlich gibt es hunderte ganz verschiedene Bauteile
> im QFP64.

Das habe ich doch geschrieben:
Beitrag "Re: Erfahrungen mit KiCAD von Eagle-Wechslern"


Wie ist Deine Frage?

Edit:
Pinbezeichner könnte sich das Programm auch vorläufig aus den im 
Layout-Tool zugewiesenen Netznamen holen.
Es geht doch darum:
Wenn ich ein Design aus dem Handgelenk machen will, dann will ich genau 
das.
Und ich will die Symbole nicht anlegen. Es ist doch klar, wie das Symbol 
auszusehen hat:
. Bei kleinen Footprints (Pinzahl) sieht das Symbol wie der Footprint 
aus
. sonst: strukturiert; ggf. Teilsymbole

[Possetitjel (Gast)]

Lars R. schrieb:

> Das habe ich doch geschrieben:
> Beitrag "Re: Erfahrungen mit KiCAD von Eagle-Wechslern"
>
> Wie ist Deine Frage?

Das habe ich doch geschrieben: Wie soll das gehen?
SCNR


> Edit:
> Pinbezeichner könnte sich das Programm auch vorläufig
> aus den im Layout-Tool zugewiesenen Netznamen holen.
> Es geht doch darum: Wenn ich ein Design aus dem Handgelenk
> machen will, dann will ich genau das.

Dann habe ich nicht verstanden, was Du gemeint hast.

Lass' mich beschreiben, was ich verstanden habe, und
korrigiere mich bitte entsprechend:

Deinen Beitrag weiter oben habe ich so verstanden: Du
hast ein Bauteil (z.B. einen FPGA) in der programmeigenen
Bauteildatenbank ("Library"). Du fügst dieses Bauteil
ins LAYOUT (nicht in den Schaltplan!) ein, ziehst
Verbindungen, und möchtest diese im Layout angelegten
Verbindungen im Schaltplan sehen und weiterbearbeiten
können.

Deinen letzten Beitrag verstehe ich anders: Du möchstest
ein Layout mit einem Bauteil anlegen, das Du NICHT in der
Datenbank hast. Dazu willst Du "on the fly" zunächst das
Bauteil definieren, dann im Layout Verbindungen verlegen,
und schließlich den zugehören Schaltplan sehen können.

Die Varianten sind zwar ähnlich, aber nicht gleich.
Daher meine Verwirrung.

[Lars R. (lrs)]

Possetitjel schrieb:
> Deinen Beitrag weiter oben habe ich so verstanden: Du
> hast ein Bauteil (z.B. einen FPGA) in der programmeigenen
> Bauteildatenbank ("Library"). Du fügst dieses Bauteil
> ins LAYOUT (nicht in den Schaltplan!) ein, ziehst
> Verbindungen, und möchtest diese im Layout angelegten
> Verbindungen im Schaltplan sehen und weiterbearbeiten
> können.

Richtig. Für existierende Bauteile möchte ich das. Diese Bauteile haben 
bereits ein Symbol (oder mehrere) und sie haben bereits Pinbezeichner.
Kleine Footprints, die im Layout nah beieinander sind und verbunden 
sind, sollen auch im Schematic automatisch beieinander angeordnet 
werden.


> Deinen letzten Beitrag verstehe ich anders: Du möchstest
> ein Layout mit einem Bauteil anlegen, das Du NICHT in der
> Datenbank hast. Dazu willst Du "on the fly" zunächst das
> Bauteil definieren, dann im Layout Verbindungen verlegen,
> und schließlich den zugehören Schaltplan sehen können.


Richtig. Ich möchte einen Footprint ins Layout ziehen. Dann soll eine 
Auswahl möglicher, bereits vorhandener Symbole angeboten werden. Wähle 
ich keines der vorhandenen Symbole aus, so soll automatisch ein Symbol 
(oder mehrere Teilsymbole) erstellt werden.

(Teil-)automatisierte Symbol-Erstellung gibt es bereits. Das Problem 
ist, dass die Symbolerstellung typischerweise vor der Erstellung des 
Footprint erfolgt.
Dh, die Vorgehensweise ist folgende:
1. Man erstellt das Symbol.
2. Man macht das Symbol hübsch, damit es ggf so ähnlich wie der 
Footprint aussieht,
3. Man erstellt den Footprint


Bei QFP44 würde ich sagen: Das Symbol möge einfach wie der Footprint 
aussehen. Die Schaltung mache ich aus dem Handgelenk im Layouteditor und 
ich vergebe die Netznamen im Layouteditor. Das Tool erstellt bitte alle 
unbekannten Symbole automatisch und erstellt das Schematic automatisch.

Für Pinbezeichner von Symbolen sollte es CSV-Dateien geben. Die 
Standardeingabe sollte NICHT grafisch sein.

Pinraster im Schematic seien dynamisch. Dh, das Pinraster eines Symbols 
kann jeder Zeit geändert werden und dann ändert das Symbol seine Größe 
und die Anordnung der Pins.

[Karl (Gast)]

Simon schrieb:
> Eine ganz unqualifizierte Anmerkung dazu: Vor laaaaaanger Zeit, als ich
> im Studium mal mit Protel (später Altium) gearbetet habe, wurde mir
> richtiggehend eingetrichtert, die FB-Annotation NIE NIE NIE zu
> verwenden

Protel 99 SE? Ich weiss noch wie es unserem damaligen Elektroniker 
regelmäßig Schweissperlen auf die Stirn getrieben hat, wenn er den 
Speichern-Button klickte - und die Bombe kam.

Ich hab mit Eagle seit 3.irgendwas gearbeitet, und FB-Anno ging dann 
schief, wenn man das Schematic geschlossen hat und allein im Board 
weitergearbeitet hat. Was auch irgendwo klar ist. Spätestens seit 6 
warnt Eagle dann ganz gross und fett.

Ich mach das manchmal, wenn ich ne kleine Leiterplatte fertiggeroutet 
habe und davon schnell mal ein paar Kopien nebeneinander brauche. 
Schematic aus, Board unter neuem Namen speichern!, Board kopieren.

W.S. schrieb:
> in einer Welt, wo V/R-Annotation dank leistungsfähiger PC's
> überhaupt kein Problem mehr ist?

Was heisst hier leistungsfähige PCs? Das ging schon vor 15 Jahren auf 
einem 700 MHz Pentium 3 mit 500MByte RAM. Ich seh auch nicht, wieso das 
groß Leistung brauchen sollte?

Possetitjel schrieb:
> Wie soll das gehen?
> Schließlich gibt es hunderte ganz verschiedene Bauteile
> im QFP64.

Es ist durchaus nicht unüblich bei der Analyse einer unbekannten 
Schaltung - zum Beispiel zur Reparatur - sich erstmal die reinen 
Packages hinzupacken und so zu verbinden, wie sie auf der Leiterplatte 
liegen, um dann nach und nach den Schaltplan zu bereinigen und den 
Teilen Namen zu geben.

[Bernd W. (berndwiebus)]

Hallo Possetitjel.

Possetitjel schrieb:

> Aus mir rätselhaften Gründen gibt es weite Teile der
> EDA-Welt, die sich standhaft weigern, die Stückliste als
> gleichberechtigte Fertigungsunterlage neben z.B. dem
> Schaltplan und dem Layout anzusehen.

Das sind die gleichen Leute, die meinen, dass in einen Schaltplan 
unbedingt  zusätzlich zum Referenzbezeichner die Bauteilwerte 
eingetragen sein sollten......

Ausser bei sehr kleinen Schaltungen bzw. für Bausätze ist das aber keine 
so gute Idee, weil es den Schaltplan unübersichtlich macht. Ausserdem 
muss  dann bei jeder Bauteiländerung der Schaltplan erneuert werden, und 
nicht nur die Stückliste.

Stücklisten haben auch den Charm, dass man dort jede Menge 
Zusatzinformationen hineinstecken kann, die auf keinen Fall in einen 
Schaltplan passen würden, wie z.B. Hinweise für den Bestücker, welche 
alternativen Transistoren aus welcher Quelle er einsetzten darf, falls 
die original vorgesehehen nicht lieferbar sind.


>
>
>> Ich verwende oft Schaltungsteile woanders wieder, oder
>> erstelle eine neue Version einer Schaltung. Da will
>> ich nicht jedesmal wieder die Footprints neu zuweisen
>> müssen.
>
> Das verstehe und akzeptiere ich.
>
> Komponenten rekursiv aus anderen Komponenten zusammen-
> zusetzen führt auf eine Baumstruktur oder eine Halb-
> ordnung. Bäume bilden Hierarchien ab.
>
> Du meckerst über fehlende feedback annotation, beschreibst
> aber hierarchisches Schaltplandesign. Findest Du das
> logisch?

Hierarchische Schaltpläne kann KiCad gut. So gut, dass die anno 2008 für 
mich der Grund zum Wechsel von Eagle nach KiCad waren.

"Back annotation" braucht man tatsächlich eher nicht. Eine 
Schaltungsänderung wird halt zuerst im Schaltplan, und dann im Board 
durchgeführt. Wo ist da nun jetzt das Problem? Probleme, eine im Board 
durchgeführte Bastelei adäquat in den Schaltplan einzufügen? Das wäre 
ein Indiz für "den Überblick" verloren. ;O)


>> Das ist so diese typische "works for me" Denke: Was
>> ich nicht brauche, brauchen andere auch nicht.
>
> Möchtest Du diesen Vorwurf vielleicht nochmal überdenken?

Unter diesem Aspekt könnte eine "Back annotation" von einigen als bequem 
eingestuft werden. Persönlich bearbeide ich aber selber schon in 
Gedanken den Schaltplan, auch wenn ich am (realen) Board herumbastel. 
Wenn ich theoretisch nicht nachvollziehen könnte, was ich da gerade 
Bastel, wäre ich mir selber unheimlich. ;O)

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

[Karl (Gast)]

Bernd W. schrieb:
> "Back annotation" braucht man tatsächlich eher nicht.

Da hast Du recht. Brauchen braucht man das nicht. Man braucht auch kein 
Layoutprogramm. Kann man alles von Hand auf Millimeterpapier zeichnen. 
Man kann auch Schaltpläne auf Karopapier zeichnen.

Ham wir früher so gemacht. Stundenlang. Will ich nicht zurückhaben.

[Possetitjel (Gast)]

Lars R. schrieb:

> Richtig. Für existierende Bauteile möchte ich das.
> Diese Bauteile haben bereits ein Symbol (oder
> mehrere) und sie haben bereits Pinbezeichner.

Okay, soweit klar und einfach.


> Kleine Footprints, die im Layout nah beieinander
> sind und verbunden sind, sollen auch im Schematic
> automatisch beieinander angeordnet werden.

Das hat Anklänge an eine "Kartoffeldruck"-Idee:
Schaltungssplitter, die als Teilmodule angelegt werden
und quasi wie Bauteile aus der Library abgerufen,
platziert und verschaltet werden können (triviale
Beispiele: LED mit Vorwiderstand; Schalttransistor
mit Basiswiderstand). Trick dabei: Diese Grundschaltungs-
muster müssen trotzdem noch parametrierbar und nicht
komplett vordefiniert sein. Weiterer Trick: Redundante
Bauteile (z.B. Vorwiderstände), die doppelt entstehen
würden, weil bei Teilschaltungen ihn mitbringen, würden
erkannt und eliminiert.


> Richtig. Ich möchte einen Footprint ins Layout ziehen.
> Dann soll eine Auswahl möglicher, bereits vorhandener
> Symbole angeboten werden. Wähle ich keines der
> vorhandenen Symbole aus, so soll automatisch ein Symbol
> (oder mehrere Teilsymbole) erstellt werden.

Ah okay. Ich verstehe. Hmm. Warum nicht.

Das läuft darauf hinaus, in der Stückliste eine ID zu
erzeugen und diesem Bauteil erstmal nur einen Footprint
zuzuordnen. Sollte technisch kein Problem sein (obwohl
ich es von der Bedienerführung her nicht schön finde,
das im Layouteditor zu machen. Das gehört "eigentlich"
in die Bauteildatenbank.)


> (Teil-)automatisierte Symbol-Erstellung gibt es bereits.
> Das Problem ist, dass die Symbolerstellung typischerweise
> vor der Erstellung des Footprint erfolgt.
> Dh, die Vorgehensweise ist folgende:
> 1. Man erstellt das Symbol.
> 2. Man macht das Symbol hübsch, damit es ggf so ähnlich
>    wie der Footprint aussieht,
> 3. Man erstellt den Footprint

Naja, das würde mich eben dazu bewegen, das alles in das
User-Interface der Bauteildatenbank (oder der "Stückliste")
schieben, wo es ja rein logisch auch hingehört.

Das Mantra wäre dann: Man kann weder im Schaltplan noch
im Layout ein Bauteil platzieren, das nicht wenigstens
eine Bauteilklassen-ID UND ENTWEDER ein Symbol (für den
Schaltplan) ODER einen Footprint (fürs Layout) in der
Stückliste hat.


> Bei QFP44 würde ich sagen: Das Symbol möge einfach wie
> der Footprint aussehen.

Das ist ja leicht durch einen passenden Default machbar.


> Die Schaltung mache ich aus dem Handgelenk im Layouteditor
> und ich vergebe die Netznamen im Layouteditor.

Was willst Du mit den Netznamen? Wegen der Pinbezeichnungen,
oder warum?

> Für Pinbezeichner von Symbolen sollte es CSV-Dateien geben.
> Die Standardeingabe sollte NICHT grafisch sein.

Ja, auf jeden Fall. Auch so eine Arbeitsbeschaffungsmaßnahme.

Stellt sich die weiterführende Frage: Könnte man die Pinnamen
auch (halb-)automatisch irgendwo extrahieren? Aus den Daten-
blätter zum Beispiel? Oder gibt es SPICE-/VHDL-Files, wo man
das entnehmen kann?


> Pinraster im Schematic seien dynamisch. Dh, das Pinraster
> eines Symbols kann jeder Zeit geändert werden und dann
> ändert das Symbol seine Größe und die Anordnung der Pins.

Ja gut... automatisches Erzeugen "schöner" Schaltpläne ist
ein anderes Trauerspiel.

[Possetitjel (Gast)]

Karl schrieb:

> Possetitjel schrieb:
>> Wie soll das gehen?
>> Schließlich gibt es hunderte ganz verschiedene Bauteile
>> im QFP64.
>
> Es ist durchaus nicht unüblich bei der Analyse einer
> unbekannten Schaltung - zum Beispiel zur Reparatur -
> sich erstmal die reinen Packages hinzupacken und so
> zu verbinden, wie sie auf der Leiterplatte liegen, um
> dann nach und nach den Schaltplan zu bereinigen und den
> Teilen Namen zu geben.

Okay, ja, es stimmt. Lars' Idee hörte sich zunächst
abstrus an, aber es gibt dafür durchaus mehr Szenarien,
als ich spontan erwartet hatte.

[Lars R. (lrs)]

Possetitjel schrieb:
> Ich halte -- zum wiederholten Male -- entgegen: Innerhalb
> eines Projektes gibt es nur EINEN EINZIGEN R42; datenbank-
> technisch gesprochen ist die ID "R42" ein Schlüssel.
> Das ist auch sinnvoll, weil es auf der fertigen Leiterplatte
> AUCH NUR EINEN EINZIGEN R42 gibt.
>
> Dieser R42 hat ein Schaltplansymbol, einen Wert, ein Gehäuse,
> einen Footprint (und vielleicht noch weitere Attribute).
> Den internen Container, in dem die EDA-Software solcherart
> Zuordnungen speichert, nenne ich "Stückliste".

Ein Footprint kann mehrere Symbole haben.


Possetitjel schrieb:
>> Kleine Footprints, die im Layout nah beieinander
>> sind und verbunden sind, sollen auch im Schematic
>> automatisch beieinander angeordnet werden.
>
> Das hat Anklänge an eine "Kartoffeldruck"-Idee:
> Schaltungssplitter

Es ging mir nur darum, dass die Symbole beieinander sind, soweit 
möglich.


> Sollte technisch kein Problem sein (obwohl
> ich es von der Bedienerführung her nicht schön finde,
> das im Layouteditor zu machen. Das gehört "eigentlich"
> in die Bauteildatenbank.)

Kann ja. Es gibt eben einen Dialog Zuordnung-Footprint-Symbole. Nur, 
dieser Dialog kein zwingender Bestandteil des Schematic, sondern 
funktioniert auch ohne Schematic.


>> Die Schaltung mache ich aus dem Handgelenk im Layouteditor
>> und ich vergebe die Netznamen im Layouteditor.
>
> Was willst Du mit den Netznamen? Wegen der Pinbezeichnungen,
> oder warum?

Eine Schaltung braucht Netznamen.


> Stellt sich die weiterführende Frage: Könnte man die Pinnamen
> auch (halb-)automatisch irgendwo extrahieren? Aus den Daten-
> blätter zum Beispiel?

Ja, oder es gibt bereits Excel- oder CSV-Files.

>> Pinraster im Schematic seien dynamisch. Dh, das Pinraster
>> eines Symbols kann jeder Zeit geändert werden und dann
>> ändert das Symbol seine Größe und die Anordnung der Pins.
>
> Ja gut... automatisches Erzeugen "schöner" Schaltpläne ist
> ein anderes Trauerspiel.

Mir geht es darum, dass ein Symbol keine statisch gemalte Grafik zu sein 
braucht.

[Possetitjel (Gast)]

Hai Bernd.

Bernd W. schrieb:

>> Aus mir rätselhaften Gründen gibt es weite Teile der
>> EDA-Welt, die sich standhaft weigern, die Stückliste
>> als gleichberechtigte Fertigungsunterlage neben z.B.
>> dem Schaltplan und dem Layout anzusehen.
>
> Das sind die gleichen Leute, die meinen, dass in einen
> Schaltplan unbedingt zusätzlich zum Referenzbezeichner
> die Bauteilwerte eingetragen sein sollten......

Naja, wie Du schon sagst: Wenn es geht, ist es sehr nett,
aber es ist halt nicht immer praktikabel.


> Stücklisten haben auch den Charm, dass man dort jede
> Menge Zusatzinformationen hineinstecken kann, die auf
> keinen Fall in einen Schaltplan passen würden, wie
> z.B. Hinweise für den Bestücker, welche alternativen
> Transistoren aus welcher Quelle er einsetzten darf,
> falls die original vorgesehehen nicht lieferbar sind.

Naja, in der Praxis kann man nicht sinnvoll auf die
Stückliste verzichten. Das habe ich auf die harte Tour
gelernt, als ich mal eine kleine Weile für die Kleinst-
serienfertigung bei uns verantwortlich war... :)


> Hierarchische Schaltpläne kann KiCad gut. So gut, dass
> die anno 2008 für mich der Grund zum Wechsel von Eagle
> nach KiCad waren.

Das habe ich schon mehrfach gelesen; die Beschäftigung
damit steht auch auf meiner Liste...

> "Back annotation" braucht man tatsächlich eher nicht.
> Eine Schaltungsänderung wird halt zuerst im Schaltplan,
> und dann im Board durchgeführt. Wo ist da nun jetzt das
> Problem?

Das Problem ist (aus meiner Sicht), dass das (zumindest
in manchen Fällen) "broken by design" ist.

Es sollte für jede benötigte Information EINE Stelle
Stelle geben, wo diese Information verbindlich gespeichert
ist. Alle anderen Stellen im Programm, die die Information
visualisieren, abfragen, ändern, ... müssen, sollten auf
diese eine Stelle zugreifen (und zwar i.d.R. über
entsprechende Funktionsaufrufe).

Ich unterstütze ja die Forderung, dass die Daten projektweit
konsistent sein sollen -- aber an der Diskussion über
forward-backward-annotation regt mich auf, dass immer wieder
eine bestimmte Lösung eines Problems eingefordert wird, das
nur aufgrund eines Designfehlers überhaupt entsteht!

> Probleme, eine im Board durchgeführte Bastelei adäquat in
> den Schaltplan einzufügen? Das wäre ein Indiz für "den
> Überblick" verloren. ;O)

Naja, nicht zwingend.
Das, was Lars und Karl geschrieben haben, gibt für mich
schon Sinn.

[Lars R. (lrs)]

Possetitjel schrieb:
> Es sollte für jede benötigte Information EINE Stelle
> Stelle geben, wo diese Information verbindlich gespeichert
> ist. Alle anderen Stellen im Programm, die die Information
> visualisieren, abfragen, ändern, ... müssen, sollten auf
> diese eine Stelle zugreifen (und zwar i.d.R. über
> entsprechende Funktionsaufrufe).
>
> Ich unterstütze ja die Forderung, dass die Daten projektweit
> konsistent sein sollen -- aber an der Diskussion über
> forward-backward-annotation regt mich auf, dass immer wieder
> eine bestimmte Lösung eines Problems eingefordert wird, das
> nur aufgrund eines Designfehlers überhaupt entsteht!

Ein Footprint hat eine Pinanzahl. Ein Symbol (Symbolgruppe) hat eine 
Pinanzahl. Für die Zuordnung Footprint<>Symbol muss die Pinzahl überein 
stimmen.



Ein Footprint kann eine Verlustleistung haben.
Ein Symbol kann eine Verlustleistung haben.

Hat ein Footprint ein Verlustleistung und hat das Symbol eine 
Verlustleistung, so sollten diese für eine Zuordnung Footprint<>Symbol 
übereinstimmen.

Frage: Wo ist nun die Verlustleistung gespeichert?
Antwort: Im Symbol und auch im Footprint


Man kann im Schematic ein Symbol setzen ohne Footprint.
Man kann im PCB einen Footprint setzen ohne Symbol.


Was passiert, wenn im Schematic die Verlustleistung verändert wird, 
obwohl bereits eine Zuordnung Footprint<>Symbol besteht? Wird dann 
mangels passender Verlustleistung automatisch der Footprint im PCB 
gelöscht?


Die Lösung/Antwort ist folgende:
Das Attribut Verlustleistung existiert in der Datenbank für den 
Footprint und im PCB für die Instanz dieses Footprints.

Das Attribut Verlustleistung existiert in der Datenbank für das Symbol 
und im Schematic für die Instanz dieses Symbols.

Annotation verändert dann die Werte der Instanzen. Ebenso, wie diese 
Werte bei der Zuordnung überschrieben werden können um eine Zuordnung zu 
erzwingen.

Dh, den Wert Verlustleistung gibt es 4x.

[Possetitjel (Gast)]

Lars R. schrieb:

> Possetitjel schrieb:
>> Ich halte -- zum wiederholten Male -- entgegen:
>> Innerhalb eines Projektes gibt es nur EINEN
>> EINZIGEN R42; datenbanktechnisch gesprochen ist
>> die ID "R42" ein Schlüssel. Das ist auch sinnvoll,
>> weil es auf der fertigen Leiterplatte AUCH NUR
>> EINEN EINZIGEN R42 gibt.
>>
>> Dieser R42 hat ein Schaltplansymbol, einen Wert,
>> ein Gehäuse, einen Footprint (und vielleicht noch
>> weitere Attribute). Den internen Container, in dem
>> die EDA-Software solcherart Zuordnungen speichert,
>> nenne ich "Stückliste".
>
> Ein Footprint kann mehrere Symbole haben.

Du sprichst in Rätseln. Mehr Kontext, bitte.

Ein - ich will es mal "generischer Footprint" nennen -
definiert nach meinem Verständnis nur Mechanik und
Geometrie.

Ein "spezifischer Footprint" ist Bestandteil einer
Bauelement-Definition und enthält noch Pinnamen und
solches Zeug.

Sicherlich kann dieselbe Bauelemente-Definition auch
mehrere alternative Schaltplansymbole enthalten (ein
Widerstand z.B. das europäische und das Ami-Symbol) --
aber inwiefern ist das hier relevant?


>> Sollte technisch kein Problem sein (obwohl
>> ich es von der Bedienerführung her nicht schön finde,
>> das im Layouteditor zu machen. Das gehört "eigentlich"
>> in die Bauteildatenbank.)
>
> Kann ja. Es gibt eben einen Dialog Zuordnung-Footprint-
> Symbole. Nur, dieser Dialog kein zwingender Bestandteil
> des Schematic, sondern funktioniert auch ohne Schematic.

Ja, selbstverständlich.
In dem Punkt sind wir einer Meinung.

>>> Die Schaltung mache ich aus dem Handgelenk im
>>> Layouteditor und ich vergebe die Netznamen im
>>> Layouteditor.
>>
>> Was willst Du mit den Netznamen? Wegen der
>> Pinbezeichnungen, oder warum?
>
> Eine Schaltung braucht Netznamen.

Klar, für die Netzliste -- aber rein technisch können
die auch vollautomatisch erzeugt werden und N001, N002,
N003 usw. sein.

>>> Pinraster im Schematic seien dynamisch. Dh, das Pinraster
>>> eines Symbols kann jeder Zeit geändert werden und dann
>>> ändert das Symbol seine Größe und die Anordnung der Pins.
>>
>> Ja gut... automatisches Erzeugen "schöner" Schaltpläne ist
>> ein anderes Trauerspiel.
>
> Mir geht es darum, dass ein Symbol keine statisch gemalte
> Grafik zu sein braucht.

Hmmja... auch Vektorgraphik ist "statisch gemalte Graphik",
aber skalierbar ist sie trotzdem... :)

Es ging Dir doch nur um den Aspekt, dass das Symbol keine
fixierte absolute Größe haben, sondern skalierbar sein soll --
oder habe ich Dich missverstanden?

[Lars R. (lrs)]

Possetitjel schrieb:
>> Ein Footprint kann mehrere Symbole haben.
>
> Du sprichst in Rätseln. Mehr Kontext, bitte.

Mehrere (Teil-)Symbole für einen Footprint.

Schon mal ein Schematic Symbol mit 2000 Pins gesehen?


>>>> Die Schaltung mache ich aus dem Handgelenk im
>>>> Layouteditor und ich vergebe die Netznamen im
>>>> Layouteditor.
>>>
>>> Was willst Du mit den Netznamen? Wegen der
>>> Pinbezeichnungen, oder warum?
>>
>> Eine Schaltung braucht Netznamen.
>
> Klar, für die Netzliste -- aber rein technisch können
> die auch vollautomatisch erzeugt werden und N001, N002,
> N003 usw. sein.

Ja. Sollte auch. Das sind auch Namen. Die kann man nach Bedarf ändern.

>>>> Pinraster im Schematic seien dynamisch. Dh, das Pinraster
>>>> eines Symbols kann jeder Zeit geändert werden und dann
>>>> ändert das Symbol seine Größe und die Anordnung der Pins.
>>>
>>> Ja gut... automatisches Erzeugen "schöner" Schaltpläne ist
>>> ein anderes Trauerspiel.
>>
>> Mir geht es darum, dass ein Symbol keine statisch gemalte
>> Grafik zu sein braucht.
>
> Hmmja... auch Vektorgraphik ist "statisch gemalte Graphik",
> aber skalierbar ist sie trotzdem... :)

Wenn Du in einem Schematic aber ein Viereck malst und fest legst, 
welchen Abstand die Pins des Symbols haben, dann ist das nicht 
dynamisch, sondern fest. -> "Pinraster"
Das Symbol eignet sich dann nur genau für dieses Pinraster.


> Es ging Dir doch nur um den Aspekt, dass das Symbol keine
> fixierte absolute Größe haben, sondern skalierbar sein soll --
> oder habe ich Dich missverstanden?

Ja.

[Possetitjel (Gast)]

Lars R. schrieb:

> Ein Footprint hat eine Pinanzahl. Ein Symbol
> (Symbolgruppe) hat eine Pinanzahl. Für die Zuordnung
> Footprint<>Symbol muss die Pinzahl überein stimmen.

Korrekt, aber ungünstiges Beispiel: Footprint und
Symbol sind im Datenbanksinn verschiedene Dinge,
deswegen ist dort nicht dieselbe Information
redundand gespeichert, sondern es sind unterschiedliche
Informationen.


> Ein Footprint kann eine Verlustleistung haben.

Nicht in meinen Universum.

Wenn man die Information haben will, welche Leistung
über Gehäuse X abführbar ist, dann formuliert man eine
passende Abfrage an die Datenbank und selektiert nach
Gehäuse und Verlustleistung.

> Ein Symbol kann eine Verlustleistung haben.

Noch viel weniger in meinem Universum.
Dem europäischen Widerstandssymbol ist unter überhaupt
keinen Umständen eine Verlustleistung zugeordnet. Nicht
bei mir.

[...]
> Man kann im Schematic ein Symbol setzen ohne Footprint.
> Man kann im PCB einen Footprint setzen ohne Symbol.
>
> Was passiert, wenn im Schematic die Verlustleistung
> verändert wird,

Das kann in meinem Universum nicht passieren, weil die
Bauteildefinition in der Stückliste bestimmt, welches
konkrete Bauteil tatsächlich verbaut wird.

Wenn ein "generischer" Schaltplan gezeichnet werden
soll, ist die Frage nach der zulässigen Verlustleistung
nicht beantwortenbar: Welche Verlustleistung verträgt
ein Widerstand in SPICE?

[...]
> Annotation verändert dann die Werte der Instanzen.

Okay... das ist ein neues Spielfeld, das hatten wir noch
nicht bisher. -- Annotationen verändern keine Werte,
sondern definieren Prüfbedingungen.


> Dh, den Wert Verlustleistung gibt es 4x.

Nicht in meinem Universum. Keinesfalls.

[Possetitjel (Gast)]

Lars R. schrieb:

> Possetitjel schrieb:
>>> Ein Footprint kann mehrere Symbole haben.
>>
>> Du sprichst in Rätseln. Mehr Kontext, bitte.
>
> Mehrere (Teil-)Symbole für einen Footprint.
>
> Schon mal ein Schematic Symbol mit 2000 Pins gesehen?

Nein. Ich bin Analog-Fuzzi.

Aber jetzt habe ich Dich verstanden, ja. Das Problem
hatte ich noch nicht auf dem Schirm.


>> Hmmja... auch Vektorgraphik ist "statisch gemalte Graphik",
>> aber skalierbar ist sie trotzdem... :)
>
> Wenn Du in einem Schematic aber ein Viereck malst und fest
> legst, welchen Abstand die Pins des Symbols haben, dann
> ist das nicht dynamisch, sondern fest. -> "Pinraster"
> Das Symbol eignet sich dann nur genau für dieses Pinraster.

Ach so -- okay. Technisches Ärgernis. Verstanden.

(Hmm. Wieso ist das eigentlich so? Hat doch keinen
sinnvollen Grund...?!)


>> Es ging Dir doch nur um den Aspekt, dass das Symbol
>> keine fixierte absolute Größe haben, sondern skalierbar
>> sein soll -- oder habe ich Dich missverstanden?
>
> Ja.

Super: "Kaffee oder Tee?" -- "Ja." :)

[Lars R. (lrs)]

Possetitjel schrieb:
>> Ein Footprint kann eine Verlustleistung haben.
>
> Nicht in meinen Universum.
>
> Wenn man die Information haben will, welche Leistung
> über Gehäuse X abführbar ist, dann formuliert man eine
> passende Abfrage an die Datenbank und selektiert nach
> Gehäuse und Verlustleistung.

Im Schematic wird der Footprint nicht zwingend festgelegt, sondern 
allenfalls optional.

Man will ja gerade die Entscheidung, welcher Footprint genutzt wird, im 
Schematic offen halten können.


...jetzt wird mir alles klar. Hier gibt es Begriffsschwierigkeiten 
folgender Art:

Typischerweise gibt es A. ein Schematic-Tool und B. ein Layout-Tool.


Einige hier, scheinbar insbesondere leidenschaftliche Kicad-Verfechter 
sehen jedoch:
A. ein Specification-Tool und B. ein Specification-to-Gerber-Tool.

Dann benennen sie das Specification-Tool als Schematic-Tool und das 
Specification-to-Gerber-Tool als Layout-Tool.

Das Umdeuten etablierter Begriffe gefällt mir nicht, wenngleich das 
heutzutage Mode ist.


>> Ein Symbol kann eine Verlustleistung haben.
>
> Noch viel weniger in meinem Universum.
> Dem europäischen Widerstandssymbol ist unter überhaupt
> keinen Umständen eine Verlustleistung zugeordnet. Nicht
> bei mir.
>
> [...]
>> Man kann im Schematic ein Symbol setzen ohne Footprint.
>> Man kann im PCB einen Footprint setzen ohne Symbol.
>>
>> Was passiert, wenn im Schematic die Verlustleistung
>> verändert wird,
>
> Das kann in meinem Universum nicht passieren, weil die
> Bauteildefinition in der Stückliste bestimmt, welches
> konkrete Bauteil tatsächlich verbaut wird.


Warum machst Du (bzw warum macht Ihr) dann überhaupt noch während des 
Designs die Zuordnung Footprint<>Symbol? Das müsstest Du dann zwingend 
gleich bereits beim Anlegen von Footprint und Symbol machen.

Na? Gotcha!


> Okay... das ist ein neues Spielfeld, das hatten wir noch
> nicht bisher. -- Annotationen verändern keine Werte,
> sondern definieren Prüfbedingungen.

Wieder Begriffsumdeutungen?

[Karl (Gast)]

..... und dabei wollte ich doch nur wissen, ob die Forward-Backward-Anno 
geht.....

So interessant eure Strategien sind, aber ein bißchen müßig ist das 
schon, oder? Die werden deswegen jetzt nicht Kicad umprogrammieren.

[Possetitjel (Gast)]

Karl schrieb:

> So interessant eure Strategien sind, aber ein bißchen
> müßig ist das schon, oder?

"Jemand gilt so lange als Spinner, bis sich seine Idee
durchgesetzt hat." (Mark Twain)


> Die werden deswegen jetzt nicht Kicad umprogrammieren.

Und? Es gibt auch noch geda-rnd und horizon.

[Possetitjel (Gast)]

Lars R. schrieb:

> Possetitjel schrieb:
>>> Ein Footprint kann eine Verlustleistung haben.
>>
>> Nicht in meinen Universum.
>>
>> Wenn man die Information haben will, welche Leistung
>> über Gehäuse X abführbar ist, dann formuliert man eine
>> passende Abfrage an die Datenbank und selektiert nach
>> Gehäuse und Verlustleistung.
>
> Im Schematic wird der Footprint nicht zwingend
> festgelegt, sondern allenfalls optional.

Richtig.

Die Bauteile im Schaltplan (Schematic) werden (nach meiner
Vorstellung) durch IDs repräsentiert, die auf die "Stückliste"
verweisen.
In der Stückliste stehen entweder vordefinierte Bauteile aus
der Bauteildatenbank ("Library") mit Symbol und Footprint,
oder ad-hoc-Bauteile, die z.B. nur Symbole enthalten können
(man will ja vielleicht einen "generischen" Schaltplan für
eine SPICE-Simulation zeichnen, der keine Footprints benötigt.)


> Man will ja gerade die Entscheidung, welcher Footprint
> genutzt wird, im Schematic offen halten können.

Jein: Man kann die Stückliste durch Zugriff auf die Bauteil-
datenbank füllen; dann wird man i.d.R. komplette Bauteile
mit Symbol und Footprint haben. Man kann natürlich auch
ad-hoc-Einträge vornehmen, dann hat man erstmal nur ein
Symbol (oder nur einen Footprint, das müsste auch gehen).

Insofern: Ja, die Entscheidung, ob man das eine, das andere
oder beides gleichzeitig haben will, ist offen.

> ...jetzt wird mir alles klar. Hier gibt es Begriffs-
> schwierigkeiten folgender Art:
>
> Typischerweise gibt es A. ein Schematic-Tool und B. ein
> Layout-Tool.

Ja, das ist meine Annahme. geda macht es z.B. so; KiCAD
meines Wissens auch.


> Einige hier, scheinbar insbesondere leidenschaftliche
> Kicad-Verfechter sehen jedoch:
> A. ein Specification-Tool und B. ein Specification-to-Gerber-Tool.
>
> Dann benennen sie das Specification-Tool als Schematic-Tool
> und das Specification-to-Gerber-Tool als Layout-Tool.

Ich kann Dir nicht folgen, ich weiss nicht, wovon Du sprichst.


> Das Umdeuten etablierter Begriffe gefällt mir nicht,
> wenngleich das heutzutage Mode ist.

Es wird sicher so sein, dass ich etablierte Begriffe ungewöhnlich
oder gar sinnwidrig verwende, aber sei versichert, das ist keine
böse Absicht.

Ich hatte beruflich sporadischen Kontakt zu OrCAD (ganz früher)
und zu Target3001; privat habe ich ganz schüchtern eagle, geda
und (ganz wenig) KiCAD ausprobiert.

ECAD ist zwar heutzutage eine Notwendigkeit für den Elektronik-
entwickler, aber mich schreckt jedesmal die grausige Ergonomie
der ECAD-Software ab.


>> Das kann in meinem Universum nicht passieren, weil die
>> Bauteildefinition in der Stückliste bestimmt, welches
>> konkrete Bauteil tatsächlich verbaut wird.
>
> Warum machst Du (bzw warum macht Ihr) dann überhaupt noch
> während des Designs die Zuordnung Footprint<>Symbol?

Wie Eagle und KiCAD das handhaben, weiss ich nicht aus dem
Stand.

geda kennt m.W. ganz konsequent NUR "generische" Symbole
im Schaltplan, d.h. "abstrakte" Bauteile ohne Footprint.
Zwischen Schaltplanerstellung und Layouterstellung ist
ein Zwischenschritt eingeschaltet, in dem den Symbolen
die Footprints zugeordnet werden müssen.

Bei Target ist es nach meiner Erinnerung so, dass man ziemlich
frei wählen kann, WANN man dem Schaltplansymbol einen Footprint
zuordnet. Es gibt zwar irgend eine Standard-Einstellung, aber
man kann das auch problemlos nachträglich ändern.

Insofern: Ja, es gibt mMn keinen zwingenden Grund, warum
man während der Schaltplanerstellung schon Footprints
zuordnen müsste. Man KANN das tun -- aber man MUSS nicht.


> Das müsstest Du dann zwingend gleich bereits beim Anlegen
> von Footprint und Symbol machen.

Jein: Es ist richtig, dass Bauteile in der Bauteildatenbank
immer beides haben müssen -- einfach weil die Bauteildatenbank
reale, kaufbare Bauteile abbilden soll, und reale, kaufbare
Bauteile eben immer sowohl Symbol (=elektrische Funktion) als
auch einen Footprint haben.

Wenn man also die "Stückliste" aus der Bauteildatenbank
befüllt, dann haben die Einträge in der Stückliste automatisch
Symbol UND Footprint. Soweit stimmt das.

Allerdings sollte es auch nicht verboten sein, in die Stückliste
erstmal NUR Symbole oder NUR Footprints hineinzuschreiben. Dann
kann man trotzdem einen Schaltplan bzw. ein Layout erstellen,
aber das jeweils andere geht noch nicht, weil die entsprechenden
Spalten in der Stückliste noch leer sind. Das muss später
nachgetragen werden, wenn man es braucht.


>> Okay... das ist ein neues Spielfeld, das hatten wir noch
>> nicht bisher. -- Annotationen verändern keine Werte,
>> sondern definieren Prüfbedingungen.
>
> Wieder Begriffsumdeutungen?

Sei versichert: Nicht absichtlich.

[Michael R. (Firma: Brainit GmbH) (fisa)]

Possetitjel schrieb:
> Ich unterstütze ja die Forderung, dass die Daten projektweit
> konsistent sein sollen -- aber an der Diskussion über
> forward-backward-annotation regt mich auf, dass immer wieder
> eine bestimmte Lösung eines Problems eingefordert wird, das
> nur aufgrund eines Designfehlers überhaupt entsteht!

Ich glaube mittlerweile, die (hitzige) Diskussion entsteht primär 
wirklich aus Begriffsverwirrungen ;-)

Possetitjel verwendet oft den begriff "Stückliste", versteht darunter 
aber was ganz spezielles, nämlich eine Art "Datenstruktur". Für mich ist 
der Begriff anderweitig belegt; eine Stückliste ist ein (weiteres) 
Element (sagen wir "Dokument") welches ein Item (Artikel, bestückte 
Platine) beschreibt. Mal abgesehen davon dass es nicht "die" Stückliste 
gibt, sondern viele Abwandlungen (Struktur-, Baukasten-, Mengen-, 
Varianten-, Auftrags-, Stamm-, Fertigungs-, ...-Stückliste) und diese 
idR ein "Abfallprodukt" des jeweiligen Autorensystems ist (ECAD, MCAD, 
PDM, ERP)

Deswegen wehre ich mich dagegen, die Stüli wäre "zentrale Instanz um 
gewisse Daten zu speichern". Wenn man Stüli hier durch einen anderen 
(welchen?) Begriff ersetzt, bin ich aber einverstanden ;-)

Ob bestimmte Informationen jetzt einmalig gespeichert werden, oder 
mehrfach, aber vom System konsistent gehalten werden, ist für den 
Anwender erstmal egal (auch wenn die einmalige Speicherung vorzuziehen 
ist). Wichtig ist doch nur, dass beim Anwender immer dieselbe 
Information ankommt, egal ob er die jetzt im Design, im Layout, in der 
Stückliste oder wo auch immer abruft.

Insofern ist FB-Anno auch nicht unbedingt ein "technisches" Feature (dem 
Anwender ist es erstmal egal wie das implementiert wird), es ist mehr 
Funktionalität die er nutzen kann und möchte.

Aus der Diskussion ist (für mich) einigermaßen klar, dass es ein 
legitimer Wunsch ist, Informationen an mehreren Stellen zu ändern: Einen 
Footprint im Design vorzugeben; einen Footprint im Layout zu ändern, 
aber auch einen Bauteilwert im Layout zu korrigieren (oder überhaupt 
erst zuzuweisen), und so weiter. Und, ganz wichtig: ich erwarte, 
Änderungen an einer Stelle an den anderen Stellen möglichst sofort 
(maximal 1-2 Mausklicks) und möglichst automatisch wiederzufinden.

In weiterer Folge sollte es aber möglich sein, gewisse Änderungen 
einzuschränken: wenn ich zB Layout extern vergebe (oder auch nur an eine 
andere Abteilung) möchte ich dort die Änderungsmöglichkeiten 
einschränken können. Das ist dann aber mehr eine Frage des 
Prozess-Designs.

Ein Fehlen der Möglichkeit dieser Einschränkung wäre eine 
Design-Schwäche, die man mit prozesstechnischen Workarounds bewerfen 
müsste.

Ein Fehlen der grundsätzlichen Möglichkeit (oder anders gesagt: das 
Bestehen einer grundsätzlichen Einschränkung) ist aber auch eine 
Designsschwäche.

Diese Designschwäche mag manche gar nicht treffen, manche leichter, 
manche schwerer. Aber es ist und bleibt eine Designschwäche. "braucht 
man nicht" ist die falsche Antwort.

[Lars R. (lrs)]

Karl schrieb:
> ..... und dabei wollte ich doch nur wissen, ob die Forward-Backward-Anno
> geht.....

Nein, geht nicht.

> So interessant eure Strategien sind, aber ein bißchen müßig ist das
> schon, oder? Die werden deswegen jetzt nicht Kicad umprogrammieren.

Doch, die schreiben das um. Das dauert nur.


Michael R. schrieb:
> Aus der Diskussion ist (für mich) einigermaßen klar, dass es ein
> legitimer Wunsch ist, Informationen an mehreren Stellen zu ändern: Einen
> Footprint im Design vorzugeben; einen Footprint im Layout zu ändern,
> aber auch einen Bauteilwert im Layout zu korrigieren (oder überhaupt
> erst zuzuweisen), und so weiter. Und, ganz wichtig: ich erwarte,
> Änderungen an einer Stelle an den anderen Stellen möglichst sofort
> (maximal 1-2 Mausklicks) und möglichst automatisch wiederzufinden.

Aus der Diskussion sollte hervor gehen, dass es nicht genau exakt einen 
Weg für alle Entwickler und für jedes Projekt geben muss, so wie das 
Kicad im Moment ein Stück weit erzwingt.

Es ist eben nicht sinnvoll, bei der Programmentwicklung festzulegen, 
dass jede Änderung des Layouts auch automatisch im Schematic erfolgen 
muss. Das sollte einstellbar oder abstellbar sein.


> In weiterer Folge sollte es aber möglich sein, gewisse Änderungen
> einzuschränken: wenn ich zB Layout extern vergebe (oder auch nur an eine
> andere Abteilung) möchte ich dort die Änderungsmöglichkeiten
> einschränken können.

Was meinst Du mit einschränken?
Bei der Annotation wird eben eingestellt, was annotatet wird. Weitere 
"Einschränkungen" braucht es nicht und diese könnten ohnehin umgangen 
werden.

Am Ende sieht man ohnehin, an welchen Stellen Schematic und Layout 
voneinander abweichen.



Michael R. schrieb:
> Ob bestimmte Informationen jetzt einmalig gespeichert werden, oder
> mehrfach, aber vom System konsistent gehalten werden, ist für den
> Anwender erstmal egal (auch wenn die einmalige Speicherung vorzuziehen
> ist).

Ein Layout muss auch ohne Schematic und ohne Symbole funktionieren.

Ein Schematic ist ein Schematic und ein Layout ist ein Layout
https://en.wikipedia.org/wiki/Schematic

https://en.wikipedia.org/wiki/Layout
https://en.wikipedia.org/wiki/Layout_(computing)

Wenn es nicht mehr um Schematic und Layout geht, sondern eine andere 
Aufteilung und Benennung verwendet, so kann man alles anders machen.

Jedoch bitte ich darum, diese Begriffe nicht umzudeuten. Eine 
Darstellung des Footprint als Symbol-Attribut ist in der 
Schematic-Layout-Welt schlicht falsch.

[KiCadSuperman (Gast)]

Possetitjel schrieb:
> Ich hatte beruflich sporadischen Kontakt zu OrCAD (ganz früher)
> und zu Target3001; privat habe ich ganz schüchtern eagle, geda
> und (ganz wenig) KiCAD ausprobiert.

Possetitjel schrieb:
> ECAD ist zwar heutzutage eine Notwendigkeit für den Elektronik-
> entwickler, aber mich schreckt jedesmal die grausige Ergonomie
> der ECAD-Software ab.

Wenn das deine Wissensbasis sein sollte, dann macht einem dein
Nassfrosches Auftreten hier irgendwie stutzig.
Du solltest in die Politik gehen da kann man Leute wie dich
gebrauchen :-)

[KiCadSuperman (Gast)]

Possetitjel schrieb:
> Naja, in der Praxis kann man nicht sinnvoll auf die
> Stückliste verzichten. Das habe ich auf die harte Tour
> gelernt, als ich mal eine kleine Weile für die Kleinst-
> serienfertigung bei uns verantwortlich war... :)



So könnte das zugehörige Arbeitszeugnis aussehen:

... bemühte sich redlich seinen Aufgaben gerecht zu werden.
                              (oder)
... hat nach Kräften versucht, die Leistungen zu erbringen,
      die wir an diesem Arbeitsplatz fordern müssen"

                           (und)

... war tüchtig und wusste sich gut zu verkaufen.

                        (Schlussformel)

Wir wünschen Ihm für die Zukunft alles Gute, auch Erfolg.

[Holm T. (Gast)]

W.S. schrieb:
> Possetitjel schrieb:
>> Zweite Bemerkung: Der Footprint hat (logisch) gar nix
>> im Schaltplan zu suchen; das ist eine Angabe, die in die
>> STÜCKLISTE gehört.
>> Aus mir rätselhaften Gründen gibt es weite Teile der
>> EDA-Welt, die sich standhaft weigern, die Stückliste als
>> gleichberechtigte Fertigungsunterlage neben z.B. dem
>> Schaltplan und dem Layout anzusehen.
>
> Du hast dich verstiegen, ganz einfach verstiegen.
>
> Zuerst mal eins: eine automatische V/R-Annotation ist etwas
> essentielles weil nur dadurch von der EDA-Soft gesichert ist, daß
> Schematic und Leiterplatte tatsächlich konsistent sind - und Konsistenz
> zwischen beiden ist so überragend wichtig, daß ich kein anderes Wort als
> eben überragend wichtig dafür finde.
[..]
> W.S.

...gilt für Dich aber auch.

Wenn das Programm nur einer Forward Annotation hat, erzeugst du keine 
Inkonsistenzen wenn Du im PCB Editor den Footprint nicht ändern 
kannst.
Wie soll das gehen?

Man muß das nicht gut finden das KCad zum derzeitigen Zeitpunkt keine 
Backward Annotation unterstützt, aber man muß Dein ständiges Gelaber 
darüber auch nicht gut finden.
Du hast einen "gravierenden Fehler" gefunden der Keiner ist, sondern nur 
ein Missing Feature.
Wenn Dir das nicht paßt, renne los und implementiere das, anstatt stets 
und ständig zu behaupten wie Scheiße KiCad ist.

Da das nun nicht das erste mal ist das Du das gesagt bekommst und auch 
nicht nur von mir, bin ich der Meinung das ich einen "gravierenden 
Fehler in Deiner Software gefunden habe. Wird Zeit das dieses Memory 
Leak mal einer patcht.

>Das interessiert den Entwickler
>und Layouter hingegen garnicht, der will lediglich einen 4k7 in 0603
>dort haben.

Nein, wenn der noch alle Tassen im Schrank hat, dann will er da 4k7 
100mW oder aber 4k7 4W, genauso wie der nicht 4,7µ RM5 sondern 4,7µ 63V 
will.

Gruß,

Holm

[Veit D. (devil-elec)]

Hallo,

warum nicht auf Target 3001 wechseln? Kann Eagle importieren.
Ich nutze als privater Bastler die kleinste Kaufversion. Damit habe ich 
Support. Und ich muss sagen der Support ist wirklich super. Jede Frage 
wird umgehend beantwortet, meistens wird sofort zurückgerufen auf Mail 
Anfrage. Wenn das im kleinen passiert, dann mit Firmen sicherlich erst 
recht.

Mit Eagle kam ich nie zurecht. Mit Target kam ich ohne eine Anleitung 
zulesen sehr weit. Irgendwann muss man dann etwas nachlesen. Bauteile 
selber erstellen ist auch einfacher gewurden.

[Max G. (l0wside)]

Hat dieser Thread eigentlich noch was mit seinem Titel zu tun?

Der Mechanismus ist doch immer der Gleiche:
1. Jemand erwähnt mehr als ein EDA-System.
2. Im unmittelbaren Anschluss hagelt es dann die Kommentare im Sinne von 
"A ist Spielzeug"/"B ist unbenutzbar".
3. Die jeweiligen Fanboys werden neugierig und schreiben auch mal was. 
In der Regel nach der Schablone "Eagle ist einfach toll"/"Die 
Eigenheiten von KiCAD müssen halt so sein".
4. Die ersten werden persönlich.
5. Die Postinganzahl wird dreistellig, der weitere Wissenszuwachs 
konvergiert gegen Null.

Zum Glück gibt es hier weder Alkohol noch Maßkrüge, sonst hätten wir 
hier regelmäßige Kneipenschlägereien...

[Possetitjel (Gast)]

Michael R. schrieb:

> Possetitjel verwendet oft den begriff "Stückliste",
> versteht darunter aber was ganz spezielles, nämlich
> eine Art "Datenstruktur".

Ja.

> Für mich ist der Begriff anderweitig belegt;

Das ist ein gewisses Problem, ja.

> eine Stückliste ist ein (weiteres) Element (sagen wir
> "Dokument") welches ein Item (Artikel, bestückte Platine)
> beschreibt.

Ja -- genau das ist ja meine (provokatorische/didaktische)
Absicht dahinter, dass ich den Begriff "Stückliste" verwende:
Wäre es nicht an der Zeit, sich von der Auffassung, die
Stückliste sei ein untergeordnetes, sekundäres Dokument, das
irgendwie aus den "richtig wichtigen Daten" abgeleitet wird,
zu verabschieden? Sind nicht die Daten auf der (klassischen)
Stückliste schon ein Teil der "richtig wichtigen Daten"?

> Deswegen wehre ich mich dagegen, die Stüli wäre "zentrale
> Instanz um gewisse Daten zu speichern". Wenn man Stüli hier
> durch einen anderen (welchen?) Begriff ersetzt, bin ich
> aber einverstanden ;-)

Gern. Mach' einen Vorschlag :)

> Ob bestimmte Informationen jetzt einmalig gespeichert
> werden, oder mehrfach, aber vom System konsistent gehalten
> werden, ist für den Anwender erstmal egal [...]

Richtig.

> Insofern ist FB-Anno auch nicht unbedingt ein "technisches"
> Feature (dem Anwender ist es erstmal egal wie das implementiert
> wird), es ist mehr Funktionalität die er nutzen kann und
> möchte.

Auch richtig.

> Aus der Diskussion ist (für mich) einigermaßen klar, dass
> es ein legitimer Wunsch ist, Informationen an mehreren
> Stellen zu ändern: [...]

Ja -- und noch einen Schritt weiter: Das System muss in
der Lage sein, auch mit "unvollständigen" Informationen
zu arbeiten.

Beispiel: Eine SPICE-Simulation möchte man in Form eines
Schaltplanes erstellen können, aber die dort verwendeten
Bauteile sind i.d.R. nur "abstrakte" Bauteile, benötigen
also nur Symbole und keinen Footprint (dafür aber ggf. ein
SPICE-Modell).

Anderes Beispiel wurde schon genannt: Reverse Engineering.
Man möchte dort Layouts mit Footprints erstellen können,
denen erstmal noch kein Symbol zugeordnet ist, die also
keine vollständigen Bauteile sind.

> In weiterer Folge sollte es aber möglich sein, gewisse
> Änderungen einzuschränken: wenn ich zB Layout extern
> vergebe (oder auch nur an eine andere Abteilung) möchte
> ich dort die Änderungsmöglichkeiten einschränken können.
> Das ist dann aber mehr eine Frage des Prozess-Designs.

Ja... gut.
Ist das nicht bei genauer Betrachtung eine andere Baustelle,
nämlich eine Art "Rechteverwaltung"?

Letztlich baut das doch auf der Idee von oben (Arbeit mit
unvollständigen Information) auf: Ein bestimmter Bearbeiter
trifft bestimmte Einschränkungen, schränkt also die Menge
der Bauteilkandidaten ein, die in Frage kommen. (Es ist also
schon Auswahlinformation da, aber die ist unvollständig.)
Ein anderer Bearbeiter wählt dann aus dieser Teilmenge das
Bauteil aus, das dann letztlich genommen wird; damit wird
die Auswahl völlig eindeutig. Die Information ist vollständig.

> Ein Fehlen der Möglichkeit dieser Einschränkung wäre
> eine Design-Schwäche, die man mit prozesstechnischen
> Workarounds bewerfen müsste.
> [...]
> Diese Designschwäche mag manche gar nicht treffen, manche
> leichter, manche schwerer. Aber es ist und bleibt eine
> Designschwäche. "braucht man nicht" ist die falsche
> Antwort.

Selbstverständlich.

Es wäre halt nur schön, wenn auch die Kritik an fehlenden
Features in einigermaßen qualifizierter Gestalt daherkäme.

Wenn forward backward annotation als Feature verstanden
wird, das deswegen zwingend erforderlich ist, weil man
die Symbol-Footprint-Zuordnung in Schaltplan und Layout
konsistent halten muss, dann ist das keine qualifizierte
Kritik, sondern ein schlechter Würgaround für einen ganz
anderen Designfehler: Inkonsistenzen dürfen nicht auftreten.
Die korrekte Antwort hierauf ist tatsächlich: Braucht man
nicht.

Wenn jedoch FB als Möglichkeit im GUI verstanden wird,
eine bestimmte Zuordnung von mehreren Stellen aus verändern
zu können, dann ist daran erstmal nix falsch. Zu überlegen
wäre allenfalls, wie eine konsistente, logische Nutzer-
führung aussehen müsste. Am Wunsch an sich ist aber nix
verkehrt.

[Possetitjel (Gast)]

Lars R. schrieb:

> Aus der Diskussion sollte hervor gehen, dass es nicht
> genau exakt einen Weg für alle Entwickler und für jedes
> Projekt geben muss,

Klar. Das ist ja das Problem: Natürlich geht jeder
Software-Entwickler erstmal von seinem eigenen Arbeits-
ablauf aus, und das ist ja auch legitim.
Das hinterliegende Datenmodell sollte aber schon so
allgemein sein, dass andere Arbeitsabläufe genauso
möglich sind.


> so wie das Kicad im Moment ein Stück weit erzwingt.

Weil man nur den Weg Schaltplan --> Layout gehen kann,
nicht aber Layout --> Schaltplan, oder worauf willst Du
hinaus?


> Es ist eben nicht sinnvoll, bei der Programmentwicklung
> festzulegen, dass jede Änderung des Layouts auch automatisch
> im Schematic erfolgen muss. Das sollte einstellbar oder
> abstellbar sein.

Hmm. Ja.

Das setzt aber voraus, dass das System
1. mit unvollständigen Daten arbeite kann und
2. unvollständige von widersprüchlichen Daten unterscheiden kann.


> Eine Darstellung des Footprint als Symbol-Attribut ist in
> der Schematic-Layout-Welt schlicht falsch.

Man korrigiere mich bei Bedarf -- aber ist das nicht eine
ausdrückliche Eagle-Spezialität?
Nach meinem Empfinden besteht fast niemand (außer vielleicht
einigen wenigen Eagle-Jüngern) auf dieser Auffassung.

[Possetitjel (Gast)]

Max G. schrieb:

> 5. Die Postinganzahl wird dreistellig, der weitere
> Wissenszuwachs konvergiert gegen Null.

Das liegt wohl im Auge des Betrachters. Ich habe der
laufenden Diskussion einige Anregungen entnommen, auf
die ich im Leben nicht allein gekommen wäre.

[Karl (Gast)]

Possetitjel schrieb:
> Wäre es nicht an der Zeit, sich von der Auffassung, die
> Stückliste sei ein untergeordnetes, sekundäres Dokument, das
> irgendwie aus den "richtig wichtigen Daten" abgeleitet wird,
> zu verabschieden?

Ist es aber. Manchmal.

Dazu musst Du erstmal definieren, was auf eine Stückliste gehört.

Bauteil-ID, Wert, Package... sicher.

Wobei es mir bei einigen Packages beim Routing nicht drauf ankommt, ob 
ich da ein 0603 verwende um möglichst dicht ranzukommen, ein 0805 um 
vielleicht noch eine Leiterbahn durchzuziehen oder ein 1206, weil da 
eine dickere Leiterbahn durchmuss. Brauche ich aber Mindestleistung, 
muss es halt das 1206 sein. Und muss es ein spezieller Melf sein, dann 
muss es halt das Melf-Package sein. - Also: Kommt drauf an.

Distributor, Bestellnummer... hm.

Viele Bauteile sind Rollenware, und da ist es mir eigentlich egal, ob 
ich die 10k 0805 oder den 7805 bei TME oder bei Farnell kaufe. Meistens 
liegen die eh auf Vorrat. Andere dagegen bekomme ich nur vom einem 
Distri, oder für spezielle Projekte als Bemusterung. Allerdings so 
selten, dass sich das Einpflegen in eine Datenbank hier auch nicht 
lohnt.

Ich seh ja ein, dass Farnell das in Eagle gern hätte, um die 
Kundenbindung zu stärken. Aber mir ist das eigentlich egal.

Anzahl... wichtig, wenn man größere Mengen braucht, um ausreichend 
nachzubestellen. Aber dann reicht eine BOM und ich brauche nicht die 
Zuordnung jedes Wertes zu jeder ID.

Also bei mir reicht Stückliste von total unwichtig bei kleinen Projekten 
bis wichtig bei größeren, aber dann auch nur als BOM.

[Lars R. (lrs)]

Possetitjel schrieb:
> Lars R. schrieb:
>> so wie das Kicad im Moment ein Stück weit erzwingt.
>
> Weil man nur den Weg Schaltplan --> Layout gehen kann,
> nicht aber Layout --> Schaltplan, oder worauf willst Du
> hinaus?

Ja.

>> Es ist eben nicht sinnvoll, bei der Programmentwicklung
>> festzulegen, dass jede Änderung des Layouts auch automatisch
>> im Schematic erfolgen muss. Das sollte einstellbar oder
>> abstellbar sein.
>
> Hmm. Ja.
>
> Das setzt aber voraus, dass das System
> 1. mit unvollständigen Daten arbeite kann und
> 2. unvollständige von widersprüchlichen Daten unterscheiden kann.

Widersprüchlich? Der Abgleich zweier, zueinander inkonsistenter 
Datensätze nach vorgegebenen Kriterien muss wohl erst noch erfunden 
werden? ;) Notfalls schreibe man bei Unison ab.

[W.S. (Gast)]

Possetitjel schrieb:
> Was ist daran so kompliziert?
>
> Ich bin -- auch wenn es nicht so scheinen mag -- durchaus
> lernwillig, aber dafür gibt es eine Bedingung: Wer meine
> Gedanken durch Anwendung passender Argumente ändern möchte,
> der möge sich BITTE auf das oben von mir skizzierte Modell
> einlassen und mir zeigen, warum es nicht praxisgerecht ist.

Nein.

Ich z.B. lasse mich eben nicht auf krude Denkmodelle anderer ein, 
sondern messe selbige an der Realität. Der "real existierende 
Sozialismus" hatte sich ebenso krude Denkmodelle ausgedacht und wollte - 
wie du - daß man sich auf ihrem Denkmodell mit ihren Argumenten und 
ihren Axiomen unterhält. Daß dabei das ganze beim Messen an der Praxis 
glatt durchgefallen ist, wissen wir ja zur Genüge.

Also: Dein Begriff von Stückliste entspricht in keinem Punkte der 
Realität. Das ist wohl dein Denkfehler.

Richtig ist: Die Bauteil-Bibliothek enthält die Datensätze zu real 
existierenden Bauteilen, dazu die Symbole, mit denen diese Bauteile im 
Schematics dargestellt werden können, dazu auch die Footprints, die zum 
fachgerechten Verwenden der Bauteile auf der Leiterplatte benötigt 
werden. So man will, kann da auch noch weitere Information beigefügt 
sein, wie Lieferant, Hersteller, usw.

Die V/R-Annotation ist das automatisierte Konsistenthalten zwischen 
Schematics und Leiterplatte - und das hat üblicherweise NICHTS mit 
Bibliotheken zu tun, auch nicht mit Stücklisten.

Das ist eine Sicherheitsmaßnahme, die dazu da ist, daß Projekte, die auf 
einem System dargestellt werden, was nicht über exakt die gleichen 
Bibliotheken verfügt, unverfälscht bleibt.

Stücklisten sind nachgeordnet - begreife das mal. Sie sind ein Mittel, 
um aus einem fertigen Projekt die Angaben herauszuziehen, die für den 
Einkäufer relevant sind. Sie sind eben kein Teil des eigentlichen 
Leiterplattenentwurfes.

So, verstehst du das jetzt etwas besser?

W.S.

[W.S. (Gast)]

Possetitjel schrieb:
> Dauernd wird hier beschworen, dass Daten konsistent gehalten
> werden müssen -- aber nirgendwo wird für mich nachvollziehbar
> erklärt, warum man sie überhaupt mehrfach speiche...

Weil es die allermeisten Firmen eben NICHT gern sehen, daß sie ihr 
gesamtes Projekt an Fertiger herausgeben müßten. Es ist ja nicht nur der 
LP-Fertiger, sondern auch der Bestücker, die Beschaffer und so weiter.

All diese Leute kommen mit dem reinen Board zurecht und benötigen eben 
NICHT die Informationen, die im Schematic stecken.

Natürlich könnte man - wenn einem der Behalt am Schematic egal ist - 
Schematic und Board in einer Datei zusammenfassen. Programmiertechnisch 
wäre das sogar die netteste Lösung.

Aber das ist wie bei deiner Haustür: Theoretisch brauchst du nur ne 
Klinke, aber kein Schloß drin und es wäre technisch einfacher und auch 
billiger in der Herstellung - und im Handling.

W.S.

[Lars R. (lrs)]

W.S. schrieb:
> Possetitjel schrieb:
>> Dauernd wird hier beschworen, dass Daten konsistent gehalten
>> werden müssen -- aber nirgendwo wird für mich nachvollziehbar
>> erklärt, warum man sie überhaupt mehrfach speiche...
>
> Weil es die allermeisten Firmen eben NICHT gern sehen, daß sie ihr
> gesamtes Projekt an Fertiger herausgeben müßten. Es ist ja nicht nur der
> LP-Fertiger, sondern auch der Bestücker, die Beschaffer und so weiter.

Nein, das ist nicht der Grund. Letztlich stehen Netze und Bauteile 
(sogar der Footprint und nicht nur das Symbol) auch im PCB.


Der Grund des (bitte optionalen) automatischen Abgleiches ist, dass man 
nicht Gefahr läuft, beim manuellen Abgleich durcheinander zu kommen. 
Wobei es eben auch Situationen und Arbeitsweisen gibt, bei denen man den 
automatischen Abgleich nicht möchte.

Beispielsweise möchtest Du persönlich wahrscheinlich auch mit 
automatischem Abgleich nicht, dass ein Löschen des Footprints 
automatisch das Symbol löscht. In anderen Situationen will man mehr 
Unterschiede zwischen Schematic und Layout.

[W.S. (Gast)]

Karl schrieb:
> Was heisst hier leistungsfähige PCs? Das ging schon vor 15 Jahren auf
> einem 700 MHz Pentium 3 mit 500MByte RAM. Ich seh auch nicht, wieso das
> groß Leistung brauchen sollte?

Du Witzbold!

Denke mal an das damalige Orcad, was unter DOS in 640 K RAM lief. Damit 
hatte ich so manchen Stromlaufplan gemacht - und früher als dieses 
lief mein erstes Layoutsystem auf CP/M - jaja, Z80 und 64K RAM.

DAS ist es, was man als FRÜHER so bezeichnet.

Später war das allerdings erstmal ziemlich genau so bei PADS unter DOS.

Der große Umbruch kam erst viel später, als Windows 95 und wesentlich 
mehr RAM aufkamen.

Und dein Verständnis für frühere Zeiten endet beim Pentium3? OK, mit 
diesem Horizont sieht man ausgesprochen wenig.

W.S.

[W.S. (Gast)]

Lars R. schrieb:
> Ein Footprint hat eine Pinanzahl. Ein Symbol (Symbolgruppe) hat eine
> Pinanzahl. Für die Zuordnung Footprint<>Symbol muss die Pinzahl überein
> stimmen.

Nö.

Das stimmt hinten und vorn nicht.

ich widerlege dich mal ganz einfach mit einem simplen SN7400. Das ist ja 
so altbekannt, daß ich voraussetze, daß du dieses Bauteil kennst.

Da hast du ein NAND-Gatter als Symbol, das hat 3 Pins (Anschlüsse) - 
allerdings hast du gleich 4 davon in dem Chip. Dazu hast du noch einmal 
GND und VCC und die sind meistens in einem fünften Symbol enthalten.

Fazit: Es kann keine "Zuordnung Footprint<>Symbol" geben, weil nirgendwo 
irgendwelche Pinzahlen übereinstimmen.

W.S.

[Lars R. (lrs)]

W.S. schrieb:
> Lars R. schrieb:
> ich widerlege dich mal ganz einfach mit einem simplen SN7400. Das ist ja
> so altbekannt, daß ich voraussetze, daß du dieses Bauteil kennst.
>
> Da hast du ein NAND-Gatter als Symbol, das hat 3 Pins (Anschlüsse) -
> allerdings hast du gleich 4 davon in dem Chip. Dazu hast du noch einmal
> GND und VCC und die sind meistens in einem fünften Symbol enthalten.
>
> Fazit: Es kann keine "Zuordnung Footprint<>Symbol" geben, weil nirgendwo
> irgendwelche Pinzahlen übereinstimmen.

Von mehrteiligen Symbolen (Gruppe von Symbolen) habe ich bereits 
geschrieben. Bezog sich auch auf das Bauteil (Zuordnung 
Footprint<->Symbol)

Erklär erst mal, warum ein Designer das Layout heraus gibt, aber bei der 
Herausgabe des Schematic Angst vor Offenlegung des Knowhow haben soll. 
Du beherrschst wohl die manuelle Annotation nicht? Zwing die 
Automatische nicht anderen auf und erspare die Ablenkungsmanöver.

[W.S. (Gast)]

Possetitjel schrieb:
>> Warum machst Du (bzw warum macht Ihr) dann überhaupt noch
>> während des Designs die Zuordnung Footprint<>Symbol?
>
> Wie Eagle und KiCAD das handhaben, weiss ich nicht aus dem
> Stand.

Eagle kennt Bauteile.
Richtige Bauteile, also z.B. den Widerstand in 1206 oder in BR614 oder 
BR207.
Und in's Schematic fügt man Bauteile ein, repräsentiert durch ihre 
Symbole.

Merke also, daß die Zuordnung zwischen dem im Schematic sichtbaren 
Symbol und dem im Layout sichtbaren Footprint bereits in der 
Bauteile-Bibliothek erledigt ist.

Man kann (so man es tatsächlich will) diese Zuordnung zwar ändern, 
genauso wie man in Eagle auch ein Layout ganz ohne Schematics machen 
könnte - aber weitaus besser ist es allemal, auf derartiges zu 
verzichten.

Bedenke mal, daß man als Schaltungsentwickler schon vor dem Einschalten 
des PC wissen sollte, was man für einen Widerstand einsetzen will. Für 
den kleinen Hochzieher am µC reicht ein 0603 aus, für den Strommeß-Shunt 
würde man so einen jedoch sofort in die Luft jagen, da wäre eher ein 
fetter BR625 nötig, der die zu erwartende Verlustleistung abkann.

Also: die Bauteil-Auswahl ist ein Akt, der noch VOR dem Zeichnen des 
Schematics stattfinden muß. Man will bei einem EDA-System ja keine 
theoretischen Symbolschaltungen erzeugen, wie man sie in 
Veröffentlichungen in Zeitschriften so sehen kann, sondern es soll am 
Ende ja ein tatsächlich praktisch benutzbares Ding bei herauskommen.

W.S.

[W.S. (Gast)]

Lars R. schrieb:
> Es ist eben nicht sinnvoll, bei der Programmentwicklung festzulegen,
> dass jede Änderung des Layouts auch automatisch im Schematic erfolgen
> muss. Das sollte einstellbar oder abstellbar sein.

Oh doch, denn die einzge Alternative dazu wäre, daß es jemanden geben 
müßte, der die Übereinstimmung von Hand erledigt - oder daß beides eben 
auseinander driftet.

> Am Ende sieht man ohnehin, an welchen Stellen Schematic und Layout
> voneinander abweichen.

Ach, und wer soll das sein?

Ich sag's dir: die Service-Leute, die dann vor Ort mit unzutreffenden 
Schematics nen Fehler suchen und nach Rückkehr dir den Hintern versohlen 
werden. Oder die Software-Abteilung, die nach zehn vergeblichen 
Versuchen, das richtige Signal am richtigen Pin rauszugeben feststellen 
müssen, daß der Stromlaufplan garnicht stimmt.

W.S.

[Karl (Gast)]

W.S. schrieb:
> Und dein Verständnis für frühere Zeiten endet beim Pentium3? OK, mit
> diesem Horizont sieht man ausgesprochen wenig.

Na wenn Du meinst... mein Verständnis beginnt mit dem Amiga500 / 286er. 
Allerdings hab ich zu der Zeit meine Schaltpläne noch handgemalt. Wir 
hatten ja nichts... als Schüler und ohne Internet.

W.S. schrieb:
> Also: die Bauteil-Auswahl ist ein Akt, der noch VOR dem Zeichnen des
> Schematics stattfinden muß.

Das ist wohl etwas einseitig betrachtet. Die Dimensionierung macht man 
anhand des Schaltplanes, und wenn bei der Dimensionierung rauskommt, der 
0805er reicht leistungsmäßig nicht, es sollte doch ein 1206er sein, oder 
der Transistor im SOT89 ist grenzwertig, besser die nächstgrößere 
Bauform nehmen, dann wird das natürlich angepasst.

Genauso wie das Layout die Schaltung beeinflussen kann, beeinflusst die 
Dimensionierung Schaltplan und Layout. Den Spannungsregler im SO-08, 
oder doch lieber im DPAK?

Das ist ein Optimieren an mehreren Stellen, da schlägt die Praxis 
einfach die Theorie.

[ZF (Gast)]

W.S. schrieb:
> Eagle kennt Bauteile.
> Richtige Bauteile, also z.B. den Widerstand in 1206 oder in BR614 oder
> BR207.
> Und in's Schematic fügt man Bauteile ein, repräsentiert durch ihre
> Symbole.
>
> Merke also, daß die Zuordnung zwischen dem im Schematic sichtbaren
> Symbol und dem im Layout sichtbaren Footprint bereits in der
> Bauteile-Bibliothek erledigt ist.

Ja, in der Welt der Sektensteuerzahler ist jedem Symbol ein Footprint 
zugeordnet und man muss sich schon im Schaltplan dafür entscheiden, ob 
es da jeweils Sinn macht oder nicht.


In der freien Welt kann der Nutzer einem Symbol kein, ein, oder viele 
(eine sinnvolle Vorauswahl) Footprints zuordnen, ganz wie er mag. 
Außerdem kann er jedem Symbol Links zu Datenblatt und Spicemodell 
zuordnen, ebenso die Bestellnummern bei verschiedenen Lieferanten, 
Lagerpositionen oder was immer er möchte, wenn er denn möchte. In der 
freien Welt kann der Nutzer die Zuordnung von Footprint zum Symbol für 
jedes Bauteil bei dem es sinnvoll ist sofort im Schaltplan treffen, und 
da wo er sich noch nicht festlegen möchte auf später verschieben.

> Also: die Bauteil-Auswahl ist ein Akt, der noch VOR dem Zeichnen des
> Schematics stattfinden muß.
Sektenmitglieder lieben den Zwang.

> Man will bei einem EDA-System ja keine
> theoretischen Symbolschaltungen erzeugen, wie man sie in
> Veröffentlichungen in Zeitschriften so sehen kann
Genau, niemand fertigt Schaltpläne für Vorlesungen, Dokumentation oder 
Schaltschränke an.

[Lars R. (lrs)]

@W.S.:

Du bist selbst das, was Du andern vorwirfst zu sein.

Was Du nicht brauchst, das hat nach Deiner Ansicht auch kein anderer zu 
brauchen. Alle haben es gleich zu machen und zwar so, wie Du das willst.

> Ach, und wer soll das sein?
>
> Ich sag's dir: die Service-Leute, die dann vor Ort mit unzutreffenden
> Schematics nen Fehler suchen und nach Rückkehr dir den Hintern versohlen
> werden. Oder die Software-Abteilung, die nach zehn vergeblichen
> Versuchen, das richtige Signal am richtigen Pin rauszugeben feststellen
> müssen, daß der Stromlaufplan garnicht stimmt.

Ja und? Sieht man doch im Programm, wenn das nicht überein stimmt. Wenn 
Du das nicht verkraftest (hab ich mir schon gedacht), dann nutze eben 
den manuellen Abgleich nicht. ...ich kann Dir auch eine beliebige alte 
Version vom Stromlaufplan geben. Die stimmt dann auch nicht.

[Holm T. (Gast)]

W.S. schrieb:
> Possetitjel schrieb:
>>> Warum machst Du (bzw warum macht Ihr) dann überhaupt noch
>>> während des Designs die Zuordnung Footprint<>Symbol?
>>
>> Wie Eagle und KiCAD das handhaben, weiss ich nicht aus dem
>> Stand.
>
> Eagle kennt Bauteile.
> Richtige Bauteile, also z.B. den Widerstand in 1206 oder in BR614 oder
> BR207.
> Und in's Schematic fügt man Bauteile ein, repräsentiert durch ihre
> Symbole.
>
> Merke also, daß die Zuordnung zwischen dem im Schematic sichtbaren
> Symbol und dem im Layout sichtbaren Footprint bereits in der
> Bauteile-Bibliothek erledigt ist.
>
> Man kann (so man es tatsächlich will) diese Zuordnung zwar ändern,
> genauso wie man in Eagle auch ein Layout ganz ohne Schematics machen
> könnte - aber weitaus besser ist es allemal, auf derartiges zu
> verzichten.
>
> Bedenke mal, daß man als Schaltungsentwickler schon vor dem Einschalten
> des PC wissen sollte, was man für einen Widerstand einsetzen will. Für
> den kleinen Hochzieher am µC reicht ein 0603 aus, für den Strommeß-Shunt
> würde man so einen jedoch sofort in die Luft jagen, da wäre eher ein
> fetter BR625 nötig, der die zu erwartende Verlustleistung abkann.
>
> Also: die Bauteil-Auswahl ist ein Akt, der noch VOR dem Zeichnen des
> Schematics stattfinden muß. Man will bei einem EDA-System ja keine
> theoretischen Symbolschaltungen erzeugen, wie man sie in
> Veröffentlichungen in Zeitschriften so sehen kann, sondern es soll am
> Ende ja ein tatsächlich praktisch benutzbares Ding bei herauskommen.
>
> W.S.

Ich deute Dein Herumgeiere auf Eagle ausschließlich als Folge Deines 
Unvermögens den Knoten im eigenen Gehirn zu finden.

Nicht nur einmal habe ich für Bastelzwecke die historische Schaltung 
irgend eines veröffentlichen Projekts das ausschließlich mit trough Hole 
BE bestückt und entworfen worden war modernisiert auf SMD BE. Am 
Schaltplan hat sich dadurch so gut wie Nichts verändert und das ist auch 
gut so.
Ich lege den Footprint eines BE fest wenn ich den Schaltplan gezeichnet 
habe, evtl. simuliert und die elektrischen Anforderungen an das BE 
ermittelt und die Verfügbarkeit im Schrank (beim Hauslieferanten etc.) 
ermittelt habe..nicht etwa bevor ich den Schaltplan zeichne.
Das machen nur verkorkste Allesbesserwissenwollerabernichtkönner.

Alles Lochstreifenrolle oder was?


Gruß,

Holm

[Karl (Gast)]

Holm T. schrieb:
> Nicht nur einmal habe ich für Bastelzwecke die historische Schaltung
> irgend eines veröffentlichen Projekts das ausschließlich mit trough Hole
> BE bestückt und entworfen worden war modernisiert auf SMD BE.

Und warum sollte das mit Eagle nicht gehen? Hab ich auch schon für 
eigene Projekte gemacht, die ich vor Jahren mit THT gebaut und dann auf 
SMD aktualisiert habe.

Und das Schöne: Man kann die Footprints im Layout ändern und gleich die 
Platzierung überprüfen - und dank FB-Anno wird das für den Schaltplan 
übernommen.

[Possetitjel (Gast)]

W.S. schrieb:

> Possetitjel schrieb:
>> Ich bin -- auch wenn es nicht so scheinen mag -- durchaus
>> lernwillig, aber dafür gibt es eine Bedingung: Wer meine
>> Gedanken durch Anwendung passender Argumente ändern möchte,
>> der möge sich BITTE auf das oben von mir skizzierte Modell
>> einlassen und mir zeigen, warum es nicht praxisgerecht ist.
>
> Nein.

Nu -- dann lässt Du es halt bleiben.

Du solltest dann allerdings auch nicht erwarten, dass Deine
Argumente wesentliche Änderungen in meinen Gedanken ver-
ursachen.


> Also: Dein Begriff von Stückliste entspricht in keinem
> Punkte der Realität.

Das ist falsch.

Mein Begriff von "Stückliste" entspricht nur nicht dem
ALLGEMEIN ÜBLICHEN Begriff von "Stückliste". Das ist
etwas ganz anderes.

Meine Gedanken über Stücklisten sind Resultat meiner
praktischen Beschäftigung mit Fertigungsorganisation.
Ich war bei dieser Tätigkeit auch durchaus erfolgreich.

Die (gewollte und von mir beabsichtigte) Provokation liegt
darin, dass ich dazu einlade, den "üblichen Gebrauch" des
Begriffes "Stückliste" zu hinterfragen, zu überdenken und
ggf. zu verändern.

Wer das nicht mag, braucht dieser Einladung nicht zu folgen.
Kein Problem.


> Die V/R-Annotation ist das automatisierte Konsistenthalten
> zwischen Schematics und Leiterplatte - und das hat
> üblicherweise NICHTS mit Bibliotheken zu tun, auch nicht
> mit Stücklisten.

Genau DAS ist einer meiner Kritikpunkte.


> Stücklisten sind nachgeordnet - begreife das mal.

Nein - ich "begreife" das nicht.

Ich weiss, das einige (viele?) Leute Deiner Meinung
sind, und ich halte diese Ansicht für schädlich. Für
meine Ansicht habe ich Gründe.

Da Du oben ausdrücklich erklärt hast, Dich "auf mein
krudes Denkmodell" nicht einlassen zu wollen, sehe ich
wenig Chance für Dich, meine Gründe zu entkräften.


> So, verstehst du das jetzt etwas besser?

Nein. :)

[Lars R. (lrs)]

Ein Bauteil ist eine Beziehung Footprint<>Symbol, ggf. +Attribute

Diese Beziehung (Bauteil) kann man auch in eine Library packen. Das wäre 
in der Library eine dritte Kategorie (Bauteil, Footprint, Symbol).

Für die Instanzen, dh im Projekt, könnte man es vielleicht so 
realisieren:
1. Bauteil (Footprint, kein Symbol)
2. Bauteil (kein Footprint, Symbol)
3. Bauteil (Footprint, Symbol)

Im Layout wird mit dem Footprint gearbeitet, im Schematic mit dem 
Symbol.
Im Zuordnungsdialog und bei den Annotations mit beidem.

[Simon H. (simi)]

W.S. schrieb:
> Eagle kennt Bauteile.
> Richtige Bauteile, also z.B. den Widerstand in 1206 oder in BR614 oder
> BR207.
> Und in's Schematic fügt man Bauteile ein, repräsentiert durch ihre

Was heisst denn hier "richtige Bauteile"? Wenn ich in einen Laden gehe 
und sage: "Ich hätte gerne einen Widerstand", dann wird mich der 
Verkäufer erst mal fragen: "ja, was denn für ein Widerstand?" Wenn ich 
aber sage: "Ich hätte gerne einen Widerstand in 1206", dann... hm... 
fragt mich der Verkäufer ebenfalls: "Ja was wollen Sie denn nun für 
einen Widerstand haben?"

Ich habe das schon in anderen Threads zum Thema nicht nachvollziehen 
können. Man spricht im Bezug auf diese "Bauteile-Philosophie" von Eagle 
immer davon, dass es "physikalische Bauteile" sind, und nicht bloss 
Abstraktionen. Doch, das sind sie immernoch! Es sind bloss 
Abstraktionen, die ein bisschen stärker konkretisiert sind. Aber es ist 
immernoch IRGENDEIN Widerstand in einem konkreten Gehäuse.

Der Aussage, dass grundsätzlich der Footprint immer VOR dem 
Schemazeichnen klar sein soll, widerspreche ich vehement. Natürlich 
weiss ich, dass ein 100A Messshunt nicht in einem 0402 Gehäuse 
daherkommt. Aber in welchem denn? Wenn ich das Schema zeichne 
interessiert mich das erstmal kein bisschen. Oder nehmen wir 
Kondensatoren. 47uF, 10V. Gibt es die im 0402? Oder in 0603? Oder muss 
ich gar auf 0805 gehen? Das alles sind Überlegungen, die mich beim 
Schemazeichnen kein bisschen interessieren. Beim Schemazeichnen 
platziere ich oft konkrete Bauteile, von denen ich eine genaue Ahnung 
habe, was GENAU ich haben möchte. Bei den meisten Bauteilen platziere 
ich aber wirklich NUR ein Symbol für etwas, das ich in einer späteren 
Phase des Designs noch genauer spezifizieren werde.

[Lars R. (lrs)]

Possetitjel schrieb:

>> Die V/R-Annotation ist das automatisierte Konsistenthalten
>> zwischen Schematics und Leiterplatte - und das hat
>> üblicherweise NICHTS mit Bibliotheken zu tun, auch nicht
>> mit Stücklisten.
>
> Genau DAS ist einer meiner Kritikpunkte.

Das stimmt halt nicht. Wenn das zu absolut jeder Zeit zu 100% konsistent 
wäre, dann bräuchte man es nicht mehrfach speichern.

[Mark S. (voltwide)]

Ja, die Synchronisation von Schaltplan und Layout ist bei KiCAD 
umständlich, um nicht zu sagen altbacken. So haben wir das schom um 1990 
herum mit OrCAD als Schaltplaneditor und Tango-Netzlisten Export 
gehandhabt.
Ist aber nun kein ko-Kriterium für KiCAD. Nach rund 25 Jahren Eagle bin 
ich umgestiegen auf KiCAD, und in der Tat gibt es da aus meiner Sicht 
eine Menge zu kritisieren.
Das quelloffene System, wo die Projektdateien im KLARTEXT abgespeichert 
werden, die große community und die deutlich besser gepflegten 
Bibliotheken sind für mich aber gewichtigere Argumente, so daß ich Eagle 
inzwischen keine Träne mehr nachweine.
Ist eben Ansichtssache...

[Sheeva P. (sheevaplug)]

W.S. schrieb:
> In die Stückliste kommt später dann nur noch, ob
> der Widerstand von Beyschlag oder Isabellenhütte oder anonym per Distri
> und dessen Katalognummer bezogen wird. Das interessiert den Entwickler
> und Layouter hingegen garnicht, der will lediglich einen 4k7 in 0603
> dort haben.

Warum sollte den Entwickler interessieren, ob der 4k7 in 0603 oder in 
0805 verbaut wird?

[Possetitjel (Gast)]

W.S. schrieb:

> Possetitjel schrieb:
>>> Warum machst Du (bzw warum macht Ihr) dann überhaupt noch
>>> während des Designs die Zuordnung Footprint<>Symbol?
>>
>> Wie Eagle und KiCAD das handhaben, weiss ich nicht aus
>> dem Stand.
>
> Eagle kennt Bauteile.

Ja, das ist klar.

Der Knackpunkt war: Kennt Eagle nur (komplette) Bauteile?
Ich bin kein Eagle-User, aber so, wie ich die zahlreichen
Diskussionen verstehe, lautet die Antwort: JA!

Man kann zwar den Footprint nachträglich ändern, aber man
kann kein Symbol ganz ohne Footprint in den Schaltplan
einfügen. Entspricht das so den Tatsachen?


> Und in's Schematic fügt man Bauteile ein, repräsentiert
> durch ihre Symbole.

Ja. Genau das ist mein Kritikpunkt. :)

Das komplette Bauteil gehört in die interne "Super-
stückliste".
In den Schaltplan gehört eine Referenz auf die entsprechende
Position der "Super-Stückliste"; der Schaltplaneditor zeigt
das zugehörige Symbol an.
In das Layout gehört eine Referenz auf die entsprechende
Position der "Super-Stückliste"; der Layouteditor zeigt den
zugehörigen Footprint an.

Eigentlich ganz einfach und logisch...

> Bedenke mal, daß man als Schaltungsentwickler schon vor
> dem Einschalten des PC wissen sollte, was man für einen
> Widerstand einsetzen will.

Genau das stimmt nicht.
Das schränkt (ähnlich wie es Lukas bei horizon mMn getan
hat) das Anwendungsfeld unmotiviert ein.

> Man will bei einem EDA-System ja keine theoretischen
> Symbolschaltungen erzeugen, wie man sie in
> Veröffentlichungen in Zeitschriften so sehen kann,

Doch! Manchmal will man GENAU DAS !

Zum Beispiel dann, wenn man eine Schaltungsidee hat und
davon eine SPICE-Simulation machen will. Oder wenn man
eine Prinzipskizze für das Mikrocontroller-Forum erstellen
will. Oder wenn man wiederverwendbare Grundschaltungen
definieren will...

[Lars R. (lrs)]

Possetitjel schrieb:
> Das komplette Bauteil gehört in die interne "Super-
> stückliste".
> In den Schaltplan gehört eine Referenz auf die entsprechende
> Position der "Super-Stückliste"; der Schaltplaneditor zeigt
> das zugehörige Symbol an.
> In das Layout gehört eine Referenz auf die entsprechende
> Position der "Super-Stückliste"; der Layouteditor zeigt den
> zugehörigen Footprint an.
>
> Eigentlich ganz einfach und logisch...

Und was passiert dann Deiner Ansicht nach, wenn Du die Verlustleistung 
vom Symbol änderst?

Geht dann die Datenstruktur "Bauteil" kaputt?
Bekommt der 0402-Footprint plötzlich 5W Verlustleistung?
Willst Du es einfach verbieten, dass beim Symbol die Verlustleistung 
geändert wird?
usw.

[Simon H. (simi)]

Ich komme nochmals auf mein Beispiel mit den Kondensatoren zurück, weil 
ich finde, dass da noch ein Aspekt drin steckt, der mir erst jetzt 
wirklich eingefallen ist:

Ich denke, es geht nicht nur mir so, dass ich während dem Schemazeichnen 
keine Lust habe, immer wieder auf mouser.com zu wechseln um zu schauen, 
in welcher Bauform denn ein bestimmter Kondensator erhältlich ist. Also 
werde ich, egal, ob ich mit KiCad oder mit Eagle arbeite, erst mal in 
meinen Gedanken IRGENDEINEN Kondensator platzieren.
Wenn ich das richtig verstanden habe, muss ich in Eagle also irgendeinen 
Kondi in irgendeinem Gehäuse platzieren. Ich muss mich entscheiden. Bei 
KiCad muss ich das nicht. Ich darf. Aber ich muss nicht.
Beim Standard-Hühnerfutter (100nF Kondis etc.) weiss ich, dass ich auf 
0402 gehe. Da muss ich sicher nicht nachschauen. Nich jetzt, nicht 
später.

Nun, Tage später, ist also mein Schema fertig. Und ich bin schon ganz 
wuschig auf's Layouten. Also ran ans Werk! Bei KiCad kommt die 
Enttäuschung sogleich: So schön es wäre, jetzt sofort ein paar Tracks zu 
legen; ich muss mich erst mal mit den Footprints befassen! Viele habe 
ich ja schon zugeordnet. Nur bei einigen Knacknüssen hat es noch keinen. 
Ok, jetzt kommt halt das mühselige Durchsuchen der Mouser-Homepage. 
Wenigstens kann ich gleich alles auf einmal machen.
Und bei Eagle? Da lege ich sofort los! Schliesslich sind ja alle 
Footprints definiert! Müssen ja! Aber Moment mal... war ich nicht bei 
einem Kondensator unsicher, ob der in diesem Gehäuse wirklich erhältlich 
ist? Welcher war das noch gleich? ...

Das hat jetzt nicht direkt mit F/B Annotation zu tun, sondern mit dem 
von vielen als einzig vernünftiges Datenmodell verkaufte Prinzip der 
"Bauteile" in Eagle.

[Sheeva P. (sheevaplug)]

W.S. schrieb:
> Eagle kennt Bauteile.
> Richtige Bauteile, also z.B. den Widerstand in 1206 oder in BR614 oder
> BR207.
> Und in's Schematic fügt man Bauteile ein, repräsentiert durch ihre
> Symbole.

Und das muß so sein? Warum denn?

> Merke also, daß die Zuordnung zwischen dem im Schematic sichtbaren
> Symbol und dem im Layout sichtbaren Footprint bereits in der
> Bauteile-Bibliothek erledigt ist.

Das ist eine Frage, wie man die Bibliothek designt. Ich halte das, was 
Eagle da zu machen scheint, allerdings für einen groben Fehler. Wenn der 
Layouter nämlich keinen Bauraum für einen 1206 hat, sondern nur für 
einen 0402, dann muß genau das passieren, dessen Fehlen Du bei KiCad 
bemäkelst: eine Backward-Annotation: der geänderte Footprint muß also 
zurück in den Schaltplan übernommen werden. Und genau das wird Dir 
früher oder später gewaltig auf die Füße fallen.

> Bedenke mal, daß man als Schaltungsentwickler schon vor dem Einschalten
> des PC wissen sollte, was man für einen Widerstand einsetzen will. Für
> den kleinen Hochzieher am µC reicht ein 0603 aus, für den Strommeß-Shunt
> würde man so einen jedoch sofort in die Luft jagen, da wäre eher ein
> fetter BR625 nötig, der die zu erwartende Verlustleistung abkann.

Das ist aber keine Frage des Footprint, sondern eine Frage von Nennwert, 
Belastbarkeit, Güte und Toleranz. Diese Werte kann, darf, soll und muß 
unser Entwickler natürlich vorgeben. Danach muß dann der Layouter einen 
Footprint auswählen, der diese Vorgaben erfüllt.

> Also: die Bauteil-Auswahl ist ein Akt, der noch VOR dem Zeichnen des
> Schematics stattfinden muß.

Die Auswahl der Bauteile, ja. Aber eben nicht die der Footprints.

[Possetitjel (Gast)]

ZF schrieb:

> Ja, in der Welt der Sektensteuerzahler ist jedem
> Symbol ein Footprint zugeordnet und man muss sich
> schon im Schaltplan dafür entscheiden, ob es da
> jeweils Sinn macht oder nicht.

:-)

Eine dämliche Folge dessen ist, dass man nicht einfach
per Knopfdruck einen Schaltplan von "amerikanischen"
auf "DIN"-Symbole umstellen kann, denn die Software
weiss ja nicht, die Symbole zwar unterschiedlich
aussehen, aber elektrisch gleichwertig sind.


>> Man will bei einem EDA-System ja keine theoretischen
>> Symbolschaltungen erzeugen, wie man sie in
>> Veröffentlichungen in Zeitschriften so sehen kann
>
> Genau, niemand fertigt Schaltpläne für Vorlesungen,
> Dokumentation oder Schaltschränke an.

Sehr schön. :)

[Possetitjel (Gast)]

Simon H. schrieb:

> Ich habe das schon in anderen Threads zum Thema nicht
> nachvollziehen können. Man spricht im Bezug auf diese
> "Bauteile-Philosophie" von Eagle immer davon, dass es
> "physikalische Bauteile" sind, und nicht bloss
> Abstraktionen. Doch, das sind sie immernoch! Es sind
> bloss Abstraktionen, die ein bisschen stärker
> konkretisiert sind. Aber es ist immernoch IRGENDEIN
> Widerstand in einem konkreten Gehäuse.

Sehr schön. Super! Es besteht noch Hoffnung...

Es ist genau, wie Du schreibst: Es gibt durchaus nicht
nur "abstrakte" und "physikalische" Bauteile, sondern
es gibt EINE GANZE REIHE unterschiedlicher Abstraktions-
ebenen, auf denen die Auswahl der "zulässigen Kandidaten"
mehr oder weniger stark eingeschränkt wird.


> Beim Schemazeichnen platziere ich oft konkrete Bauteile,
> von denen ich eine genaue Ahnung habe, was GENAU ich
> haben möchte. Bei den meisten Bauteilen platziere ich
> aber wirklich NUR ein Symbol für etwas, das ich in einer
> späteren Phase des Designs noch genauer spezifizieren
> werde.

Genau; das ist der nächste Punkt: Es STIMMT EINFACH NICHT,
dass man in einem bestimmten Arbeitsschritt IMMER schon
bestimmte Informationen hat, und andere noch nicht. DAS
IST NICHT WAHR!
Es tritt immer wieder auf, dass das Wissen in einer bestimmten
Bearbeitungsstufe noch unvollständig ist, und man trotzdem
weiterarbeiten will. Die Software muss das ermöglichen!

[Simon H. (simi)]

Ein weiterer Grund, warum ich überhaupt nicht der Meinung bin, dass 
jeder Schemasymbol a priori einem Footprint zugeordnet sein muss:

Ich möchte irgendein exotisches Bauteil einsetzen. Vor mir liegt das 
Datenblatt mit Footprint-Vorschlag. Ich sehe, dass dieser Footprint für 
mich ok ist. Und das reicht mir erst mal. Im Moment bin ich am Designen 
der Schaltung. Das Schemasymbol muss ich zeichnen, da komme ich jetzt 
nicht drum herum. Ist aber auch kein Hexenwerk. Ganz sicher möchte ich 
mich jetzt aber nicht mit dem Zeichnen des Footprints befassen. Das 
macht entweder mein Layouter, oder ich, wenn ich später mal die 
Laouter-Mütze aufhabe. Jetzt bin ich am Entwickeln. Und das möchte ich 
nicht unterbrechen.

Also nochmals: JA, ein Schema beinhaltet Symbole, die a priori ABSTRAKT 
sind. Ich weiss mehr oder weniger genau, was für ein Footprint ein 
Symbol repräsentiert (neben anderem), aber dieser ist oft erst mal noch 
gar nicht definiert resp. in der Bibliothek angelegt! Das ist nicht, wie 
vielfach gesagt wurde, Schlamperei, sondern schicht effizientes 
Arbeiten.

[Sheeva P. (sheevaplug)]

Karl schrieb:
> Holm T. schrieb:
>> Nicht nur einmal habe ich für Bastelzwecke die historische Schaltung
>> irgend eines veröffentlichen Projekts das ausschließlich mit trough Hole
>> BE bestückt und entworfen worden war modernisiert auf SMD BE.
>
> Und warum sollte das mit Eagle nicht gehen? Hab ich auch schon für
> eigene Projekte gemacht, die ich vor Jahren mit THT gebaut und dann auf
> SMD aktualisiert habe.
>
> Und das Schöne: Man kann die Footprints im Layout ändern und gleich die
> Platzierung überprüfen - und dank FB-Anno wird das für den Schaltplan
> übernommen.

Tja, nachdem Du jetzt Das Schöne vorbringst, muß ich leider auf Das 
Dumme hinweisen: redundante Datenhaltung ist aus Informatikersicht ein 
Disaster waiting to happen. Auch dann, wenn Du Automatismen für den 
Abgleich der redundanten Daten implementierst.

Aus diesem Grund wird bei relationalen Datenbanken ein hoher Aufwand 
betrieben, um die Daten zu normalisieren, also: Redundanzen und damit 
die Möglichkeit von Inkonsistenzen zu vermeiden. Trotzdem betreiben 
derartige Systeme einen nochmals enorm hohen internen Aufwand, um die 
referentielle Integrität der Daten sicherzustellen. Denn es ist nicht 
einmal innerhalb eines einzelnen Softwareprozesses möglich, die 
Integrität und Konsistenz redundanter Daten auch dann zu garantieren, 
wenn er etwa abstürzt.

Ich persönlich halte es bis zum Beweis des Gegenteils für einen Fehler 
im Design von Eagle, Footprints in den Schaltplan zu schreiben. Ein 
Footprint gehört aus logischer Sicht IMHO nicht zum Schaltplan, sondern 
zum Layout, und zwar NUR zum Layout.

[Simon H. (simi)]

Possetitjel schrieb:
> Es tritt immer wieder auf, dass das Wissen in einer bestimmten
> Bearbeitungsstufe noch unvollständig ist, und man trotzdem
> weiterarbeiten will. Die Software muss das ermöglichen!

Eben! Und KiCad macht das, indem es sagt: "Falls Du schon weisst, 
welchen Footprint das sein soll, sag's mir. Ansonsten lasse ich dieses 
Feld erst mal noch offen.

Possetitjel schrieb:
> Es ist genau, wie Du schreibst: Es gibt durchaus nicht
> nur "abstrakte" und "physikalische" Bauteile, sondern
> es gibt EINE GANZE REIHE unterschiedlicher Abstraktions-
> ebenen, auf denen die Auswahl der "zulässigen Kandidaten"
> mehr oder weniger stark eingeschränkt wird.

Genau so bei KiCad. Du kannst in der Bibliothek ein Bautel anlegen für 
einen 100 Ohm Widerstand im 0605 Gehäuse mit 1% Genauigkeit und der 
Farbe Rot.
Und ein weiteres Bauteil mit exakt denselben Werten, jedoch der Farbe 
Grün.

Wie geht denn das bei Eagle? Wenn ich den Footprint nicht weiss, kann 
ich dann das Symbol dennoch platzieren? Ist das dann halt ein 
"generischer Widerstand" ohne Footprint? Und wie gebe ich dem dann einen 
Footprint? Indem ich den Widerstand im Schema durch einen "konkreten" 
Widerstand ersetze?

Nachtrag: Ich habe gerade ein Deja-vu. Zu Folgender Erkenntnis bin ich 
mal in einem anderen Thread gekommen:


> 1. KiCad lässt eine a-priori Festlegung auf einen Footprint zu.
> 2. KiCad zwingt niemanden dazu.
> 3. Eagle lässt eine a-priori Festlegung auf einen Footprint zu.
> 4. Eagle zwingt niemanden dazu.

> Aus 1 und 2 folgt, dass KiCad ein Basteltool ist.
> Aus 3 und 4 folgt, dass Eagle ein Profitool ist.

(fairerweise muss man sagen, dass man die letzten Zeilen auch umgekehrt 
formulieren kann - je nach Sichtweise ;-) Ausserdem ist dieser Thread 
hier weit weniger polemisch. :-)

[Possetitjel (Gast)]

Lars R. schrieb:

> Possetitjel schrieb:
>> Das komplette Bauteil gehört in die interne "Super-
>> stückliste".
>> In den Schaltplan gehört eine Referenz auf die entsprechende
>> Position der "Super-Stückliste"; der Schaltplaneditor zeigt
>> das zugehörige Symbol an.
>> In das Layout gehört eine Referenz auf die entsprechende
>> Position der "Super-Stückliste"; der Layouteditor zeigt den
>> zugehörigen Footprint an.
>>
>> Eigentlich ganz einfach und logisch...
>
> Und was passiert dann Deiner Ansicht nach, wenn Du die
> Verlustleistung vom Symbol änderst?

Erstmal die "naive" Variante:

Nach meiner Ansicht hat das Symbol keine Verlustleistung,
sondern nur das Bauteil (also eine bestimmte "Zeile" in
der internen "Super-Stückliste").
Wenn Du die Verlustleistung ändern willst, musst Du das
entsprechende (Exemplar des) Bauteil(s) in der internen
"Super-Stückliste" durch ein anderes ersetzen, das die
gewünschte Verlustleistung verträgt.

(Das könnte durchaus das GUI des Schaltplaneditors mit
erledigen -- die Variable, die die Daten tatsächlich
enthält, befindet sich aber in der Super-Stückliste.)

> Geht dann die Datenstruktur "Bauteil" kaputt?

Jein :)

Wenn Du verbindlich Footprint 0402 und Verlustleistung
5W forderst, dann stehen zwar diese Werte in der
"Super-Stückliste", aber sie entsprechen keinem Bauteil
in der Bauteil-Datenbank mehr -- einfach weil es diese
Kombination nicht gibt.


> Bekommt der 0402-Footprint plötzlich 5W Verlustleistung?

Nein.
Wenn Du im entsprechenden Dialog nach der Verlustleistung
selektierst, wird 0402 nicht in der Treffermenge angezeigt,
weil es keine 5W verträgt.
Wenn Du 0402 auswählst, wird als Verlustleistung 60mW (oder
was immer da herauskommt) eingetragen.

> Willst Du es einfach verbieten, dass beim Symbol die
> Verlustleistung geändert wird?

Jein: Ein Schaltplansymbol hat einfach keine Verlust-
leistung. (Die hat es ja WIRKLICH nicht.)


Jetzt die "nicht ganz so naive" Variante:

Ich sehe durchaus das Problem, das Du ansprichst; ich
hatte es bis jetzt nicht auf dem Schirm, einfach weil
ich von dessen Existenz bisher nichts wusste :)

Als Lösungsvorschlag werfe ich mal folgendes in den Raum:
Man schafft im GUI des Schaltplaneditors die Möglichkeit,
den einzelnen Bauteilen bestimmte Restriktionen zuordnen
zu können. Die konkreten Vertreter, die in der "Super-
Stückliste" aufgeführt sind, erfüllen entweder diese
Restriktionen, dann ist alles gut, oder sie erfüllen sie
nicht, dann wird das angezeigt. Die Weiterbearbeitung
wird nicht verhindert, aber trotzdem ist das automatisiert
prüfbar.

Der Trick dabei ist, dass die Verlustleistung des Bauteil
eine Verlustleistung, also ein Kennwert (=eine Zahl) ist,
während die Restriktion "Pv >= 5W" eben KEINE Leistung,
sondern eine Restriktion (in Form einer Ungleichung) ist, die
erfüllt oder nicht erfüllt sein kann.

> usw.

Neinein, das ist super. Sachliche Kritik ist willkommen.

[Zeno (Gast)]

ZF schrieb:
> In der freien Welt kann der Nutzer einem Symbol kein, ein, oder viele
> (eine sinnvolle Vorauswahl) Footprints zuordnen, ganz wie er mag.

Das ist doch Käse. Ein reales Bauelement hat einen 
(mehrere)Footprint(s). Bei der Schaltungsentwicklung lege ich bereits 
die Anforderungen an die BE fest und ich entscheide schon beim Entwurf 
ob ich Durchsteckmontage oder SMD möchte.
Falls ich mich dann später umentscheiden möchte ist das kein Problem. Es 
ist auch kein Problem, wenn ich beim Layouten merke, das eine andere 
Bauform, Größe etc. besser geeignet ist als ursprünglich im Schematic 
vorgeshen war, das erledige ich das bei Eagle mit 3 Klicks im 
Layouteditor ("Element ersetzen" wählen >> neues BE auswählen >> das zu 
ändernde BE im Layouteditor anklicken). Am Schematic ändert das 
zumindest optisch erst mal nichts. Wenn ich mir dann allerdings 
Informationen zum Device im Schematic anzeigen lasse, dann sehe ich sehr 
wohl, das BE jetzt einen neuen Footprint hat.
Umgekehrt, also bei Änderungen im Schematic, dann wirkt sich das 
natürlich auch im Layout aus, sofern das neue BE einen anderen Footprint 
hat.

Ich habe also auch bei dem Konzept von Eagle alle Freiheiten. Ich kann 
auch in Eagle generische Symbole, also solche ohne Footprint benutzen. 
Und ja solche Symbole werden natürlich nicht im Layout angezeigt - wie 
soll das auch funktionieren, wenn sie keinen Footprint haben


Noch was zu FB: Das ist natürlich essentiell. Wie anders will ich sonst 
sicherstellen, das Bord und Schematic konsistent sind? Bei wenigen BE 
kann ich das zur Not noch selbst manuell erledigen, wenn's dann aber 
viele BE sind wird's schon schwierig und die Wahrscheinlichkeit das man 
etwas übersieht wird sich 100% nähern. Es hat schon einen Grund warum 
z.B. Profiprogramme wie z.B. Pulsonix auf dieses Feature nicht 
verzichten.

Letztendlich bleibt es jedem selbst überlassen welches Programm er 
benutzt. Dennoch sollte man in der Lage sein Fehler im Programm bzw. 
konzeptionelle Schwächen zu benennen und nicht schön zu reden. Es gibt 
keine fehlerfreien Programme. Eine steile Lernkurve ist eben kein 
Feature sondern ein konzeptioneller Fehler. Selbst ein Profiprogramm wie 
Pulsonic leistet sich solch eine Schwäche bei den grundlegenden 
Funktionen nicht. Man ist bei diesem Programm durchaus in der Lage ohne 
Studium eines Tutorial ein einfaches Schematic + Board zu erstellen.

[Sheeva P. (sheevaplug)]

Lars R. schrieb:
> Ein Bauteil ist eine Beziehung Footprint<>Symbol, ggf. +Attribute
>
> Diese Beziehung (Bauteil) kann man auch in eine Library packen. Das wäre
> in der Library eine dritte Kategorie (Bauteil, Footprint, Symbol).
>
> Für die Instanzen, dh im Projekt, könnte man es vielleicht so
> realisieren:
> 1. Bauteil (Footprint, kein Symbol)
> 2. Bauteil (kein Footprint, Symbol)
> 3. Bauteil (Footprint, Symbol)
>
> Im Layout wird mit dem Footprint gearbeitet, im Schematic mit dem
> Symbol.
> Im Zuordnungsdialog und bei den Annotations mit beidem.

So ganz grundsätzlich würde ich die Datenstruktur einer Library im 
ersten Schritt etwa so designen, wie in den Anhängen beschrieben. Ist 
aber bisher nur ein erster Gedanke, mehr nicht. Unbedingt sollte man 
dort sogar noch Datasheets, Distributoren/Lieferanten und / oder 
Simulationsmodelle oder weitere Dinge einbauen.

Das Ganze ließe sich, mal ins Blaue gedacht, im Backend wunderbar mit 
einer Volltext-Suchmaschine wie Apache Solr oder Elasticsearch abbilden. 
Dadurch gewänne man die Möglichkeit, den Daten im Volltext durchsuchen 
zu können -- und wenn die Datenblätter eingebunden wären, sogar in 
denen. Obendrein wäre solch eine Lösung zweifellos gut skalierbar, 
Elasticsearch und Apache Solr unterstützen verteilte Cluster-Modus mit 
Replikation und Sharding.

HINWEIS: ja, ich habe viele naheliegende Datenfelder für die einzelnen 
"Datenstrukturen" bewußt ausgelassen. Danke für den Hinweis. :-)

[Zeno (Gast)]

Possetitjel schrieb:
> Man kann zwar den Footprint nachträglich ändern, aber man
> kann kein Symbol ganz ohne Footprint in den Schaltplan
> einfügen. Entspricht das so den Tatsachen?

Man kann.

[Thomas F. (tf1973)]

Das Problem mit dem Footprint liegt eigentlich schon im Workflow bei 
einer Produktentwicklung. Bei mir ist es so, das nach dem Schematic 
Entwurf der Einkauf sofort die BOM haben möchte um zu sehen ob das 
überhaupt finanziell im Rahmen liegt. Also weit bevor irgend eine 
einzige Leiterbahn geroutet ist.
Ich brauche da also schon das komplette Bauteil mit Footprint und 
Bestellnummer. Zusätzlich gibt es eine firmeninterne Bauteilbibliothek 
mit getesteten Bauteilen auf die im optimalen Fall zu 100% 
zurückgegriffen werden muss. Neue Bauteile muss man dann als Entwickler 
teilweise mit Händen und Füßen verteidigen:-)
Wenn ich beim Routen feststelle das geht auf keinen Fall, werden 
einzelne Bauteile in der BOM geändert. Aber im großen Stil mal eben 50% 
aller Bauteile zu ändern ist ein No-go.

[Michael R. (Firma: Brainit GmbH) (fisa)]

Thomas F. schrieb:
> Das Problem mit dem Footprint liegt eigentlich schon im Workflow bei
> einer Produktentwicklung. Bei mir ist es so, das nach dem Schematic
> Entwurf der Einkauf sofort die BOM haben möchte um zu sehen ob das
> überhaupt finanziell im Rahmen liegt. Also weit bevor irgend eine
> einzige Leiterbahn geroutet ist.

Sehr guter Einwurf!

[ZF (Gast)]

Zeno schrieb:
> Das ist doch Käse. Ein reales Bauelement hat einen
> (mehrere)Footprint(s). Bei der Schaltungsentwicklung lege ich bereits
> die Anforderungen an die BE fest und ich entscheide schon beim Entwurf
> ob ich Durchsteckmontage oder SMD möchte.
Für dich mag das gelten, andere möchten sich nicht immer schon beim 
Zeichnen des Schaltplans auf jeden Footprint und damit auch auf das 
Lötverfahren (z.B. Welle oder Reflow) festlegen müssen. Sie finden es 
schön sich festlegen zu können, wo Bauteil und Lötverfahren feststehen, 
und die Festlegung auf später verschieben zu können, wenn Bauteil und 
Lötverfahren noch nicht feststehen.

> Letztendlich bleibt es jedem selbst überlassen welches Programm er
> benutzt.
Genau, ist doch schön, dass es für Jeden was passendes gibt.

[Lars R. (lrs)]

Possetitjel schrieb:
> [...]

Wird sind uns einig, dass man ein Symbol ohne Footprint im Schematic 
haben kann?

Wir sind uns einig, dass man ein Symbol mit Footprint im Schematic haben 
kann? Mit dem Footprint ist bereits ein Layout gebaut.

Wir sind uns einig, dass man ein Symbol ohne Footprint im Schematic 
haben kann und der Entwickler sagt: An diesem Widerstand (egal welcher 
Footprint das auch sein möge) benötige ich 5Watt Verlustleistung?

Folgendes Szenario:
Symbol im Schematic. Footprint im Layout, dh es existiert bereits ein 
Layout mit dem Footprint 0402 (in welchem Stadium sich das Layout 
befindet, das sei dahin gestellt).
Nun möchte der Entwickler im Schematic die Vorgabe 5W Verlust an diesem 
Widerstand eintragen.

Nochmal meine Fragen:
. Geht dann die Datenstruktur "Bauteil" kaputt?
. Bekommt der 0402-Footprint plötzlich 5W Verlustleistung?
. Willst Du es einfach verbieten, dass beim Symbol die Verlustleistung
geändert wird? Genauer entsprechend Deinem Ansatz: Sobald ein Footprint 
gewählt wurde, darf im Schematic die Verlustleistung nicht mehr beliebig 
geändert werden. Zuerst muss vorher der Footprint aus dem Layout 
gelöscht werden.


> Der Trick dabei ist, dass die Verlustleistung des Bauteil
> eine Verlustleistung, also ein Kennwert (=eine Zahl) ist,
> während die Restriktion "Pv >= 5W" eben KEINE Leistung,
> sondern eine Restriktion (in Form einer Ungleichung) ist, die
> erfüllt oder nicht erfüllt sein kann.

So ähnlich wird das gemacht. Man kann beliebige Attribute anlegen.
Warum schaust Du Dir nicht mal an einer Uni/FH bei Elektrotechnik die 
großen Suiten (Mentor, Cadence) an, bevor Du unbedingt mit dem Kopf 
durch die Wand gehst?

[ZF (Gast)]

Kleiner Nachtrag:
Man kann sich in Kicad eine Symbol-lib erstellen, in der jedem Symbol 
exakt ein Bauteil mit exakt einem Footprint für exakt ein Lötverfahren 
zugewiesen ist. Aber, auch wenn eine spätere Änderung möglich ist, warum 
sollte man sich selbst so gängeln? Doch wer Gängelung mag, der kann auch 
mit Kicad glücklich werden.

[Lars R. (lrs)]

oder/und Du schaust Dir Designspark PCB an.

[Lars R. (lrs)]

Was ist das nur immer und immer noch mit dem Eagle? Soll das wirklich 
für immer der Maßstab sein? Dann wird's Zeit für Kicad-Subscription.

[Lars R. (lrs)]

Sheeva P. schrieb:
> [aufteilung.png]

Der Footprint in der Footprint-Library kann eine Verlustleistung haben
Jeder Footprint im Layout kann eine andere Verlustleistung haben, obwohl 
es in der Library alles der selbe Footprint ist.


Das Symbol in der Symbol-Library kann eine Verlustleistung haben
Jedes Symbol im Schematic kann eine andere Verlustleistung haben, obwohl 
es in der Library alles das selbe Symbol ist.

Ergo:
Class Footprint   (Library)
Instanz Footprint (Projekt)

weitere Funktion: Überschreibe Eigenschaften der Klasse mit den 
aktuellen Eigenschaften der Instanz

selbiges für Symbol.


Annotations: Synchronisation der Datensätze Schematic und Layout.

[Holm T. (Gast)]

Leute der wievielte Therad ist das eigentlich in dem wir uns mit W.S. 
kruden Ansichten über die KiCad vs. Eagle Verfahrensweise 
auseinandersetzen?
Das ist doch mindestens der 5. oder 6...
Meint Ihr das hat Sinn? Ich denke nicht das W.S. das mal einsehen wird, 
so lange KiCad nicht gleich Eagle ist wird es für ihn nicht taugen, aber 
ist das wirklich das Problem einer ganzen Community?

Gruß,

Holm

[As-I-Roved-Out (Gast)]

Ich mag KiCAD :)
Hab es um Weihnachten rum in 2 Tagen so weit gebracht meine, zu dem 
Zeitpunkt, in Entwicklungsstadium befindlichen Schaltpläne damit zu 
zeichnen.
Der Workflow ist tatsächlich etwas gewöhnungsbedürftig.

Gut fand ich:
- Gratis
- Umfangreich
- Habe mit den OnlineTutorials alle Standardthemen verstanden

Kritik von mir:
- Auswählen von Bauteilen und Scrollen ist teilweise doch etwas 
unangenehm
  (Bauteil packen, an den Fensterrand schieben um weiterzuscrollen,
   plötzlich 30cm weiter)
- Autorouter muss man von Hand reinstricken

Gescheitert bin ich mit:
dem Export der Echtzeit 3D Darstellung und dem folgenden Import in 
FreeCAD

[Helmut S. (helmuts)]

Vielleicht sollte man mal schauen wie die großen Firmen das mit ihren 
Bauteilen machen.
Beispiel: http://www.sphere.bc.ca/download/hp_xref-free.pdf
Dort hat jedes Bauteil eine Nummer. Die Nummern sind dabei nach 
Kategorien geordnet. Hinter jeder Nummer steckt eine Liste der dafür 
gültigen Teile, footprints und weiterer Informationen. Meines Wissens 
nach machen das viele große Firmen so. Das ist zwar für den Bastler 
etwas abstrakt aber im Profibereich finde ich das eine gute Sache.

[Gu. F. (mitleser)]

Ich war lange Zeit Eage user, weil nix anderes brauchbares für kleines 
Geld gab. Ich habe diese Diskussion nun genutzt mich endlich mal näher 
mit KiCAD
auseinander zu setzen. Ich hab also inzwischen mehrere Tage mit der sw 
gespielt und ein (wenn auch klitzekleines) Projekt erstellt.
Mein erster Eindruck ist erst mal nicht schlecht.
Ob ein footprint nun im Schaltbild oder während der Layoutphase gesetzt 
wird ist mir erst mal egal.
Wahrscheinlich würde ich mir sowieso eine eigene Bibliothek anlegen bei 
der die gängigen Bauteile (R,C, usw) mit einem footprint vorbelegt sind. 
Ich sehe an dieser Stelle kein wirkliches Problem, im Gegenteil. Wenn 
ich an die (in meinen Augen) wirklich vermurkste Bibliotheksverwaltung 
bei Eagle denke, hab ich den KiCAD Workflow nach wenigen Stunden schon 
mehr oder weniger verinnerlicht.

Die Kritik von einigen, dass KiCAD am user vorbei programmiert wurde 
würde ich nicht so krass formulieren, aber ganz unberechtigt ist die in 
meinen Augen auch nicht. Leider gibt's wiklich ein paar "Eigenheiten" in 
der die echt gar nicht nachvollziehen kann.

Ein Beispiel wäre das verschieben von Bauteilen mitsamt Leiterbahnen.

Im Schaltbild:
Einzelbauteil verschieben mit "g".
Bauteilgruppe verschieben mit "m", dann "TAB". Das Gradeziehen der 
danach schiefen Leitungen ist ziemlich mühselig. Warum bleicbt ihre 
Ausrichtung nicht einfach erhalten?
Wenn Zwei Bauteil direkt zusammenhängen (Pin auf Pin) verschieben sich 
beide Bauteile hmmm.

Im Layout:
Bauteil verschieben mit "m". Die Leiterbahnen reisen aber ab. 
Verschieben mit Leiterbahnen hab ich gar nicht geschafft.
Dann verhält sich das Verschieben von Leiterbahnen auch noch 
unterschiedlich je nachdem ob Canvas "Standart" oder "OpenGL" oder 
"Cairo" angewählt ist.
Außerdem muß auch noch vorher der Punkt "Leiterbahn hinzufügen" 
angewählt sein, während im Schaltbild der "Pfeil" angewählt sein muß.

Nach meinem Gefühl ein ziemliches Wirrwarr... (vlt. habe ich's auch 
noch nicht ganz kapiert).

Was ich an Eagle noch sehr geschätzt habe war die komfortable Auswahl 
von bestimmten Bereichen mit einem beliebigen Polygon. Das ist was ich 
sehr an KiCAD vermisse.
Generell empfinde ich das nachträgliche "optimieren" von Schaltbild oder 
Layouts nicht sehr gut gelungen. Alles was mit ändern, schieben, bewegen 
zu tun hat ist doch sehr mühselig.

Es gibt also noch Luft nache oben ;-)

[ZF (Gast)]

Holm T. schrieb:
> Leute der wievielte Therad ist das eigentlich in dem wir uns mit W.S.
> kruden Ansichten über die KiCad vs. Eagle Verfahrensweise
> auseinandersetzen?
> Das ist doch mindestens der 5. oder 6...
> Meint Ihr das hat Sinn?
Ja, nicht wegen W.S., aber wegen der Leute, die es lesen und seinen 
Unsinn sonst vielleicht glauben würden.

> Ich denke nicht das W.S. das mal einsehen wird,
> so lange KiCad nicht gleich Eagle ist wird es für ihn nicht taugen, aber
> ist das wirklich das Problem einer ganzen Community?
Sein Problem sitzt tiefer: Etwas was nichts kostet darf nicht besser 
sein als etwas für das er Geld bezahlt hat. Das ist gegen sein 
Werteverständnis.

[Noob A. (strippenzieher)]

As-I-Roved-Out schrieb:
> Auswählen von Bauteilen und Scrollen ist teilweise doch etwas
> unangenehm
>   (Bauteil packen, an den Fensterrand schieben um weiterzuscrollen,
>    plötzlich 30cm weiter)

Es gibt die Möglichkeit mit Ctrl + Mausrad horizontal zu scrollen. Shift 
+ Mausrad scrollt vertikal.

[KiCadSuperman (Gast)]

As-I-Roved-Out schrieb:
> Kritik von mir:
> .....
> - Autorouter muss man von Hand reinstricken

Frag mal in die Runde wer den vermisst ? ich nicht.

As-I-Roved-Out schrieb:
> Gescheitert bin ich mit:
> dem Export der Echtzeit 3D Darstellung und dem folgenden Import in
> FreeCAD

Frag mal  Tante Google  nach "KiCad ist geil"
gleich der erste Treffer kann dir vieleicht weiterhelfen.

So am Rande:
Das ist übrigens ein  Beispiel für eine gut gemachte SEO Optimierung.
Immer hin gibt es da eine Klickzahl auf die Bilder von über 1000.
(sowas würde man einen Azubi gar nicht zutrauen :O )

[KiCadSuperman (Gast)]

Gu. F. schrieb:
> Ich hab also inzwischen mehrere Tage mit der sw
> gespielt und ein (wenn auch klitzekleines) Projekt erstellt.

Deine Vorgehensweise sich in ein neues CAD einzuarbeiten ist gut!

Aber daraus einen Bericht zu stricken, wo man den Eindruck hat
das war dein 10. Großprojekt ist weniger gut.

Warte es mal eine Zeit lang ab, dann wird sich der Inhalt deines 
Berichtes
umdrehen.

Lese dir dazu nochmals den Eingangsbeitrag vom TO (Bob A.) durch.

[KiCadSuperman (Gast)]

ZF schrieb:
> Sein Problem sitzt tiefer: Etwas was nichts kostet darf nicht besser
> sein als etwas für das er Geld bezahlt hat. Das ist gegen sein
> Werteverständnis.

Da ist W.S bestimmt nicht alleine unterwegs :-(

[Noob A. (strippenzieher)]

Naja, ein paar "Eigenheiten" nimmt man ja in der Tat nur hin weil das 
Programm für lau daher kommt...

Andererseits... falls man sich einbringen möchte, und sei es nur mit 
(hoffentlich) konstruktiver Kritik...

@KiCadSuperman: Ich deute dein Nickname mal so dass du dich mit KiCAD 
recht intensiv befasst hast, deswegen die Frage an deine Adresse: gibt 
es da eine zentrale Annahmestelle für?

[KiCadSuperman (Gast)]

Bob A. schrieb:
> gibt
> es da eine zentrale Annahmestelle für?

für was ??

Meistens entscheidet man sich für einen Nicknamen wenn
man auf den ersten Beitrag im Thread antwortet, weil er dazu
am besten passt.

Gemäß den Forenregeln hier ist man dann aber gezwungen den
gewählten Namen beizubehalten.

Meistens ist es bei mir aber so, dass meine Nicknamen eher
als Understatement daherkommen.

[Noob A. (strippenzieher)]

KiCadSuperman schrieb:
>> gibt es da eine zentrale Annahmestelle für?
>
> für was ??

für jenes was ich davor schrub:

Bob A. schrieb:
> falls man sich einbringen möchte, und sei es nur mit (hoffentlich)
> konstruktiver Kritik...

[KiCadSuperman (Gast)]

Bob A. schrieb:
> gibt
> es da eine zentrale Annahmestelle für?

meinst du das hier ?

https://bugs.launchpad.net/kicad/+bugs?orderby=-date_last_updated&start=0

Um da zu posten musst du angemeldet sein.
Die reagieren recht flott - so meine Erfahrung.

Aber einen Newcomer würde ich  nicht dazu raten da
sofort "Vorschläge zu machen"
Die werden dann meistens sofort wiederlegt
und man selber verliert die Lust dabei.

Hingegen echte "Kinken" kann man sehr wohl posten.
Die müssen aber gut belegbar und nachvollziehbar / reproduzierbar sein!

[Gu. F. (mitleser)]

KiCadSuperman schrieb:
> Warte es mal eine Zeit lang ab,

Warten bringt mir nichts.
Wie wärs, wenn du mir eine Lösung hierfür erklärst.

Gu. F. schrieb:
> Bauteil verschieben mit "m". Die Leiterbahnen reisen aber ab.
> Verschieben mit Leiterbahnen hab ich gar nicht geschafft.


Und diese "Bemerkung" versteh ich jetzt grad gar nicht.

KiCadSuperman schrieb:
> Aber daraus einen Bericht zu stricken, wo man den Eindruck hat
> das war dein 10. Großprojekt ist weniger gut.

P.S. ... siehe Titel des Fadens!

[KiCadSuperman (Gast)]

Gu. F. schrieb:
> Leider gibt's wiklich ein paar "Eigenheiten" in
> der die echt gar nicht nachvollziehen kann.
>
> Ein Beispiel wäre das verschieben von Bauteilen mitsamt Leiterbahnen.

Du kommst halt von einem anderm CAD-Welt.
Das kann ich ja nochvollziehen.

Ich z.B. kann keinen Vorteil darin sehen, dass
z.B. beim Verschieben eines Bauteils quer über die Platine die
Leiterbahnen  angeheftet bleiben.
Sie  bedecken dann sofort alle möglichen Bauteile -
und wie gehts dann weiter ?

Der Weg hier ist (bei KiCad), dass man das Bauteil dort hin bewegt  wo 
man es will (die Netzlinien gehen ja mit).
Dann löscht man die alten Leiterbahn-Stummel und verbindet neu.
(Am besten dann mit P&S) - fertig ist die Schose.

Wie gesagt, warte es mal ab in spätestens einem Jahr siehst du das 
anders.

[Gu. F. (mitleser)]

KiCadSuperman schrieb:
> Ich z.B. kann keinen Vorteil darin sehen, dass
> z.B. beim Verschieben eines Bauteils quer über die Platine die
> Leiterbahnen  angeheftet bleiben.

Ach so, braucht man also nicht.
Ich hab's schon verstanden...

[Gu. F. (mitleser)]

Wenn ich also zwischen DDR-RAM und Controller 5mm mehr Platz brauche muß 
ich 84 Leitungen neu verlegen???

[KiCadSuperman (Gast)]

Gu. F. schrieb:
> Wenn ich also zwischen DDR-RAM und Controller 5mm mehr Platz brauche muß
> ich also 84 Leitungen neu verlegen???

JA und was ist so schlimm dabei?
Hast du sowas mit EAGLE jeden Tag 2x gemacht?

Das schlimmste was einem im realem CAD Leben passiert ist,
dass man z.B. einen 64er QFN Bauteil verschieben muss,
das geht aber leider nicht so schön linear wie im deinem schönen 
Beispiel :-(

[Michael R. (Firma: Brainit GmbH) (fisa)]

KiCadSuperman schrieb:
> JA und was ist so schlimm dabei?
> Hast du sowas mit EAGLE jeden Tag 2x gemacht?

Wie bitte? Also zumindest ich mach das dauernd... und solange die 
Verschiebung in Richtung der Leiterbahn erfolgt, soll sich diese 
gefälligst verkürzen/verlängern, sodass NULL Nacharbeit nötig ist. bei 
anderen Winkeln muss man sowieso ran...

[Karl (Gast)]

ZF schrieb:
> Sein Problem sitzt tiefer: Etwas was nichts kostet darf nicht besser
> sein als etwas für das er Geld bezahlt hat. Das ist gegen sein
> Werteverständnis.

Oh, keine Panik. Bis es soweit ist, wird Kicad noch ein paar Jährchen 
brauchen.

Possetitjel schrieb:
> Man kann zwar den Footprint nachträglich ändern, aber man
> kann kein Symbol ganz ohne Footprint in den Schaltplan
> einfügen.

Natürlich kann man Symbole ohne Footprint einfügen.

Possetitjel schrieb:
> Das komplette Bauteil gehört in die interne "Super-
> stückliste".
> In den Schaltplan gehört eine Referenz auf die entsprechende
> Position der "Super-Stückliste"; der Schaltplaneditor zeigt
> das zugehörige Symbol an.

Deine "Superstückliste" hat einen entscheidenden Denkfehler. Sie ist als 
solche nichts wert. Warum? Darum:

> Zum Beispiel dann, wenn man eine Schaltungsidee hat und
> davon eine SPICE-Simulation machen will.

Eine Stückliste ohne Netzliste ist weder für Schaltplan noch für Layout 
sinnvoll. Es bringt Dir gar nichts alles über die Eigenschaften der 
Bauteile zu wissen, wenn Du nicht weisst wie sie verbunden werden.

[Karl (Gast)]

KiCadSuperman schrieb:
> JA und was ist so schlimm dabei?
> Hast du sowas mit EAGLE jeden Tag 2x gemacht?

Muhaha, ist das geil!

Hier fehlen grundlegende Funktionen und Du säufst Dir das schön, weil Du 
es um jeden Preis verteidigen musst.

Junge, wenn etwas Scheisse ist, dann darf man das auch Scheisse nennen 
und muss es nicht als Schokotorte verkaufen.

[KiCadSuperman (Gast)]

Michael R. schrieb:
> Wie bitte? Also zumindest ich mach das dauernd... und solange die
> Verschiebung in Richtung der Leiterbahn erfolgt, soll sich diese
> gefälligst verkürzen/verlängern, sodass NULL Nacharbeit nötig ist. bei
> anderen Winkeln

... muss man sowieso ran... ach ja?


Karl schrieb:
> Hier fehlen grundlegende Funktionen und Du säufst Dir das schön, weil Du
> es um jeden Preis verteidigen musst.

Deine Formulierungen sind richtig geil - die gefallen mir.


Karl schrieb:
> Junge, wenn etwas Scheisse ist, dann darf man das auch Scheisse nennen
> und muss es nicht als Schokotorte verkaufen.

Da hab ich ja komplett in ein Wespennest gestossen.
(das wollte ich aber nicht :-)

Karl schrieb:
> Muhaha, ist das geil!

...   wie die so rumschwirren :-))

[Gu. F. (mitleser)]

KiCadSuperman schrieb:
> JA und was ist so schlimm dabei?


Klar, mit genügend Spieltrieb kann man auch ein TQP96 neu anschließen. 
Aber meinem Chef möchte ich dann nicht erklären müssen warum ich eine 
Stunde brauche um ein paar mm Platz zu schaffen.

Du hört sich an als hättest du noch nie ein Layout erstellt, zumindest 
außerhalb deiner Freizeit.

[KiCadSuperman (Gast)]

> KiCadSuperman schrieb:
>> JA und was ist so schlimm dabei?

JA und ich bleib dabei.

Notfalls kann man im KiCad
den externen Autorouter bemühen wenn es um solche lineare Verschiebungen
(wie oben beschrieben) geht.
Das geht ratzi fatzi.

@Karl
Für mich ist KiCad geil geiler am geilsten.
Das kommt bei mir gleich nach den Frauen :-))

[Holm T. (Gast)]

Gu. F. schrieb:
> KiCadSuperman schrieb:
>> JA und was ist so schlimm dabei?
>
>
> Klar, mit genügend Spieltrieb kann man auch ein TQP96 neu anschließen.
> Aber meinem Chef möchte ich dann nicht erklären müssen warum ich eine
> Stunde brauche um ein paar mm Platz zu schaffen.
>
> Du hört sich an als hättest du noch nie ein Layout erstellt, zumindest
> außerhalb deiner Freizeit.

Ist ja recht..aber laß KiCad mal ein Bisschen älter und reifer werden.
Das nächste freie CAD System steht ja auch schon in den Startlöchern 
(Beitrag "Horizon EDA [War: Neues, halbfertiges Elektronik-CAD-Programm]") und Eagle sollte eine 
"erfahrene" und durchentwickelte Plattform sein..trotzdem hat es etliche 
Unzulänglichkeiten.

KiCad kostet mich nix und es macht keinen Unterschied ob ich damit für 
mich privat oder in meiner kleinen Firma kommerziell entwickle..das was 
Autodesk sich da denkt geht aber aus beiden Sichten gar nicht.
Die "Freeware" ist nicht mehr zeitgemäß und zu restriktiv, die möglichen 
Platinen zu klein, das was ich kommerziell bräuchte rechnet sich nicht 
und mit der neuen Lizensierung nie mehr.. so wo bitte ist der Vorteil?

..da lebe ich doch lieber mit einem CAD System mit dem ich Alles tun 
kann, das aber u.U. noch nicht ganz fertig ist.

Gruß,

Holm

[ZF (Gast)]

Gu. F. schrieb:
> Klar, mit genügend Spieltrieb kann man auch ein TQP96 neu anschließen.
Schlags den Jungs vor. Frage sie, ob es möglich ist P&S auf das 
Verschieben von Bauteilen mit den angeschlossenen Leiterbahnen zu 
erweitern. Oder arbeite an einer entsprechenden Lösung mit.

[Karl (Gast)]

Holm T. schrieb:
> das was ich kommerziell bräuchte rechnet sich nicht
> und mit der neuen Lizensierung nie mehr..

Sehe ich bei mir genauso. Ich mach mal monatelang keine Leiterplatten, 
dann wieder mehrere. Da hab ich keine Lust ständig die Lizenz 
anzupassen.

Also bleib ich erstmal bei der gut abgehangenen 6.5 im Wissen, dass ich 
die noch ein paar Jahre nutzen und zur Not auch in Kicad importieren 
kann, und schau mal wie sich das entwickelt.

KiCadSuperman schrieb:
> Deine Formulierungen sind richtig geil - die gefallen mir.

Das freut mich.

Ich finde es halt immer witzig, wenn Leute Kritik an der Sache gleich 
als Kritik an sich auffassen und sich dann die blödesten Argumente 
ausdenken, warum die eigentlich doofe Umsetzung jetzt doch ganz toll 
ist.

Leider kommt man dabei technisch nicht weiter, weil eine Diskussion 
abgewürgt wird.

Vor einiger Zeit hiess es bei Kicad zu FB-Anno: Braucht kein Mensch, 
machen wir nicht. Inzwischen gibt es Ansätze dafür und in 1-2 Jahren 
werden sie das wohl implementiert haben. Auch das mit den anhängenen 
Leiterbahnen werden sie implementieren.

Aber dazu muss man halt drüber reden können, und da sind Leute wie Du 
eher hinderlich.

[Holm T. (Gast)]

Karl schrieb:
> Holm T. schrieb:
>> das was ich kommerziell bräuchte rechnet sich nicht
>> und mit der neuen Lizensierung nie mehr..
>
> Sehe ich bei mir genauso. Ich mach mal monatelang keine Leiterplatten,
> dann wieder mehrere. Da hab ich keine Lust ständig die Lizenz
> anzupassen.
>
> Also bleib ich erstmal bei der gut abgehangenen 6.5 im Wissen, dass ich
> die noch ein paar Jahre nutzen und zur Not auch in Kicad importieren
> kann, und schau mal wie sich das entwickelt.
>
[..]

Bin völlig Deiner Meinung nur kommt bei mir hinzu das ich i.A. kein 
Windows auf den Rechnern habe sondern FreeBSD, hier existiert deshalb 
auch keine alte Version von Eagle, das war noch nie praktikabel.
Ich für meinen Teil kann mit KiCad relativ gut arbeiten ..wie Dus mit 
Deiner alten Version E. wahrscheinlich auch kannst. Der einzige Grund da 
ich hier überhaupt das Maul aufgerissen habe sind W.S.s seltsame 
Ansichten.


>Und warum sollte das mit Eagle nicht gehen? Hab ich auch schon für
>eigene Projekte gemacht, die ich vor Jahren mit THT gebaut und dann auf
>SMD aktualisiert habe.
>
>Und das Schöne: Man kann die Footprints im Layout ändern und gleich die
>Platzierung überprüfen - und dank FB-Anno wird das für den Schaltplan
>übernommen.

Man kann auch bei KiCad die Footprints im Layout ändern wenn man 
unbedingt möchte, man muß aber nicht. Der Aufwand das an der richtigen 
Stelle zu machen ist vergleichsweise gering, das übergeordnete KiCad 
fenster mit dem man EEschema und auch PCBnew startet ist doch im 
Hintergrund ständig offen.
es gibt also keinen Grund die Änderung unbedingt im Layouteditor 
durchführen zu müssen, aber man kann es auch tun.

Ich werde Keinem vorschreiben das er nur grüne Schraubendreher zu 
verwenden hat und das Blaue Mist sind.

Gruß,

Holm