mikrocontroller.net

Forum: Platinen [KiCad] Bibliotheksaufbau - Konzeptideen gesucht


Autor: Rene B. (yob) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Mitstreiter,

wie einige von euch bereits wissen entwickelt "Bernd Wiebus alias dl1eic
" eine KiCad-Bibliothek mit Norm-Schaltzeichen und anderen speziellen 
Schaltzeichen für KiCad. Ich habe mich vor 1 Monat dem Projekt 
angeschlossen und nun sind wir beide am überlegen wie man die Bibliothek 
ambesten aufbauen sollte um dem zukünftigen Anwender natürlich ein 
flinkes arbeiten zuermöglichen.

Hier könnt ihr eure Vorschläge, Ideen, Erfahrungen posten und zur 
Diskussion stellen.


Viele Grüße, Rene

Autor: Adlerauge (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, das is jetz nur gefährliches halbwissen meinerseits, aber imho 
arbeiten die entwickler gerade daran, das komplette lib-system von kicad 
umzubauen, nicht dass ihr euch dann jetzt viel mühe gebt und die arbeit 
dann umsonst war..
falls meine info falsch sein sollte, bitte den beitrag einfach überlesen 
;)

Autor: Rene B. (yob) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Adlerauge,

kannst du diese Information bitte noch mit einer Quellenangabe versehen. 
Denn dies wäre eine schon entscheidende Information.

VG, Rene

Autor: Adlerauge (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, gefunden habe ich das auf der neuen seite der entwickler, bei 
launchpad. unter blueprints, https://blueprints.launchpad.net/kicad ist 
von einem neuen library-system die rede. der link von dort führt auf die 
(alte?) sourceforge seite, auf der änderungen aufgelistet werden, es 
scheint aber alles noch nicht besonders weit gediegen..ich hab das auch 
nur durch zufall entdeckt, weil mich halt interessiert wie sich da alles 
entwickelt (is ja vielversprechend..)
ich hoffe das hilft..

Autor: Rene B. (yob) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Besten Dank Adlerauge.

Ich werde das mal unter die Lupe O.O nehmen und versuchen ein paar 
Informationen zu ergattern ;).

Autor: Rene B. (yob) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mir das jetzt mal geschaut und kann dies etwas entkräften. An 
einem neuen Library-System wird scheinbar nicht gearbeitet.

Denn das Änderungsdatum von der alten Sourceforge-Seite lautet:

http://kicad.sourceforge.net/wiki/index.php/New_Li...

>> unten links
This page was last modified 15:16, 4 November 2009

Der Eintrag bei Launchpad ist ebenfalls schon sehr alt:

https://launchpad.net/~kicad-testing-committers/+r... (obere 
Seite)
https://blueprints.launchpad.net/kicad/+spec/kicad... 
(Eintrag)

>> oben rechts
Registered by Manveru  on 2009-10-14

Dafür habe ich einen interessanten BUG-Report gefunden, bei welchem es 
anscheinend um die Problematik des Library_Transportes geht und es 
Schwierigkeiten bei gleicher Symbolbenennung in 2 verschiedenen 
Libraries bei gemeinsamer Nutzung geht.

https://bugs.launchpad.net/kicad/+bug/575810

Autor: Rene B. (yob) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie würdet ihr eine Bibliothek in KiCad aufbauen? Alle Symbole in eine 
Datei, damit man alles schnell zur Hand hat oder bevorzugt ihr eine 
bestimmte Strucktur & Sortierung?

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rene B. schrieb:
> Wie würdet ihr eine Bibliothek in KiCad aufbauen? Alle Symbole in eine
> Datei, damit man alles schnell zur Hand hat oder bevorzugt ihr eine
> bestimmte Strucktur & Sortierung?

Ich hab vor ner Weile meine eigene Eagle-Bibliothek mal auf Vordermann 
gebracht. Dort halte ich das etwa so:
- B (Gleichrichter)
- C (Kondensatoren, unterteilt in polar, bipolar, tantal)
- CON-molex
- CON-pin (Stiftleisten)
- IC-avr
- IC-com (Kommunikation, Bus)
- IC-memory
- IC-opv (Opamps)
- IC-ttl
- IC-vreg (Schaltregler, Linearregler)
- L
- R
- R-pot (Potis)
- T (Transistoren)
usw.

Wo zutreffend, nach Typ gruppiert, sonst nach Bauart, also nicht für 
jeden Wert ein eignes Bauteil.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte mir for längere Zeit mal etliche Libs von Basista glaube ich
(Leiterplattenhersteller Berlin) heruntergezogen, nur Layout ohne 
Symbole,
und die 4.x version. Darin enthalten war auch eine Ellenlange 
Nomenklaturerklärung. Habe viel mit den Libs gearbeitet, auch aus dem 
Grund,
daß viele Symbole, welche in Eagle std-libs mit 6Mil Rules waren, dort 
mit
8 mil rules zu finden waren, ohne DRC verletzung. Sollte es die libs 
nicht
mehr geben, kann ich die gerne posten. Trotzdem wäre ev. auch eine 
ofizielle
Anfrage nicht schlecht, da es ja ein Tool für die Konvertierung von 
Eagle->Kikad gibt, ob man nicht die Libs offiziell konvertieren und als
Kikad Libs freigeben könnte. Könnte die File frühestens Dienstag posten,
trotzdem wäre die ofizielle Anfrage nicht schlecht und ich fand die 
umfangreichen Nomenklatur auch nicht schlecht, bzw. könnte ev. ein 
Ausgangspunkt werden.

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
- Frei eingebbare Tags ermöglichen, damit jeder seine Bibliothek nach 
eigenen Wünschen filtern kann. (Z.B. nach den Namen von Projekten, nach 
Datum, nach Sachgruppen usw.)

- Sämtliche auf MK upgeloadete .sch- und .brd-Dateien mit einem Script 
auf die verwendeten Bauteile absuchen und diese auflisten (mit Tag 
"mk"). Das entspricht dann dem, worüber hier auf der Plattform geredet 
wird.

- Liste nach Häufigkeit der Nutzung sortieren oder gruppieren, so dass 
man das, was man immer wieder braucht, besonders schnell findet.

- Eine Funktion schaffen, mit der man alle schon einmal in einem eigenen 
Projekt genutzten Bauteile filtern kann. "Das hatte ich doch schon mal, 
aber wie hieß das Teil doch noch?"

Autor: Andreas A. (elw-2)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das Projekt von euch finde ich echt super!!
Ich weiss nicht ob du splan kennst, aber evtl. wäre das ja ein 
Bibliotheksabfbau für euch (siehe Screenshot)

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich find, es gibt nix Hinderlicheres beim Arbeiten, als solch 
ellenlange Bezeichnungen. Mich hat das in der Target-Bibliothek schon 
immer gestört, drum hab ichs bei meinen Bibliotheken anders gemacht und 
nur noch kurze, knackige Präfixe benutzt.
Bisher gabs noch keine Namenskollisionen ;-)

Autor: Rene B. (yob) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Abend,

sowie ich das sehe ist eine eine Katalogisierung durch Kategorien 
unerlässlich um eine erste Übersicht zugewährleisten.

Die Idee von  Sven P. (haku) mit kurzen Knackigen Präfixen finde ich 
ganz gut.

Man könnte kurze Präfixe mit einer längeren Bezeichnung kombinieren um 
bei öfterer Nutzung nicht immer alles lesen zu müssen und bei neuer 
Suche nach einem Symbol kann man in Ruhe lesen, das finde ich einen 
guten Kompromiss.

@ Chris (Gast)

Eine Nutzung von anderen Symbolen durch eine Konvertierung ist nicht 
ganz trivial, weil das Urheberrecht beim Ersteller dieser liegt.

@ didadu (Gast)

Dies sind auch gute Ideen jedoch etwickeln wir den Bibliotheks-Browser 
nicht.
Wir erstellen hauptsächlich Symbole & Footprints für KiCad.

@  Andreas A. (elw-2)

Ich habe mit SPLAN nur kurz gearbeitet. Ich werde es die Tage mal wieder 
ausgraben und mir den Aufbau dort anschauen.


Besten Dank an alle für die ersten Tips.

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nett wären auch ein paar fertige Module:
- Spannungswandler inkl. Kondensatoren
- Schaltwandler inkl. passiven Bauteilen für die häufigsten 
Anwendungsfälle
- Prozessoren inkl. Blockern, Quarz, Reset-R usw. für die häufigsten 
Anwendungsfälle
- SD-Card-Anbindung komplett
- Verschiedene häufig verwendete Sensoren
- Verschiedene häufig verwendete Aktoren
- usw.

Die Idee dabei ist, dass bestimmte Sachen immer und immer wieder 
auftreten, von Neulingen (und anderen) immer wieder dieselben Fragen 
gestellt und Fehler gemacht werden, und fertige "Modul-Bausteine" 
könnten die Arbeit vielleicht erleichtern und beschleunigen.

Wenn man dann nur noch einen "Baustein" laden muss, der sogar schon in 
sich geroutet ist, dann muss man nur noch die Leitungen zwischen den 
Bausteinen anschließen und das Projekt ist fertig.

Autor: Bernd Wiebus (berndwiebus) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo didadu
> Nett wären auch ein paar fertige Module:
> - Spannungswandler inkl. Kondensatoren

Gährt hier zur Zeit experimentell. In der KiCAD user group ist schon 
eine Sammlung experimenteller Building Blocks. Allerdings nur LM317 
Schaltungen in (fast) allen Perversionen. Hier liegt eine zu einem 
viertel fertige Dokumentation, wie man rationell das hierarschische 
Schaltplansystem von KiCAD verwendet, um daraus schnell Schaltpläne 
aufzubauen.
Sie mal hier 
http://www.mikrocontroller.net/wikifiles/4/41/Buil...
Es ist ein Beispielprojekt enthalten:
Das File 
KiCAD-HierarchischeSchaltplaene+buildingBlocksRevA_Vorlaeufig.pdf,
ist eine vorläufige Beschreibung dazu. Es fehlt noch die Übersetzung und 
die Bebilderung. Im Ordner Experimentalprojekt23052010 findet sich ein 
weiterer Ordner BuildingBlocksExperimental. Dieser enthält 
VoltageRegulatorBuildingBlock.sch mit
VoltageRegulatorBuildingBlock-cache.lib und 
VoltageDetectorBuildingBlock.sch mit
VoltageDetectorBuildingBlock-cache.lib. Die Projektdateien .pro sind nur 
der Vollständigkeit und zur leichteren Bearbeitung zugefügt. Aus 
VoltageDetectorBuildingBlock.sch und
VoltageRegulatorBuildingBlock.sch wurde im übergeordneten Ordner das 
Projekt VoltageRegulatorBuildingBlock.pro zusammengesetzt.
NICHT VERGESSEN DIE CACHE.LIB EINZUBINDEN!
Sonst gibt es nur Fragezeichen statt Bauteile.

Erzähl mal einer, wie es funktioniert hat. Das Beispielprojekt enthält 
eine 24V Unterspannungsüberwachung für einen Bleiakku, die zwei 12V 
Gruppen überwacht. Nicht elegant, aber hoffentlich robust. :-)


> - Schaltwandler inkl. passiven Bauteilen für die häufigsten
> Anwendungsfälle
> - Prozessoren inkl. Blockern, Quarz, Reset-R usw. für die häufigsten
> Anwendungsfälle
> - SD-Card-Anbindung komplett
> - Verschiedene häufig verwendete Sensoren
> - Verschiedene häufig verwendete Aktoren
> - usw.


Gemach, Gemach.....

>
> Die Idee dabei ist, dass bestimmte Sachen immer und immer wieder
> auftreten, von Neulingen (und anderen) immer wieder dieselben Fragen
> gestellt und Fehler gemacht werden, und fertige "Modul-Bausteine"
> könnten die Arbeit vielleicht erleichtern und beschleunigen.

Sooooo einfach ist es leider nicht. Zum Beispiel die Spannungsregeler 
aus dem Beispiel. Es gibt Fälle, wo der Kühlkörper nötig ist, und Fälle, 
wo er stört. Egal, ob ich eine Bibliothek mit oder ohne Kühlkörper 
bereitstelle, der Anwender muss sich immer überlegen, ob er einen 
benötigt oder nicht, und entsprechend zufügen oder löchen. Stelle ich 
zwei Bibliotheken zu Verfügung, muss er sich überlegen, welche er nimmt.

Ein weiterer Punkt sind Schnittstellen.....ich muss mir immer genau 
ansehen, wie sie im Detail ansehen, wie sie aufgebaut ist. Beispiel: Ich 
würde in einem Ausgang irgendwo einen RC Tiefpass verwenden. Durch das 
Paralellschalten der Ausgänge könnte der C mehrfach auftreten.......oder 
ein anderer Eingang mit ebenfalls RC-tiefpass. Zwei tiefpässe würden 
durch das blinde aneinanderfügen der Building blocks 
hintereinandergeschaltet. Das kann schon zu viel sein. Wenn ich sie 
weglasse, wo? Am Eingang? Am Ausgang? Ganz weglassen? Dann muss auch das 
der Anwender wissen und gegebenenfalls selber zufügen.

Solche Systeme  können nur eine Arbeitserleichterung sein, aber 
keinesfalls das selber denken ersetzten.

Im übrigen ist das ganze zur Zeit auch noch recht gefährlich. Es ist nur 
eine Möglichkeit, die eigentlich so nicht angedacht war. KiCAD stellt 
dazu keine Werkzeuge zur Verfügung, und das ganze lebt vom manuellen 
umkopieren und umbenennen von Dateien. Und immer schön auf die 
~-cache.lib achten. Weil in den Blocks können ja Symbole sein, die man 
selber nicht im System hat......oder anders, mit gleichem 
Namen.....gaaaanz übel.
Vertippt man sich, kann man sich ganz leicht ganz weit wegschiessen. 
z.b. Wenn durch einen Fehler beim Umbenenen der Unterschaltpläne ein 
Unterschaltplan anfängt sich selber zu enthalten.....:O)


>
> Wenn man dann nur noch einen "Baustein" laden muss, der sogar schon in
> sich geroutet ist, dann muss man nur noch die Leitungen zwischen den
> Bausteinen anschließen und das Projekt ist fertig.

"in sich geroutet......". Tja....so weit ist KiCAD leider noch nicht.
Bis jetzt (25.05.2010) geht das ganze nur Brechstangenmäßig mit 
Schaltplänen, nicht mit Boards.

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic


http://www.dl0dg.de

Autor: Bernd Wiebus (berndwiebus) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:

>> Die Idee dabei ist, dass bestimmte Sachen immer und immer wieder
>> auftreten, von Neulingen (und anderen) immer wieder dieselben Fragen
>> gestellt und Fehler gemacht werden, und fertige "Modul-Bausteine"
>> könnten die Arbeit vielleicht erleichtern und beschleunigen.

> Sooooo einfach ist es leider nicht. Zum Beispiel die Spannungsregeler
> aus dem Beispiel. Es gibt Fälle, wo der Kühlkörper nötig ist, und Fälle,
> wo er stört. Egal, ob ich eine Bibliothek mit oder ohne Kühlkörper
> bereitstelle, der Anwender muss sich immer überlegen, ob er einen
> benötigt oder nicht, und entsprechend zufügen oder löchen. Stelle ich
> zwei Bibliotheken zu Verfügung, muss er sich überlegen, welche er
> nimmt.~~~~~~

Achja....den Spannungsteiler zum justieren des LM317 muss er sich auch 
immer noch selber ausrechnen. Ihm im 0,1V Abstand Buildingblocks 
bereitzustelln wäre etwas überkandidelt....mal abgesehen, daß ich es 
manchmal mag, den Abgleich auf mehr als zwei Widerstände im 
Spannungsteiler zu verteilen. Tekade hat früher vergleichbares zur 
Resteverwurstung gemacht, und wenn ich Ausschlachtmaterial verwende, 
oder nur eine eingeschränkte E6 Widerstandsreihe in der Tasche habe, 
kann das nützlich sein.


Mit freundlichem Gruß: Bernd Wiebus alias dl1eic

http://www.dl0dg.de

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
didadu schrieb:
> - Frei eingebbare Tags ermöglichen, damit jeder seine Bibliothek nach
> eigenen Wünschen filtern kann. (Z.B. nach den Namen von Projekten, nach
> Datum, nach Sachgruppen usw.)

Die Idee hatte ich vor einiger Zeit auch schonmal. Hab sogar ne Mail an 
die Entwickler geschickt. Leider nie was davon gehört

http://www.elektronik-projekt.de/thread.php?threadid=6244

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Praktisch wäre auch eine "API" zur Anbindung an die eigene 
Bauteilebibliothek. Und zwar so, dass man alle (und nur) die Teile 
angezeigt bekommt, die man auch hat.

In die umgekehrte Richtung wäre eine Funktion praktisch, die für eine 
von extern (z.B. hier aus dem Forum) geholte, gerade geöffnete Schaltung 
(und eine "Anzahl Exemplare, die ich bauen will") zwei Listen generiert: 
"Diese Bauteile hast Du in Deiner Sammlung" und "Diese Bauteile musst Du 
bestellen".

Für die Bestellung wäre noch eine Funktion nützlich, die beim (bzw. bei 
den) bevorzugten Elektronikhändler einen Warenkorb generiert, den man 
dann nur noch bestätigen muss. (Das erfordert ggf. eine Zusammenarbeit 
mit denen, damit die dortige API überhaupt existiert.)


Zur Auswahl von "Modulen": Wenn ich hier im Wiki auf die Seite 
"Konstantstromquelle" gehe, finde ich mehrere Schaltungsvorschläge. 
Jeder hat seine Vorteile und seine Nachteile. Die sollten natürlich als 
Auswahlhilfe angegeben werden.
Ob nun nur die Schaltung oder auch ein Board-Element in das Projekt 
importiert wird, erscheint mir eher wie eine Frage des schrittweisen 
Vorgehens. Bei layoutkritischen Sachen (HF, Leistungs-Schaltelektronik) 
ist ein Vorlayout natürlich hilfreich.

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd Wiebus schrieb:
> den Spannungsteiler zum justieren des LM317 muss er sich auch
> immer noch selber ausrechnen

Warum nicht die Formeln mit implementieren? Bei Aufruf des Moduls oder 
beim Anklicken eines "Formel"-Ankers im Schaltplan wird das geöffnet 
(als Dialog), was sonst immer irgendwo einer als Javascript zum 
Selbst-Berechnen ins Web gestellt hat -- aber wo war das man noch? 
Gerade beim jeweiligen Modul wäre das doch am Besten aufgehoben.
Wenn so eine Möglichkeit für den User erstmal gegeben ist, das selbst 
(per "Scripting") zu implementieren, wird es sicher Leute geben, die 
solche Module für alle bauen.

> "Gemach, Gemach..."
Schon klar, aber es geht ja hier um Konzeptideen, also das "wie stelle 
ich mir die ideale Arbeitsumgebung vor".

Noch eine Idee: Eine Datenblattverwaltung, die sowohl an meine 
Inventarliste (Inventar-Bauteilebibliothek) als auch an die 
Layoutprogramm-Bauteilebibliothek angebunden ist. Es ist ja toll, dass 
es die ganzen PDFs heute alle im Internet gibt, aber da sie manchmal nur 
etwas manuell-umständlich (und aus nicht immer ganz klarer Quelle) 
auffindbar und herunterladbar sind (unter teilweise sehr undeutlichen 
Dateinamen), fände ich eine geeignete PDF-Verwaltung hilfreich. Vor 
allem sollten die Schlüsseldaten nicht nur als PDF vorliegen, sondern 
auch direkt in den Bauteilebibliotheken abrufbar sein.

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
didadu schrieb:
> Noch eine Idee: Eine Datenblattverwaltung,

Ist die nicht schon drin? Habe sowas in Erinnerung,
aber bisher nicht benutzt.

Autor: Bernd Wiebus (berndwiebus) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo didadu und guido

>> den Spannungsteiler zum justieren des LM317 muss er sich auch
>> immer noch selber ausrechnen
>
> Warum nicht die Formeln mit implementieren?

Aeeehm......es geht hier um Symbol Bibliotheken ZUR EINBINDUNG in KiCAD, 
nicht um KiCAD selber und etwaige zukünftige Scripte.

Ansonsten ist die Idee nicht schlecht, abgesehen von den ganzen 
Sonderfällen.....:O)


> Noch eine Idee: Eine Datenblattverwaltung, die sowohl an meine
> Inventarliste (Inventar-Bauteilebibliothek) als auch an die
> Layoutprogramm-Bauteilebibliothek angebunden ist. Es ist ja toll, dass
> es die ganzen PDFs heute alle im Internet gibt, aber da sie manchmal nur
> etwas manuell-umständlich (und aus nicht immer ganz klarer Quelle)
> auffindbar und herunterladbar sind (unter teilweise sehr undeutlichen
> Dateinamen), fände ich eine geeignete PDF-Verwaltung hilfreich. Vor
> allem sollten die Schlüsseldaten nicht nur als PDF vorliegen, sondern
> auch direkt in den Bauteilebibliotheken abrufbar sein.

>> Noch eine Idee: Eine Datenblattverwaltung,
>Ist die nicht schon drin? Habe sowas in Erinnerung,
>aber bisher nicht benutzt.

Nicht wirklich. Ich verwende dafür lieber Jabrev, um Tags und Bibtex 
Einträge an meine PDFs zu pappen, und ansonsten eine desktop suche. Das 
ist NOCH flexibler und universeller......
Ausserdem ist sie bei KiCAD vor allem an Module, weniger an Symbole 
gebunden. Eigentlich auch nicht für Datenblattsuche, sondern zum 
Betrachten und Suchen in den Footprints.....

Jedenfalls ist das Hauptproblem, das Du generische Bauteile nicht 
explizit an herstellergebundene Datenblätter binden möchtest. Und was 
ist, wenn Du Deine PDF Dateien umgruppierst? Dann brauchst Du zwei 
Ordnersysteme. Einmal das originale, was Du nach herzenslust 
umgruppieren kannst, und ein fixes, nur mit den Dateien, die Du für 
KiCAD brauchst. (Das mache ich nur zum Schluss, wen ich die Daten 
rausgebe....... )
Oder halt wieder ein Indexsystem, wie bei der Desktop suche......

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic

http://www.dl0dg.de

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd Wiebus schrieb:
> Jedenfalls ist das Hauptproblem, das Du generische Bauteile nicht
> explizit an herstellergebundene Datenblätter binden möchtest.

Doch doch, ich möchte das. Ich habe z.B. das Problem, dass ich die 
Spannungsfestigkeit einer Spule herausfinden will. Wenn ich dann nicht 
Zugriff auf verschiedene (!) Datenblätter der Hersteller (und ggf. deren 
Adressen) habe, dann wird es sehr langwierig.

Weitere Ideen:
Es gibt eine Menge libraries, die im Web verstreut sind. Natürlich gibt 
es z.B. http://www.kicadlib.org/, wo man sicher viel "findet" ... wenn 
man das Gewünschte denn findet, nach dem meiner Meinung nach doch recht 
umständlichen Suchen.

Mein erster Ansatz wäre daher immer, erstmal alles Bestehende zu sammeln 
(Herunterladen, Auspacken, alle Dateinamen, Bauteilenamen, Download-URLs 
usw. in eine DB, möglichst auch die jeweiligen Lizenzen!), dann mir eine 
Schnittstelle zu machen, um das alles möglichst einfach und schnell 
abzurufen. (Sowas ist mit Python, einem lokalen Ad-hoc Server und 
sqlite3 recht schnell gemacht.) Dann kann man erstmal überhaupt gucken, 
was es denn schon alles gibt. Sicher eine ganze Menge.
Wenn man mehr braucht, geht man über google und sucht nach Stichwörtern, 
die auf weitere Bibliotheken führen, wo man dann noch mehr runterladen 
kann (inurl:.lib oder so), den URL und am Besten die E-Mail immer mit 
abspeichern!

Der nächste Schritt wäre die Anbindung an Kicad selbst, also der einfach 
Export der von mir selbst gewünschten Listen.

Wenn man einen Schritt weiter gehen möchte, organisiert man eine 
gemeinsame Anstrengung, eine weltweite Datenbank aller Bauteile 
aufzubauen, die mögilchst allen Ansprüchen und Wünschen gerecht wird. 
Erst dann wird es wirklich ein Projekt, das langfristig allen viel Zeit 
und Mühe spart. Da wären dann z.B. auch Übersetzungen der Beschreibungen 
hilfreich. Man könnte automatisch alle Lib-Ersteller (die das nicht 
sowieso unter GPL o.ä. gestellt haben) anschreiben und ihnen anbieten, 
die Daten mit in die Datenbank aufzunehmen. (Wo sie für den persönlichen 
Gebrauch eh schon sind, aber eben noch nicht öffentlich.)

Autor: Bernd Wiebus (berndwiebus) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo didadu.

> Wenn man einen Schritt weiter gehen möchte, organisiert man eine
> gemeinsame Anstrengung, eine weltweite Datenbank aller Bauteile
> aufzubauen, die mögilchst allen Ansprüchen und Wünschen gerecht wird.

Wie wahr. Leider werden meine Fähigkeiten diesen Anforderungen nicht 
gerecht. Ich fürchte, ich werde diese kleine Aufgabe Dir überlassen 
müssen.

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic

http://www.dl0dg.de

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd Wiebus schrieb:
> ich werde diese kleine Aufgabe Dir überlassen müssen

Wir danken für das uns ausgesprochene Vertrauen :-D

Ich bin aber auch nur einer.

Wie alle anderen auch.

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rene B. schrieb:
> doch etwickeln wir den Bibliotheks-Browser
> nicht.
> Wir erstellen hauptsächlich Symbole & Footprints für KiCad.

Ich verstehe noch nicht ganz, wie ihr vorgeht.

Es gibt ja schon so viele Dinge, wollt ihr also das Rad neu erfinden?
Oder wollt ihr etwas vereinheitlichen?
Oder etwas aktualisieren, erneuern?
Etwas neu kategorisieren?
Etwas vervollständigen?

Was genau ist es, das ihr verbessern wollt?

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir scheint außerdem, dass es verschiedene Schaltsymbol-Stile gibt. Also 
z.B. einen europäischen, einen amerikanischen, vermutlich noch weitere. 
Dann gibt es alte und neue Darstellungsnormen (z.B. bei Logikbauteilen). 
Das alles beeinflusst die Darstellung (Footprint im Schaltplan) ein- und 
desselben Bauteils, und es gibt da sicher benutzerspezifische 
Präferenzen. Ich bin mir nicht sicher, dass es dafür 
Umschaltmöglichkeiten in den existierenden Schaltplaneditoren gibt, also 
muss man das Programm umgehen und entsprechende Umschaltungen in den 
bereitgestellten Footprint-Libraries machen.

Im Übrigen gibt es noch erhältliche Bauteile und mehr oder weniger 
historische Bauteile (die man aber in Altgeräten finden und evtl. nutzen 
möchte). Auch da bieten sich Umschaltmöglichkeiten in der 
Library-Verwaltung an.

Weiters gibt es verschiedene Bezeichnungen und Synonyme für Bauteile und 
Bauteilekategorien. Das ist eine Frage der ALIASE und der Übersetzungen. 
Wenn man seine Bibliothek gut kennt, hat man die direkten 
Bauteile-Bezeichnungen im Kopf, aber es ist eine große Hürde am Anfang 
und wenn man ein Bauteil sucht, das man nicht so gut kennt oder erstmals 
verwendet. Da ist eine Suchhilfe nützlich, und möglichst viele Aliase, 
die den Weg zum Bauteil ermöglichen. Dabei steht auch die Usability im 
Vordergrund, z.B. dass bei Eingabe eines Anfangsbuchstabens sofort die 
ganzen Auswahlmöglichkeiten erscheinen, oder auch Symbole zum Anklicken, 
oder mehrere unterschiedliche Kategorisierungen.

Das alles läuft meiner Meinung nach auf eine Kicad-externe 
Bauteilverwaltung heraus, die dann jeweils das gewünschte Bauteile-Set 
in der vom jeweiligen User bevorzugten Form an die richtige Stelle im 
Verzeichnisbaum des Rechners mit dem richtigen Namen exportiert, um es 
dann in Kicad zu nutzen.

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch ein paar Pointer für Interessierte:

Libraries:
Offizielle "contribs": http://www.kicadlib.org/
DARC: 
http://www.darc.de/distrikte/l/02/dateien/dl1eic/S...
Umgewandelte Eagle-Libraries: http://library.oshec.org/
More: http://www.google.de/search?q=kicad+libraries

Script zum Umwandeln von Eagle-Symbolen (wo das rechtlich 
unproblematisch ist) in Kicad-Symbole: eagle2kicad-0.9b.ulp

Quick KICAD Library Component Builder: 
http://kicad.rohrbacher.net/quicklib.php

Gibt es eigentlich auch ein Tool für die Umwandlung KiCad=>Eagle? Wäre 
vielleicht auch interessant.

Mich nervt das Gesuche in den Libraries so sehr (egal ob Eagle oder 
KiCad) -- das ist ein echter Turn-Off --, dass ich mir wohl ein 
Such-Tool dafür mache, und zwar ungefähr so wie oben angegeben.

Wie in OSS üblich, besteht die Tendenz ja immer darin, alle Formate in 
alle anderen umwandeln zu können. Das sehe ich auch so. Warum soll man 
nicht EINE Datenbank der Teiledaten haben, die dann für ALLE Tools 
Exporte machen kann? Die Grunddaten sind ja dieselben, nur die konkrete 
Codierung variiert. Einlesen, Verarbeiten und Exportieren der 
KiCad-Daten sehe ich unproblematisch, das sind alles Text-Files. Selbst 
einen Parser und Checker könnte man noch bauen (für manuell erstellte 
Dateien).

Aber hat jemand eine Beschreibung des Eagle-Formats?

Außerdem fände ich es sinnvoll, wenn man auch in KiCad schon bei der 
Bauteile-Auswahl eine Gehäuse-Auswahl machen könnte. Dann hat man es in 
einem Arbeitsgang schon erledigt, das erscheint mir einfach praktischer. 
Wahrscheinlich könnte man in den Libraries entsprechende bevorzugte 
Gehäuseformen als Kommentar eingeben und dann nach der 
Schaltplanerstellung mit einem Script eine Verknüpfungsdatei 
(vor-)erstellen, die auf diesen Angaben basiert.

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch ein paar Pointer für Interessierte:

Libraries:
Offizielle "contribs": http://www.kicadlib.org/
DARC: 
http://www.darc.de/distrikte/l/02/dateien/dl1eic/S...
Umgewandelte Eagle-Libraries: http://library.oshec.org/
More: http://www.google.de/search?q=kicad+libraries

Script zum Umwandeln von Eagle-Symbolen (wo das rechtlich 
unproblematisch ist) in Kicad-Symbole: eagle2kicad-0.9b.ulp

Quick KICAD Library Component Builder: 
http://kicad.rohrbacher.net/quicklib.php

Gibt es eigentlich auch ein Tool für die Umwandlung KiCad=>Eagle? Wäre 
vielleicht auch interessant.

Mich nervt das Gesuche in den Libraries so sehr (egal ob Eagle oder 
KiCad) -- das ist ein echter Turn-Off --, dass ich mir wohl ein 
Such-Tool dafür mache, und zwar ungefähr so wie oben angegeben.

Wie in OSS üblich, besteht die Tendenz ja immer darin, alle Formate in 
alle anderen umwandeln zu können. Das sehe ich auch so. Warum soll man 
nicht EINE Datenbank der Teiledaten haben, die dann für ALLE Tools 
Exporte machen kann? Die Grunddaten sind ja dieselben, nur die konkrete 
Codierung variiert. Einlesen, Verarbeiten und Exportieren der 
KiCad-Daten sehe ich unproblematisch, das sind alles Text-Files. Selbst 
einen Parser und Checker könnte man noch bauen (für manuell erstellte 
Dateien).

Aber hat jemand eine Beschreibung des Eagle-Formats?

Außerdem fände ich es sinnvoll, wenn man auch in KiCad schon bei der 
Bauteile-Auswahl eine Gehäuse-Auswahl machen könnte. Dann hat man es in 
einem Arbeitsgang schon erledigt, das erscheint mir einfach praktischer. 
Wahrscheinlich könnte man in den Libraries entsprechende bevorzugte 
Gehäuseformen als Kommentar eingeben und dann nach der 
Schaltplanerstellung mit einem Script eine Verknüpfungsdatei 
(vor-)erstellen, die auf diesen Angaben basiert.

Und gEDA <=> KiCad geht dann vielleicht auch noch irgendwann.

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
[Sorry für den Doppelpost, da war eine Fehlermeldung, die mich schließen 
ließ, dass der Server busy ist und der Post nicht ankam.]

Hier die gEDA Filespecs:
http://www.geda.seul.org/wiki/geda:file_format_spec

Autor: Rene B. (yob) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Abend alle miteinander,

wie ich sehe gibt es neue Ideen ^^.

didadu schrieb:
> Mir scheint außerdem, dass es verschiedene Schaltsymbol-Stile gibt. Also
> z.B. einen europäischen, einen amerikanischen, vermutlich noch weitere.
> Dann gibt es alte und neue Darstellungsnormen (z.B. bei Logikbauteilen).
> Das alles beeinflusst die Darstellung (Footprint im Schaltplan) ein- und
> desselben Bauteils, und es gibt da sicher benutzerspezifische
> Präferenzen.

didadu schrieb:
> Weiters gibt es verschiedene Bezeichnungen und Synonyme für Bauteile und
> Bauteilekategorien.

Richtig! Dies ist vorallem von der jeweiligen Norm des entsprechenden 
Fachgebietes abhängig.

didadu schrieb:
> Das alles läuft meiner Meinung nach auf eine Kicad-externe
> Bauteilverwaltung heraus,

So ist es! Hier setzen wir an, in dem wir nach unseren gegebenen 
Möglichkeiten der Norm entsprechnden Symbole als auch Hersteller 
spezifische Symbole und Footprints erstellen. Zudem versuchen wir diese 
wiederum mit einer aussagekräftigen Nomenklatur zuversehen.

Man bedenke bitte auch das nicht jede Kopie (Symbol oder Footprint) 
eines anderen Erstellers auch nach dem Recht des jeweiligen Landes 
einfach so in jedem Arbeitsbereich oder Komerzielle Zwecke verwendet 
werden darf!

Nicht in allen Bereichen ist nur eine Anleitung zum Einschalten eines 
Gerätes nötig.

Wir schaffen die Basis ;).


> die dann jeweils das gewünschte Bauteile-Set
> in der vom jeweiligen User bevorzugten Form an die richtige Stelle im
> Verzeichnisbaum des Rechners mit dem richtigen Namen exportiert, um es
> dann in Kicad zu nutzen.

Dies impliziert für mich eine Datenbank als Verwaltungssystem von 
Symbolen und Footprint sowie anderen zugehörigen Daten. Ich persöhnlich 
kenne mich mit Datenbanksystemen nicht sehr gut aus. Ich weis durch 
andere Quellen das ein solches System nicht trival ist, da ja eine 
stetige Konsistenz der Daten gewährleistet werden muss/soll und 
Änderungen bei falschen Einträgen ohne großen Aufwand kaum zubeheben 
sind.

Ich befürchte ebenso ein, das dadurch eine kunter bunte Bibliothek 
entsteht in der es zwar alles geben mag aber es kein einheitliches 
Konzept der Zeichnung gibt. Jede Linie, Abstände, Anschlüsse wie es der 
Ersteller bevorzugt. Dies ist für den einfachen Bastler nicht so schlimm 
aber solbald es ein Gruppenprojekt wird und man auf den Austausch von 
Schaltungsunterlagen angewiesen ist wird es auch optisch ganz schnell 
murks und der Überblick ist nicht mehr gegeben.


Die Konzeptideen sind ansich alle sehr gut, diese beinhalten aber auch 
eine Verpflichtung auf mehrere Jahrzehnte und müssten noch ausgiebigeren 
Prüfungen unterzogen werden ;).

Ich selbst programmiere keine Anwendungsprogramme dieser Art, nur 
Automatisierungs- & Messsoftware mit LabView und besitze dementsprechend 
nicht ganz so den Einblick in die Materie. Ein µC ist da viel harmloser
und einfacher zu programmieren ;).

---

VG, Rene

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

haette da auch noch ein paar Ideen/Anmerkungen:

didadu schrieb:
> ...
> Wie in OSS üblich, besteht die Tendenz ja immer darin, alle Formate in
> alle anderen umwandeln zu können. Das sehe ich auch so. Warum soll man
> nicht EINE Datenbank der Teiledaten haben, die dann für ALLE Tools
> Exporte machen kann? Die Grunddaten sind ja dieselben, nur die konkrete
> Codierung variiert. Einlesen, Verarbeiten und Exportieren der
> KiCad-Daten sehe ich unproblematisch, das sind alles Text-Files. Selbst
> einen Parser und Checker könnte man noch bauen (für manuell erstellte
> Dateien).
>

Am Beispiel des Quick KICAD Library Component Builder kam mir mal vor 
laenger folgende Idee: Jeder soll online einen Baustein eingeben und 
fuer andere abspeichern koennen. So fuellt man mal die Datenbank. Der 
naechste Schritt ist die Sicherung eines Standards und der Qualitaet, 
deshalb muesste sich jemand um das eigentliche Format und die 
Verifizierung kuemmern. Schreit nach Web-Anwendung, nicht?

Zu dem omnipotenten Datenformat, das du ansprichst: Ich habe noch nicht 
den Einblick in die allgemeine Formatvielfalt, aber wuerde mal schwer 
wetten, dass man mit XML relativ weit kommt: von XML kommt man in 
relativ linear aufgebaute Formate recht gut mit XSLT-stylesheets (ich 
generiere hier z.B. C-Code aus komplexen XML-Beschreibungen). Wenn 
nicht, muss man halt einen Translator selbst schreiben (z.B. in Python 
keine Hexerei).

Das grosse Problem ist nun, sich ein schlaues XML-Format zu ueberlegen, 
was moeglichst alle Format-Eigenheiten abstrahiert.

Zurueck zur Ambition der umfassenden, schrittweise perfektionierbaren 
Bibliothek: Ich habe vor der Komplexitaet solcher Anforderungen erst mal 
kalte Fuesse bekommen, sprich: fuer mich waere es utopisch, das mal in 
vernuenftiger Zeit umsetzen zu koennen.
ABER: Wenn es jemand hinbekommt, einen Library-Server aufzusetzen und 
mit einem Authoring-Tool a la KICAD component builder plus 
Datenbankvernetzung und einem Bewertungs-System ("Design verifiziert", 
etc.)  dem Designervolk zugaenglich macht, muesste das eigentlich sogar 
laengerfristig Marktwert haben, sobald man eine Community hostet, die 
fuer einen arbeitet.

Also nochmal in der Zusammenfassung die "Utopia":

1. XML-Format definieren, Translator sheets schreiben (zunaechst Kicad, 
Eagle)
2. Web-Interface schreiben, Datenbank designen (wie sortiert man diese 
Unzahl an Bausteinen)
3. Eventuelle Schnittstellen zu Authoring-Tools zusaetzlich entwickeln
4. Die Community die Datenbank aufbauen lassen (Gehaeuse, 3D-Daten, 
Schema/Pinmaps/Gehaeusevarianten, Kreuzverweise)

Ich wette, dass Farnell sowas in der Richtung anstreben wird - aus 
irgend einem Grund hat man ja wohl Cadsoft eingekauft.

Das Projekt muesste irgendwie zu einem Selbstlaeufer werden, damit es 
laengerfristig funktioniert (und die Initianten nicht von der 
Komplexitaet her auffrisst). Finanzieren soll es sich auch koennen, das 
koennte dadurch funktionieren, dass kommerzielle Anbieter die Daten fuer 
ihre Tools lizenzieren koennen, bzw. die Entwicklung der Translator 
(XML->Anbieterformat) finanzieren.

> Aber hat jemand eine Beschreibung des Eagle-Formats?

Leider nein. Aber vielleicht waere das auch ueber die ULP-Schnittstelle 
nicht noetig?

>
> Außerdem fände ich es sinnvoll, wenn man auch in KiCad schon bei der
> Bauteile-Auswahl eine Gehäuse-Auswahl machen könnte. Dann hat man es in
> einem Arbeitsgang schon erledigt, das erscheint mir einfach praktischer.
> Wahrscheinlich könnte man in den Libraries entsprechende bevorzugte
> Gehäuseformen als Kommentar eingeben und dann nach der
> Schaltplanerstellung mit einem Script eine Verknüpfungsdatei
> (vor-)erstellen, die auf diesen Angaben basiert.

Dem kann ich mich auch anschliessen. Anhand der wuenschenswerten 
Web-Datenbank sollte man die Listen mit den verfuegbaren Packages zum 
Baustein generieren koennen (d.h. den Package-Filter).

Soweit mal mein Senf, ich werde das mal auf jeden Fall mitverfolgen..

Gruesse,

- Strubi

Autor: Yob (Rene B.) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie du schon schön geschrieben hast ist die Datenbank durch ihre vielen 
Parametern und deren x-Verknüpfungen unter einander eine mehr 
Jahresprojekt ohne das irgendwelche Massen an Symbolen und 
Footprintserzeugt werden müssen, das kommt dann von allein. Von der 
Verifizierung der Eingabedaten mal ganz abgesehen ;).

Das Farnell so etwas auf die Beine stellt glaub ich nicht außer es 
rappelt grad einen beim durchlesen hier ;). Thema: "Instandhaltung" wird 
abschrecken, denke ich.

Ich würde hier eher Leutz von Multisim[NI] vermuten, die sind so 
Größenwahnsinnig ^^. Wundern tut mich das "Tina" von Designsoft, so 
klein ist trotz [TI] im Rücken. Diese Software hat meiner Meinung auch 
das Potential für solch ein Projekt. KiCad fehlt leider noch die 
Kopplung zur Simulation.

So nun muss ich aber noch bissel was zeichnen ;).


----

VG, Rene

Autor: didadu (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, hier ist mal eine sortierte Liste der auf www.gedasymbols.org (die 
Site ist etwas unübersichtlich...) befindlichen Footprints und Symbole.

Angegeben sind als Tablist jeweils Typ (Footprint ODER Symbol), der 
Dateiname und der URL zum Aufrufen der Seite mit dem Download-Link.

Vielleicht hilft das den ;-) Bibliothekaren, den Inhalt der dort 
auffindbaren Objekte einzuschätzen.

Eine Symboldatei beispielsweise sieht dann etwa so aus:
v 20081231 1
P 0 200 200 200 1 0 0
{
T 100 250 5 8 0 1 0 6 1
pinnumber=1
T 100 150 5 8 0 1 0 8 1
pinseq=1
T 100 250 9 8 1 1 0 0 1
pinlabel=+
T 250 200 5 8 0 1 0 2 1
pintype=pwr
}
P 700 200 500 200 1 0 0
{
T 600 250 5 8 0 1 0 0 1
pinnumber=2
T 600 150 5 8 0 1 0 2 1
pinseq=2
T 450 200 9 8 0 1 0 6 1
pinlabel=2
T 450 200 5 8 0 1 0 8 1
pintype=pwr
}
T 350 450 8 10 1 1 0 3 1
refdes=B?
T 0 1700 5 10 0 0 0 0 1
device=Battery
T 0 700 5 10 0 0 0 0 1
author=Stefan Salewski
T 0 900 5 10 0 0 0 0 1
description=Battery
T 0 1100 5 10 0 0 0 0 1
numslots=0
T 0 1300 5 10 0 0 0 0 1
dist-license=GPL
T 0 1500 5 10 0 0 0 0 1
use-license=unlimited
L 200 400 200 0 3 0 0 0 -1 -1
L 300 300 300 100 3 0 0 0 -1 -1
L 400 400 400 0 3 0 0 0 -1 -1
L 500 300 500 100 3 0 0 0 -1 -1

Man findet dort auch Abbildungen der Objekte, und sonstige Tools.

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier ist die Beschreibung des Dateiformats der KiCad 
Schaltsymbol-Libraries:

http://en.wikibooks.org/wiki/Kicad/file_formats#Sc...

Konkretes Beispiel:
EESchema-LIBRARY Version 2.3  Date: 20/2/2009-09:35:03
#
# SW_DIP_1
#
DEF SW_DIP_1 SW 0 40 Y Y 1 F N
F0 "SW" 0 125 60 H V C C
F1 "SW_DIP_1" 0 -125 60 H V C C
DRAW
S 50 20 120 -20 0 1 0 F
P 4 0 1 0  130 30  130 -30  130 -30  130 -30 F
P 4 0 1 0  -130 30  -130 -30  -130 -30  -130 -30 F
P 4 0 1 0  -130 30  -130 -30  -130 -30  -130 -30 F
P 4 0 1 0  130 30  130 -30  130 -30  130 -30 F
S 50 20 120 -20 0 1 0 F
S -175 50 175 -50 0 1 0 N
S -140 30 140 -30 0 1 0 N
S -140 30 140 -30 0 1 0 N
X ~ 1 425 0 251 L 50 50 1 1 B
X ~ 2 -425 0 251 R 50 50 1 1 B
ENDDRAW
ENDDEF
#
# SW_DIP_2
#
DEF SW_DIP_2 SW 0 40 Y Y 1 F N
F0 "SW" 0 175 60 H V C C
F1 "SW_DIP_2" 0 -175 60 H V C C
DRAW
S 50 -30 120 -70 0 1 0 F
P 4 0 1 0  130 -20  130 -80  130 -80  130 -80 F
P 4 0 1 0  -130 -20  -130 -80  -130 -80  -130 -80 F
P 4 0 1 0  -130 -20  -130 -80  -130 -80  -130 -80 F
P 4 0 1 0  130 -20  130 -80  130 -80  130 -80 F
S 50 -30 120 -70 0 1 0 F
S 50 70 120 30 0 1 0 F
P 4 0 1 0  130 80  130 20  130 20  130 20 F
P 4 0 1 0  -130 80  -130 20  -130 20  -130 20 F
P 4 0 1 0  -130 80  -130 20  -130 20  -130 20 F
P 4 0 1 0  130 80  130 20  130 20  130 20 F
S 50 70 120 30 0 1 0 F
S -140 80 140 20 0 1 0 N
S -140 80 140 20 0 1 0 N
S -140 -20 140 -80 0 1 0 N
S -140 -20 140 -80 0 1 0 N
S -175 100 175 -100 0 1 0 N
X ~ 1 425 -50 251 L 50 50 1 1 B
X ~ 2 425 50 251 L 50 50 1 1 B
X ~ 4 -425 -50 251 R 50 50 1 1 B
X ~ 3 -425 50 251 R 50 50 1 1 B
ENDDRAW
ENDDEF

Sieht also so ähnlich aus wie die gEDA-Symbole. Würde mich wirklich 
wundern, wenn man das nicht recht einfach zusammenführen könnte. Auch 
die Formatbeschreibungen sind überschaubar.

Autor: Martin S. (strubi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich schmeisse nochmal lose ein paar Inputs rein:

- Habe mal mit phpmyadmin und einer MYSQL Datenbank plus nem Python 
script eben etwas rumgespielt. Die Datenbank als solche systematisch 
aufzubauen, duerfte, sobald das Framework steht, keine riesen Sache 
sein. Siehe Anhang.
- Zum Framework: Mit PHP und einigen Masken kann man mal weitermachen 
und Daten einzugeben (mit phpmyadmin eher muehsam).
- Ich denke, geda, kicad, eagle, und alle anderen Formate abzudecken, 
schreit nach einem erweiterbaren Meta-format, da faellt mir erst mal nur 
XML ein. Es kann sein, dass man im Zuge der Entwicklung feststellt, dass 
die Struktur des Formats nicht optimal ist. Der Vorteil beim XML ist, 
dass man einen Formatkonverter relativ schnell geschrieben hat, und alle 
bestehenden Daten schoen automatisch in das "neue" Format umkonvertiert 
hat (Stichwort XSLT stylesheets)
- XML laesst sich sehr schoen mit dem freien XMLmind XML Editor (xxe, in 
Java) editieren. Die Beschreibung des eigentlichen Meta-Formats fuer 
Komponentendaten geschieht ebenfalls in Stylesheets (XSD).

Um den Beduerfnissen und der Systematik allen Usern gerecht zu werden, 
müsste man dem Nutzer erlauben, per Script die lokale library 
entsprechend aus der Online-Datenbank zu generieren (und zwar nur die 
gewuenschten/abonnierten Komponenten). Das waere mal das zu loesende 
PULL-Problem (koennte einfach ueber einen direkten mysql-Zugang gehen). 
Die Systematik von User "haku" finde ich schon mal einen guten Ansatz a 
la "keep it simple", die wuerde ich schon mal so in die Datenbank 
uebernehmen.

Das PUSH-Problem ist das naechste: Wie werden die Daten im Meta-Format 
erzeugt, was fuer Autorentools muessen geschrieben werden? Wie einfach 
ist es, z.B. aus kicad ein "Meta-Format" auszugeben, oder gibt es 
allenfalls bessere Tools? (bei der Part-Verwaltung hat kicad ein paar 
fiese Boecke, es darf an der gleichen Position nicht mehr als einen Pin 
geben)

Ja, und dann die Aufgabenverteilung: Der, der sich den Managerhut 
anzieht, muesste auch fast gleich Wiki und Datenbank zur Verfuegung 
stellen, sonst sieht's mit der Kooperative schon mal schwierig aus, und 
die Diskussion wird ausufern, bevor ueberhaupt ein Prototyp laeuft.

Meiner Meinung nach muessten sich also verschiedene Profis verschiedene 
Aufgabenbereiche krallen:

1) PHP/Datenbank/Eingabemaske (bestehende Tools nutzen? kicadlib, 
Component Builder)
2) Format-Design (XML), erste XML-Formatkonverter-Prototypen fuer kicad, 
geda, Eagle, usw.
3) Tools zum Erstellen der Rohdaten, also Pinlisten, und Package-Design 
(online? kicad-Export in XML?)
4) Community management

Die Sache ist riesig komplex, aber ich wuerde mir spasseshalber mal Teil 
2) unter die Lupe nehmen.

Der Erfolg oder das Scheitern eines solchen Projekts haengt nach meiner 
Erfahrung meist im Endeffekt von Punkt 1) und einem guten Web-Interface, 
spaeter von Punkt 4), also des Willens einer Usergruppe, Daten zu 
konvertieren/eingeben, ab. Alles andere fiele unter schrittweise 
Iteration..

Gruesse,

- Strubi

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> ich wuerde mir spasseshalber mal Teil
> 2) unter die Lupe nehmen.

Wenn Du für jedes Format einen Parser geschrieben und verstanden hast, 
wozu die verschiedenen Befehle und Werte benutzt werden, dann wird Dir 
auch klar, was in die Metadaten muss. (Es macht ja keinen Sinn, sich aus 
der hohlen Hand ein XML-Format auszudenken.)

Mein erster Schritt wäre, alle bekannten Symbole im Originalformat in 
eine DB einzulesen (jeweils mit genauer Herkunftsangabe und dem Typ 
(also "KiCad", "gEDA" usw.) und dann ein Script zu machen, das mir die 
Bilder generiert, damit man überhaupt mal sehen kann, was es da gibt 
(und um sich mit dem Parsen vertraut zu machen).
Außerdem ein Script, das mir alle verfügbaren Metadaten aus den 
jeweiligen Formaten extrahiert, in eine separate Tabelle schreibt und 
per Suche erschließt.
Wenn ich einen kleinen Pinheader suche, möchte ich z.B. mir mal eben 
schnell alle Teile anzeigen lassen, die 2 Pins haben. Oder alle, wo ein 
Pin "MISO" heißt. Oder alle, die einer bestimmten Norm genügen (das 
müsste man dann als neues Metadatenfeld dazutragen). Oder einen 
bestimmten Autor haben. Oder zu einer bestimmten Firma gehören. Oder ein 
bestimmtes Package haben. Usw.

Mit solchen Funktionen dürfte das Vergleichen, Neukategorisieren und 
Ausmisten hoffentlich erleichtert werden.

Als Parserschreiber hat man ja die Datenformate komplett begriffen, dann 
dürften die Exporte also auch keine große Hürde mehr sein.

Bei gEDA sind übrigens die Kategorien (wichtige Metadaten für eine 
thematische Suche) teilweise in separaten Dateien enthalten, die man 
teilweise in den Archiven von den Websites mit runterlädt und also 
ebenfalls auswerten sollte.

So komplex finde ich das alles gar nicht, nachdem ich in die Dateien 
geschaut und mir die verfügbaren Erläuterungen (s.o. die Links) 
durchgelesen habe. Eher unerwartet simpel.

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
didadu schrieb:
> Wenn Du für jedes Format einen Parser geschrieben und verstanden hast,
> wozu die verschiedenen Befehle und Werte benutzt werden, dann wird Dir
> auch klar, was in die Metadaten muss. (Es macht ja keinen Sinn, sich aus
> der hohlen Hand ein XML-Format auszudenken.)

Nee, ich wuerde gerade eben vermeiden, einen Parser fuer alle 
erdenklichen Formate zu schreiben, das kann uebelst ausarten. Das 
Meta-Format soll ja moeglichst simpel sein, und nicht zwingend alle 
Schweinereien der End-Formate enthalten - zumindest nicht als erstes. 
Aber natuerlich muss man verstanden haben, welche Eigenschaften ein 
Format abdeckt.

Habe mal testweise meine device-beschreibungs-sprache (normalerweise 
fuer register genutzt) aufgebohrt. Das sieht dann per Baustein so aus:
  <device id="FT2232H" name="FT2232H" protocol="PROPERTY">
    <revision>
      <major>0</major>

      <minor>1</minor>
    </revision>
    <schematic name="FT2232H" unitcode="U">
      <schematic:part name="A">
        <schematic:pin id="1" name="VCC">
          <schematic:geometry orientation="LEFT">
            <schematic:coordinate x="250" y="500" />
          </schematic:geometry>
        </schematic:pin>

        <schematic:pin id="2" name="GND">
          <schematic:geometry orientation="RIGHT">
            <schematic:coordinate x="750" y="500" />
          </schematic:geometry>
        </schematic:pin>
      </schematic:part>
    </schematic>
  </device>

Laesst sich bereits in eine rudimentaere kicad lib uebersetzen, es 
fehlen halt nur noch einige Optionen.

Wenn Metadaten in Custom-Formaten in mehreren Files verteilt sind, 
sollte das auch kein grosses Problem sein, diese mit den XSLT's zu 
extrahieren.

Wenn sich dann eben rausstellt, dass es fuer ein weiter hinzukommendes 
Format unerlaesslich ist, den XML-Dialekt zu aendern, dann tut man das 
halt, konvertiert die "Legacy" und zaehlt die Versionsnummer hoch, damit 
man auch Kompatibilitaeten abdecken kann.

In der Tat nicht ganz so wild, aber bis es dann funktioniert, braucht es 
schon einige Mannmonate an vereinten Kraeften.

Nu warte ich mal ab, was sonst noch an Ideen zusammenkommen..

Gruesse,

- Strubi

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> ich wuerde gerade eben vermeiden, einen Parser fuer alle
> erdenklichen Formate zu schreiben, das kann uebelst ausarten.

Ich verstehe nicht, wie Du die Daten in das XML-Neuformat überführen 
willst, wenn Du sie nicht parst.

> Das
> Meta-Format soll ja moeglichst simpel sein, und nicht zwingend alle
> Schweinereien der End-Formate enthalten

Es soll vor allem keine Informationen verlieren. Die Leute haben sich 
die Mühe gemacht, die Symbole zu erstellen, das würde ich nicht 
missachten wollen.
Außerdem würde ich lieber gleich Nägel mit Köpfen machen (die Symbole 
sind ja nicht gerade sehr kompliziert gestrickt: Kästen, Linien, Bögen, 
Text), als ewig lange mit mehrfachen Formatänderungen rumzuhuddeln.

Andererseits will ich auch niemanden abhalten, es zu tun, wie sie es für 
richtig hält. :-)

Wenn man sich die Daten lange genug anschaut, hat man ja schon (selbst) 
gar keine großen Fragen mehr, um seine Bauteile zu finden/zu erstellen, 
womit sich so ein Projekt für einen selbst dann natürlich mehr oder 
weniger erübrigt. Es ist dann halt nur noch ein Projekt für die 
folgenden Erstwanderer im Bauteilwald.

Die ursprüngliche Absicht hier war ja anscheinend auch eher, komplett 
neue Symbole nach bestimmten Richtlinien zu erstellen. Das ist ja noch 
mal wieder ein anderes Feld als das "Jagen und Sammeln" des Vorhandenen.

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
didadu schrieb:
> Ich verstehe nicht, wie Du die Daten in das XML-Neuformat überführen
> willst, wenn Du sie nicht parst.

Na ganz einfach ein gut wiederverwertbares Exporter-Plugin fuer die 
diversen Tools schreiben. Wer lieber einen Parser baut, kann das ja 
ebenfalls tun.

> Die ursprüngliche Absicht hier war ja anscheinend auch eher, komplett
> neue Symbole nach bestimmten Richtlinien zu erstellen. Das ist ja noch
> mal wieder ein anderes Feld als das "Jagen und Sammeln" des Vorhandenen.

Das stimmt eigentlich schon. Aber meiner Meinung nach sollte man bei 
solchen Projekten gerne mal ein bisschen in die Infrastruktur klotzen, 
sonst bleibt die gute Idee meist auf halber Strecke stecken, weil die 
Community fehlt. Ohne "Standard" werden viele User nicht auf den Zug 
aufspringen und weiter ihre eigene Suppe kochen.

Gruss,

- Strubi

Autor: Bernd Wiebus (berndwiebus) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo didadu.

> Wenn Du für jedes Format einen Parser geschrieben und verstanden hast,
> wozu die verschiedenen Befehle und Werte benutzt werden, dann wird Dir
> auch klar, was in die Metadaten muss. (Es macht ja keinen Sinn, sich aus
> der hohlen Hand ein XML-Format auszudenken.)

Mmmh. Zum Thema XML und Platinen: Was ist mit IPC-2581?
Siehe: http://webstds.ipc.org/2581/documents/IPC-2581pubv1.0.pdf

Leider habe ich zur Zeit wenig Zeit, mich so Richtig darum zu 
kümmern......und ich kann nicht programmieren. :-(

Jedenfalls habe ich angefangen, Symbole und Module/footprints für KiCAD 
zu erstellen, weil sie mir fehlten.

Einen universellen Dateibrowser mit Konvertierungsfeatures für alle 
gängige PCB-Layout Programme zu erstellen, ist für mich drei Hutnummern 
zu groß. :O)


Mit freundlichem Gruß: Bernd Wiebus alias dl1eic

http://www.dl0dg.de

Autor: Bernd Wiebus (berndwiebus) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Martin S. und Sven P.

> Nee, ich wuerde gerade eben vermeiden, einen Parser fuer alle
> erdenklichen Formate zu schreiben, das kann uebelst ausarten.

Das mit dem ausarten kann ich verstehen. ;-)

>Das
> Meta-Format soll ja moeglichst simpel sein, und nicht zwingend alle
> Schweinereien der End-Formate enthalten - zumindest nicht als erstes.

Nicht als erstes.....weil alles fängt klein an. Aber es wird darauf 
hinauslaufen müssen.

Viel kleiner:
Was ich als erstes nützlich finden würde, wäre ein tool, das es erlaubt, 
die Bauteile in unterschiedlichen .libs / .mods hin und her zu schieben 
und umzuverteilen, sowie eine Möglichkeit, komplette Gruppen von 
Symbolen umzubenennen, und zum Beispiel mit einem Versionssufix / 
Datecodesufix zu versehen.
Es sollte ein Sufix sein, und kein Prefix, weil KiCAD Alphanumerisch 
nach Namen im Symbol/Modulbrowser sortiert, der User das aber erst in 
zweiter Linie wissen will/ wissen muss. Diese Info im Namen ist aber 
wichtig, weil KiCAD Symbole/Module nach dem Namen in die Schaltung 
bindet. Aenderst Du die Version, aber den Namen nicht, und öffnest eine 
älteres Projekt mit einer neueren library Version, kann es unliebsame 
Überraschungen geben.
Die Situation ist unter der Verwendung der -cache.lib, die zum Projekt 
gehört, rettbar, aber es ist mühselig, und der Ärger ist persistent, 
wenn Du nicht nur die -cache.lib verwenden willst, sondern auch eine 
aktuelle .lib, weil Du an dem Projekt etwas ändern möchtest, und die 
aktuelle .lib eine neue Version des Symbols unter gleichem Namen 
enthält....

Zu sven P.:
>Also ich find, es gibt nix Hinderlicheres beim Arbeiten, als solch
>ellenlange Bezeichnungen. Mich hat das in der Target-Bibliothek schon
>immer gestört, drum hab ichs bei meinen Bibliotheken anders gemacht und
>nur noch kurze, knackige Präfixe benutzt.
>Bisher gabs noch keine Namenskollisionen ;-)

Ich kann Deinen Einwand verstehen, aber Versionssufix / Datecodesufix 
werden den Namen noch länger machen.
Und wenn ich die Symbole auswählen will, ohne immer in der Tiefe 
rumsuchen zu müssen, wüsste ich eben schon gerne am Namen schnell, was 
es ist. Und zwar auch bei einem Symbol / Modul, das ich seit snderthalb 
Jahren nicht angepackt habe.
Ich gestehe, das ich auch gelegentlich die Fenster in den Symbol/Modul 
Browsern von KiCAD etwas knapp finde, aber letztlich ist es für mich das 
kleinere Übel.
Obiges hypothetisches Tool könnte die Situation entschärfen, weil man 
sich damit schnell eine individuelle "Buddys" .lib schaffen könte, wo 
der Widerstand nur "R" heißt. Kürzer und knackiger gehts dann kaum. ;-)

>Mit freundlichem Gruß: Bernd Wiebus alias dl1eic

http://www.dl0dg.de

Autor: Rene B. (yob) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo alle zusammen,

für kristallisieren sich hier 2 Projekte heraus. Wie von "didadu" 
bereits das schön herrausgestellt hat.

1. Das eretellen  von neue Symbole nach bestimmten Richtlinien.
2. Das Jagen und Sammeln des Vorhandenen und Neuem.

Im Bezug auf das XML-Format und einer simplen einfachen Umsetzung kann 
ich mir folgenden TAG-Aufbau vorstellen.

> <device id="FT2232H" name="FT2232H" protocol="PROPERTY">
>     <revision>
>       <major>0</major>
>       <minor>1</minor>
>     </revision>
im Oberern Teil werden wichtige Daten von Hand über ein Interface 
eingegeben, voerst.

>     <KiCad-Lib>
eingefügter verweis zum Speicherort der KiCad-Lib
>     </Kicad-lib>

>     <Eagle-Lib>
eingefügter verweis zum Speicherort der KiCad-Lib
>     </Eagle-lib>

>     <Geda-Lib>
eingefügter verweis zum Speicherort der KiCad-Lib
>     </Geda-lib>

>     <Other-Lib>
eingefügter verweis zum Speicherort der KiCad-Lib
>     </Other-lib>

>   </device>

Das ganze dann noch nach entsprechender Norm (noch nnicht durchgewälzt) 
wäre perfekt, denke ich.

>Mmmh. Zum Thema XML und Platinen: Was ist mit IPC-2581?
>Siehe: http://webstds.ipc.org/2581/documents/IPC-2581pubv1.0.pdf

Einauslesen von diversen verschiedenen Parametern in verschiedenen 
eigenständigen Formaten halte ich für Overkill. Wenn die 
CAD-Softwarehersteller ihr eigenes Format verändern muss auch das 
entsprechende Auslesetool angepasst werden. Dies beinhaltet eine Feste 
Regelungsstrucktur, welche sich ausschließen um diese Problemtaik 
kümmern muss um damit eine perfekte Schnittstelle zum sammeln Daten 
bereit zustellen.

Mein Vorschlag zielt darauf ab eigenständige Formate der jeweiligen 
Hersteller nicht zu analysieren zu müssen (vorerst) und zusätzliche 
wichtige/interessante Informationen mit zuspeichern.

Daraus lässt sich ebenso schnell erkennen welche Angaben benötigt 
werden, welche sich im späteren Verlauf der Projektentwicklung auch 
automatisiert aus den Cad-Software spezifischen Formaten auslesen lassen 
sollten. So kann man dann hergehen und die Programmierer der jeweiligen 
CAD-Software anschreiben und diese bitten die gesuchten Informationen 
mit in aufzunehmen und in einer entsprechenden Strucktur in ihrem Format 
abzulegen. Zudem findet auch eine Kommunikation beider Parteien statt, 
statt eines reinen Reagieren auf eine Vielfalt & Änderungen von 
Parametern, sowie Formaten ansich.

Zu bedenken ist natürlich das diese ganzen gesammelten Information noch 
in keinster Weise in der jeweiligen CAD-Software zur Verfügung stehen! 
Dies ist ebenso Aufgabe der Programmierer der CAD-Software ;).

Nun ist die Frage wo man denn als Erstes ansetzt?

PS: Große Hobbies kann man haben, nur die Frage ob man die Zeit hat?
---

VG, Rene

Autor: Bernd Wiebus (berndwiebus) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rene B.

> für kristallisieren sich hier 2 Projekte heraus. Wie von "didadu"
> bereits das schön herrausgestellt hat.
>
> 1. Das eretellen  von neue Symbole nach bestimmten Richtlinien.
> 2. Das Jagen und Sammeln des Vorhandenen und Neuem.
>

Ich sehe darunter sogar drei verschiedene Projekte:

1. Das erstellen von neuen Symbolen (und footprints) speziell für KiCAD.

2. Das Jagen und Sammeln vorhandener Symbole, und deren Erfassung in 
einer Datenbank (universell für unterschiedliche PCB-Layout Programme). 
Diese Datenbank soll auf ein PDF Archiv mit Datenblättern Und 
Applikationen verweisen.

3. Das Erstellen einer Symbol- und Footprintbibliothek in einem 
hochflexiblen und offenem Format, welches es erlaubt, mit einer noch zu 
erstellenden Konverter Toolchain die verschiedenen offenen und 
proprietären (wenn sie denn bekannt sind) Formate zu importieren und zu 
exportieren. Gleichzeitig soll eine Datenbank existieren, welches die 
einzelnen Symbole und Footprints und deren Versionen untereinander und 
mit einem Kommentar- und Datenblatt- und Applicationsarchiv verknüpft.

Ich persönlich werde mich auf Punkt 1 konzentrieren. Diese Aufgabe ist 
in Bezug auf Symbole unter einigen Nebenbedingungen für mich fast 
abgeschlossen. Ich wollte eine Symbolbibliothek ähnlich EN60617 / DIN617
für diskrete elektronische Bauteile. Sprich Symbole für R, C, L, diverse 
Dioden, Transistoren, Thyristoren, Stecker, Relais......also das, was 
ich neben den ICs auf jeden Fall brauche, und die ich (persönlich) auch 
gerne in einer einzigen Symbolbybliothek vereine. Die habe ich nun. Noch 
ein paar Sachen dazugepackt, die sich als praktisch herausstellten, und 
jetzt noch an den Feinheiten feilen......
Symbole für ICs sind wieder ein anderes Kapitel, Footprints sowieso.

Der Sinn von Punkt 2 erschliesst sich mir nicht wirklich. Weil das habe 
ich bisher zu eigener Zufriedenheit mit einer Dateiverwaltung und einer 
Desktopsuche (Beagle) erledigt. Wenn ich meine, das an PDF Dokumente 
noch Bibtext Einträge gehören, mache ich die mit Jabrev. Richtig, 
bezüglich Jabrev hätte ich auch noch Wünsche offen, aber es funktioniert 
gut. ;-)

Punkt 3 ist eine Herkules Aufgabe. Schreib doch einer mal eine E-mail an 
Donald Knuth. Vieleicht braucht der ja abends Abwechslung, wenn er den 
ganzen Tag an tex gewartet hat. ;-)

Persönlich stehe ich ja auf dem Standpunkt: Besser machen heisst Selber 
machen. Leider stosse ich dabei eben oft an meine Grenzen, was meine 
Zeit und auch meine Fertigkeiten angeht.

> PS: Große Hobbies kann man haben, nur die Frage ob man die Zeit hat?

Richtig. Manchmal ergänzt sich aber das eine oder andere auch mit 
dienstlichen Aufgaben. :-)

>Mit freundlichem Gruß: Bernd Wiebus alias dl1eic

http://www.dl0dg.de

Autor: Rene B. (yob) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd Wiebus schrieb:
>> PS: Große Hobbies kann man haben, nur die Frage ob man die Zeit hat?
>
> Richtig. Manchmal ergänzt sich aber das eine oder andere auch mit
> dienstlichen Aufgaben. :-)

Genau so sehe ich das auch. Mir persöhnlich ging das schon so bei der 
Fage nach dem einarbeiten überhaupt in KiCad selbst.

Bernd Wiebus schrieb:
> Ich wollte eine Symbolbibliothek ähnlich EN60617 / DIN617
> für diskrete elektronische Bauteile. Sprich Symbole für R, C, L, diverse
> Dioden, Transistoren, Thyristoren, Stecker, Relais......also das, was
> ich neben den ICs auf jeden Fall brauche, und die ich (persönlich) auch
> gerne in einer einzigen Symbolbybliothek vereine. Die habe ich nun. Noch
> ein paar Sachen dazugepackt, die sich als praktisch herausstellten, und
> jetzt noch an den Feinheiten feilen......

Das fand & finde ich einfach klasse eine Bibliothek mit genormten 
Schaltzeichen nutzen zukönnen. Mein Anliegen ist ja ebenso diese mit 
weiteren Symbolen zu füllen. Denn dies ist die Basis die man immer 
brauch ;-).

In Punkto IC's & Footprints ist das meisten eine individuelle Geschichte 
je nachdem am welchen Projekt man gerade arbeitet, da füllt sich eine 
Bibliothek mit der Zeit.

Da ich nicht über 1000 Pdfs besitze erledigt bei mir eine einfache 
Ordnerstrucktur und die Software "Mendeley" die Dokumenten Verwaltung. 
Von daher hält sich mein Eifer in dieser Sache eine Perfektion 
anzustreben für direkte Zugriffe von der Cad-Software "KiCad" über DB's 
auch in Grenzen, eher "nice to have".

Das Thema Zeit ist für mich wichtig, weil ich noch andere berufliche 
Pläne verfolge und mein Hobby ein kleines Hobby ist!, wenn ich denn mal 
Zeit habe.

---

VG, Rene

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Bernd,

Bernd Wiebus schrieb:
> Viel kleiner:
> Was ich als erstes nützlich finden würde, wäre ein tool, das es erlaubt,
> die Bauteile in unterschiedlichen .libs / .mods hin und her zu schieben
> und umzuverteilen, sowie eine Möglichkeit, komplette Gruppen von
> Symbolen umzubenennen, und zum Beispiel mit einem Versionssufix /
> Datecodesufix zu versehen.
> Es sollte ein Sufix sein, und kein Prefix, weil KiCAD Alphanumerisch
> nach Namen im Symbol/Modulbrowser sortiert, der User das aber erst in
> zweiter Linie wissen will/ wissen muss. Diese Info im Namen ist aber
> wichtig, weil KiCAD Symbole/Module nach dem Namen in die Schaltung
> bindet. Aenderst Du die Version, aber den Namen nicht, und öffnest eine
> älteres Projekt mit einer neueren library Version, kann es unliebsame
> Überraschungen geben.

Momentan loese ich das Versions-Problem per SVN (dafuer habe ich separat 
ein Repository fuer alle lokalen Libraries):

- Ich lege einen Projektfolder $(PCBDIR)/project1 fuer ein neues Projekt 
an
- Setze einen svn:externals auf mein library-repository mit Ziel 
$(PCBDIR)/project1/lib und checke die aktuelle Version aus
- Gibt es Aenderungen an der Library von anderen Projekten aus, committe 
ich die einfach und update die Projekte, wo ich die Updates jeweils 
brauche. Und muss natuerlich ev. Anpassungen vornehmen.
- Wenn ich ein Projekt einfriere (Platine mache), wird der external auf 
eine explizite Library-Revision festgefroren, oder zusaetzlich im Sheet 
die Revision-Nummer der Library notiert.

Heisst, jeder Projektordner hat einen versionskontrollierten 
lib/-Unterordner. Das kicad so gut mit SVN funktioniert, macht es 
eigentlich echt unschlagbar fuer Gruppenarbeiten.

Ich wuerde in so einem Fall auch nicht versuchen, eine eigene 
Versionskontrolle zu erfinden, sondern eher Schnittstellen zu SVN oder 
git in kicad einbauen, um die jetzige Handarbeit noch bequemer zu 
machen.

Die Frage ist nur, ob man wirklich eine Versionskontrolle PER Baustein 
innerhalb der Library braucht. Hier wuerde ich eher sagen: Keep it 
simple, man legt sich einfach mehrere Libraries mit ev. denselben 
Objekten an, und schaut, dass man die Versionsnummern im Griff hat.

Allerdings ist eben das Herumschieben von Symbolen wie Du sagst, etwas 
muehsam, man muss echt aufpassen, dass man die Komponente aus der 
richtigen Library importiert, wenn man mit mehreren Versionen 
arbeitet. Kommt bei mir gottseidank nicht so oft vor.

> Punkt 3 ist eine Herkules Aufgabe. Schreib doch einer mal eine E-mail an
> Donald Knuth. Vieleicht braucht der ja abends Abwechslung, wenn er den
> ganzen Tag an tex gewartet hat. ;-)

Das stimmt. Aber ich haette das Framework dazu auf einer andern 
Baustelle fertig (nennt sich "netpp" und ist eine universelle Library 
zum Fernsteuern von beliebigen registerbasierten Geräten, Chips, etc.).
Muss dazu etwas ausholen:
Die Komplexitaeten von XML nach irgendwas zu konvertieren waeren damit 
so ziemlich "im Griff" - in obigem Fall ist es C-Code, Dokumentation, 
VHDL-Registertabellen, usw. Du erstellst also eine XML-Datei mit der 
Geraetebeschreibung, heraus kommt nach dem "make" eine Bibliothek, die 
auf Geraeteseite mit dem geraeteunabhaengigen Frontend (PC) ueber 
beliebige Interfaces kommuniziert und komplett mit der Hardware 
synchronisiert ist. Das laesst sich genauso auf eine 
Schematic-Bibliothek uebertragen, sei es per peer-to-peer oder ueber 
einen Format-Translator (Es gibt ja XMLRPC, UPnP und Konsorten, aber die 
sind weit vom Attribut "leichtgewichtig und universell" entfernt).
Man muss sich wirklich nur noch die Format-Erweiterung fuer 
Schematic-Entities ueberlegen (also: "Was muss noch alles rein").
Ich will das Teil nach 7 Jahren Einsatz demnaechst opensourcen, insofern
waeren das zwei Fliegen mit einer Klappe. ABER: Was noch fehlt, ist die 
Datenbank, um alle Geraete zu erfassen und kategorisieren.
Da mir eben auch die Zeit wie allen fuer solche Spaesse begrenzt ist, 
sehe ich eben nur die Chance, eine Community (oder schon mal 5 
talentierte Hacker) dafuer zu begeistern.
Insofern ist das Hauptproblem an der Sache, diese zig Beduerfnisse 
verschiedener User unter einen Hut zu kriegen, sprich, einen "Standard" 
zu schaffen. Ich habe miterlebt, wie muehsam das innerhalb der EMVA sein 
kann (Stichwort GenICam-Standard, der das obige spezifisch fuer 
Industriekameras angegangen hat), den firmenpolitischen Ballast haetten 
wir hier ev. nicht.

Prinzipiell spricht ja nichts dagegen, erst mal mit kicad anzufangen, 
und sich dann als naechstes fuer die fertige, standardisierte und freie 
library-collection zu ueberlegen, wie man das ganze in eine Datenbank 
quetscht und es auch anderen usern im kommerziellen Bereich (also in 
anderen Formaten) zugaenglich macht. Mit Versionshistory, und was 
dazugehoert.

Die bessere Investition faende ich allerdings immer noch die 
Datenbank/Plattform, auf der man den "Standard" im Rahmen einer 
Usergruppe prototypen und weiteroptimieren kann. Sonst lohnt sich 
zumindest fuer mich das Projekt erst mal nicht, da ich mit den 
bestehenden Symbolen soweit arbeiten kann.
Wo ich eher Zeit sparen wuerde, waeren die komplexen Chips mit vielen 
Pins, die vermutlich einige User im Component Builder generieren, aber 
nie anderen zur Verfuegung stellen (koennen).
Im Prinzip waere ich schon mit reinen Pin-Listen zufrieden (bei manchen 
Chips parse ich die BSDL-Files um ein rohes .LIB-File zu generieren, und 
drehe dann die Pins manuell hin).

Mal sehen, vielleicht wird der Winter wieder kalt, bis dann werd ich mir 
spaetestens das Datenbankproblem unter die Lupe genommen haben. Wenn 
aber jemand mitmachen will und gut PHP kann (und Zeit hat), soll er laut 
HIER schreien :-)

Gruesse,

- Strubi

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmal an Bernd:

Wo wir gerade beim Thema SVN sind: Habt ihr euch schon ueberlegt, 
einfach mal das Projekt auf dem hiesigen (mikrocontroller.net sei dank) 
SVN-Server zu starten? Wenns ausartet und manche User Mist committen, 
kann man's spaeter immer noch regeln :-)
Gleichzeitig koennten diverse User dann auch noch ihre Tools und 
Hilfs-Scripte hochladen, und wir merken dann ev. so nach und nach, was 
das Projekt noch braucht.

Gruesse,

- Strubi

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
An Rene, der in Beitrag #1726853 schrob:


>>     <KiCad-Lib>
> eingefügter verweis zum Speicherort der KiCad-Lib
>>     </Kicad-lib>
>
>>     <Eagle-Lib>
> eingefügter verweis zum Speicherort der KiCad-Lib
>>     </Eagle-lib>

Eigentlich nur eine kleine Anmerkung: Alles herstellerspezifische würde 
ich so als eigenstaendigen tag moeglichst vermeiden, sondern eher was a 
la:

<liburl vendor="kicad">/pfad/zur/datei</liburl>

machen. Spezifische Meta-Daten ebenfalls in was wie:

<meta vendor="kicad" delim=";">
optionX=blabla;
optionY=gnagna;
</meta>

Sonst muss man fuer jeden hinzugekommenen "vendor" den Dialekt 
aufblaehen.

Rene B. schrieb:
> Einauslesen von diversen verschiedenen Parametern in verschiedenen
> eigenständigen Formaten halte ich für Overkill. Wenn die
> CAD-Softwarehersteller ihr eigenes Format verändern muss auch das
> entsprechende Auslesetool angepasst werden. Dies beinhaltet eine Feste
> Regelungsstrucktur, welche sich ausschließen um diese Problemtaik
> kümmern muss um damit eine perfekte Schnittstelle zum sammeln Daten
> bereit zustellen.
>
> Mein Vorschlag zielt darauf ab eigenständige Formate der jeweiligen
> Hersteller nicht zu analysieren zu müssen (vorerst) und zusätzliche
> wichtige/interessante Informationen mit zuspeichern.

Wenn das nach beim kurzen Ueberfliegen des IPC-Dingens richtig 
verstanden hab, soll das aber nur ein Standard anstelle von Gerber sein, 
richtig? Also in kicad-Sprache, nur die MOD-Seite abdecken, aber nicht 
die LIB.

Ich wuerde hierbei die Komplexitaet des IPCschiessmichtot erst mal 
meiden, und erst spaeter versuchen, den eigenen XML-Dialekt dem Standard 
anzunaehern.

Autor: Rene B. (yob) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> An Rene, der in Beitrag #1726853 schrob:
>
>
>>>     <KiCad-Lib>
>> eingefügter verweis zum Speicherort der KiCad-Lib
>>>     </Kicad-lib>
>>
>>>     <Eagle-Lib>
>> eingefügter verweis zum Speicherort der KiCad-Lib
>>>     </Eagle-lib>
>
> Eigentlich nur eine kleine Anmerkung: Alles herstellerspezifische würde
> ich so als eigenstaendigen tag moeglichst vermeiden, sondern eher was a
> la:
>
> <liburl vendor="kicad">/pfad/zur/datei</liburl>
>
> machen. Spezifische Meta-Daten ebenfalls in was wie:
>
> <meta vendor="kicad" delim=";">
> optionX=blabla;
> optionY=gnagna;
> </meta>
>
> Sonst muss man fuer jeden hinzugekommenen "vendor" den Dialekt
> aufblaehen.

Ich kenne mich mit XML wie gesagt nicht so aus. Die Idee besteht darin 
voerst nur Verweise zu den original Daten einzusetzen um es simpel 
zuhalten. Für Tag-Schreibweisen und Optimierung kommst du ins Spiel, wie 
du gut aufgezeigt hast ;). Dies bezieht sich natürlich rein auf das 
sammeln von Daten. Die Meta-Daten dachte ich vorerst von Hand 
einzugegeben, durch ein fest vordefiniertes Interface. Das ist ja auch 
nicht anders als wie beim Erstellen in KiCAd selbst auch.

Martin S. schrieb:
> Wenn das nach beim kurzen Ueberfliegen des IPC-Dingens richtig
> verstanden hab, soll das aber nur ein Standard anstelle von Gerber sein,
> richtig? Also in kicad-Sprache, nur die MOD-Seite abdecken, aber nicht
> die LIB.
>
> Ich wuerde hierbei die Komplexitaet des IPCschiessmichtot erst mal
> meiden, und erst spaeter versuchen, den eigenen XML-Dialekt dem Standard
> anzunaehern.

>>(noch nicht durchgewälzt)


Hier noch eine kleine Info. didadu hat noch eine kleine Brücke in 
anderer Richtung geschlagen :).

didadu schrieb im Beitrag #1727948:
> Re: Teile-Verwaltung für elektronische Bauteile
>
>       Autor:
>       didadu (Gast)>
>       Datum: 29.05.2010 10:02
>

>
>       Schaut doch bitte mal hier rein:
> Beitrag "[KiCad] Bibliotheksaufbau - Konzeptideen gesucht"
> Vielleicht lassen sich da sinnvolle Verknüpfungen schaffen.
>
> Interessant wäre auch mal eine öffentliche, lizenzfreie Datenbank ALLER
> existierenden (auch historischen) Elektronikkomponenten.
> Das ließe sich sicher vereinfachen, wenn die Benutzer solcher
> Datenbanken, die in diesem Thread das Thema sind, eine Funktionen
> hätten, um alle unterschiedlichen Teile in eine Liste zu exportieren,
> die dann irgendwer sammelt und allen zur Verfügung stellt.
>
> Wenn man dann noch sowas wie "popularity contest" (s. Debian) einbaut,
> wüsste man, welche Teile am häufigsten eingesetzt werden, um eine
> Richtlinie zu haben, in welcher Priorität man Footprints erstellt, seine
> Bauteilesammlung erweitern kann, usw.


Wenn ich den bisherigen Content hier im Thread so betrachte, vorallem 
den Input von den Programmierern, muss ich teileise ganz schön staunen, 
was so in Runde eingebracht wird. Einerseits sehr zukunftsorientiert und 
zugleich irgendwie selbstverständlich, "das wird irgendwie schon" bzw. 
die Basis ist schon versteckt fertig.

---

VG, Rene

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmal n Gedanke:
das mag jetzt nach Schnellschuss und schrecklicher Aufblaehung des 
eigentlichen Projekts klingen, aber da die Utopie schon laenger gaert, 
muss der Furz nun raus (wer nicht wagt, gewinnt auch nix):

Zur Embedded World Messe (ich glaube ungefaehr Maerz 2011, Nürnberg) 
gibt es ja die Moeglichkeit, Workshops zu organisieren, und auch Papers 
einzureichen. Vielleicht hat ja jemand Lust, an einem Konzeptpapier 
mitzuarbeiten, was mit viel Glueck an der Embedded eventuell etwas 
Aufmerksamkeit bekommen koennte. Abgesehen davon koennte man probieren, 
einen Raum fuer einen Workshop zu bekommen. Ob und wieviel das kostet, 
muesste man erst nach dem Einreichen des Abstract und nach einem 
wohlwollenden Echo (kann ja auch als "Bullshit" abgeschmettert werden) 
mal feststellen.

Da es nicht das erste Mal ist, dass sich so ein Furz (entschuldigt mir 
die burschikose Sprache) zu einem echten Standardkommittee entwickelt, 
finde ich, wir sollten das wagen. Allerdings muss man echt aufpassen, 
dass einem die grossen Hersteller nicht in den Napf spucken und die 
guten Ideen absahnen.

Zudem ist die Zeit recht knapp:

    * Submission of abstracts: September 17, 2010
    * Notification of authors:    October 27, 2010
    * Final proceeding papers: January 12, 2011

Siehe auch:
http://www.embedded-world.eu/call-for-papers/abstr...

Bis dahin sollte man also etwas vorzuweisen haben...

Gruesse,

- Strubi

Autor: Rene B. (yob) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dies wäre der 1. Meilenstein ;).

VG, Rene

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Die Komplexitaeten von XML nach irgendwas zu konvertieren waeren damit
> so ziemlich "im Griff" - in obigem Fall ist es C-Code, Dokumentation,
> VHDL-Registertabellen, usw. Du erstellst also eine XML-Datei mit der
> Geraetebeschreibung, heraus kommt nach dem "make" eine Bibliothek, die
> auf Geraeteseite mit dem geraeteunabhaengigen Frontend (PC) ueber
> beliebige Interfaces kommuniziert und komplett mit der Hardware
> synchronisiert ist.

Seid Ihr sicher, dass XML gegenüber einer recht einfach gehaltenen 
Textdatei wirklich so große Vorteile bringt? Allein die Notwendigkeit, 
zusätzlich noch einen (meist fetten und langsamen) XML-Parser nutzen zu 
müssen, die nicht mehr wirklich gegebene Lesbarkeit in einem normalen 
Editor und der fehlende echte Mehrwert haben mich immer wieder von XML 
abgehalten.
Das Schlimmste ist aber, dass man mit Fehlern bei den Tags große 
Datenbereiche der Datei "korrumpieren" kann, was bei einfacher 
strukturierten Textdateien wesentlich unwahrscheinlicher ist.

Autor: Strubi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi Gastino,

Gastino G. schrieb:
> Seid Ihr sicher, dass XML gegenüber einer recht einfach gehaltenen
> Textdatei wirklich so große Vorteile bringt?

Ja :-)
Zumindest für das Prototyping von Formaten. Die taegliche Anwendung in 
einem Programm ist ne andere Sache.

> Allein die Notwendigkeit,
> zusätzlich noch einen (meist fetten und langsamen) XML-Parser nutzen zu
> müssen, die nicht mehr wirklich gegebene Lesbarkeit in einem normalen
> Editor und der fehlende echte Mehrwert haben mich immer wieder von XML
> abgehalten.

Du hast schon recht. Ich vermeide auch tendentiell die Verwendung von 
XML-Dialekten in Work-Dateien. Aber deren IFF-Format in XML beschreiben 
macht wiederum Sinn.
Wegen der Lesbarkeit: Du brauchst schon einen guten XML-Editor, der mit 
Schemas (xsd, oder kraenkeres :-) ) umgehen kann.

> Das Schlimmste ist aber, dass man mit Fehlern bei den Tags große
> Datenbereiche der Datei "korrumpieren" kann, was bei einfacher
> strukturierten Textdateien wesentlich unwahrscheinlicher ist.

Das passiert dir z.B. mit XXE (XMLMind XML Editor) nicht.
Hab mal eben nen Screenshot angetackert. Das Ding ist wirklich ne 
Meisterleistung, da alle Eingaben validiert werden, bzw. du nur das 
einfuegen kannst, was nach Schema-Beschreibung erlaubt ist, kannst Du 
als Autor kaum Mist bauen. Die ganzen Eingabemasken kannst du mit 
CSS-Stylesheets anpassen.

Fuer jedes andere objektorientierte Format muesstest du Parser, Handler 
und Translator schreiben, und das mit einem Mehraufwand (zumindest fuer 
mich, denn ich bin generell faul) gegenueber einem XSLT-Sheet. Es gaebe 
allerdings einen recht kranken Ansatz mit Python und dem pickle-Modul, 
aber das wuerde zu weit fuehren.

Der eigentliche Knackpunkt ist, dass das Format dauernd erweitert werden 
koennen muss, und sowohl abwaerts als auch aufwaertskompatibel bleibt.
Das ist ein ziemlicher gordischer Knoten, und mir ist sonst nur ein 
Binaerformat bekannt, welches das in etwa hinbekommt.

Gruss,

- Strubi

Autor: didadu (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, hier sind drei Listen der Inhalte der Felder "Value", "Device" und 
"Package" der exportierten BOMs aller .sch-Dateien (also von 
Schaltplänen), die hier auf MK als öffentliche Attachments gepostet 
wurden (ca. 470 Stück).

Nicht berücksichtigt wurden .sch-Dateien, die in ZIP-Archiven o.ä. 
gepostet wurden (einfach weil es ein Stück mehr Aufwand gewesen wäre). 
Es wäre interessant zu wissen, welchen Anteil der Projekte man deshalb 
nicht erfasst.

Diese Listen erstrecken sich also über einige Jahre und die 
verschiedensten Projekte.

Alle drei Listen sind sortiert nach Häufigkeit des Auftretens des 
jeweiligen Elements (die Häufigsten zuerst).

Ich hoffe, dass dies hilft, besser zu verstehen, mit was für Teilen wir 
hier so umgehen und was in einer Datenbank benötigt wird.

Autor: didadu (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier auch noch die "Descriptions".

Die geben eine stärker aggregierende Aussage über die verwendeten Teile.

Autor: didadu (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Da auch noch andere Analysen interessant sein können ("Welche Werte 
verwenden die Leute bei Bauteile im Package X"), für die mehrere Felder 
einer Zeile erforderlich sind, poste ich hier auch noch die Gesamtliste 
für Interessierte.

Nützliche commandline-Befehle zum schnellen Auswerten sind: cut, sort, 
uniq, grep, less und |

Das gibt dann Zeilen, die in etwa so aussehen:
cat All.txt | cut -f 3 | grep -v DIEWILLICHNICHT | sort | uniq -c | sort -n -r | less

Autor: Rene B. (yob) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nabend,

mir ist gerade Idee gekommen das man im Bezug auf Datenblätter eine 
Kooperation mit einer der großen Sammelmaschinen a la "Datasheetcatalog" 
oder "AllDataSheet" eingehen könnte. Gibt natürlich ein paar kleine 
Probleme wie Aktualität, Vollständigkeit + andere Erfahrungen. Im 
einfachsten Falle könnte man das aus der Datenbank ausgewählte 
Bauelement bei einer solchen Sammelmaschine über den Namen des Bauteils 
suchen lassen und dann die angezeigten Ergebnisse 3-4 Pdfs zur Auswahl 
stellen in dem diese direkt verlinkt sind. Sonst müsste man meiner 
Meinung nach Kooperationen mit den Herstellern selbst aufbauen um nicht 
wieder manuelle Aktualisierungen der Datenbank betreiben zu müssen.

---

VG, Rene

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Rene,

einen Link zum PDF mit aufzunehmen finde ich sowieso schon mal gut. Dass 
der dann ins Leere zeigt, wenn der Hersteller das PDF verschiebt, 
muesste man einfach mit einplanen. Weiss nicht, wieviel Kooperation mit 
den Herstellern das braucht, man muesste pro Hersteller ev. den link 
fuers http get generieren und nur eine Datenbank ID abspeichern. So hat 
man bei Aenderungen schnell alles wieder unter Kontrolle.
Kann man meiner Meinung auch alles spaeter mal verbessern. Die 
Datenblatt-Kraken sind, glaube ich, fast alle asiatisch...
Das Problem, ein Datenblatt schlussendlich aufzufinden, finde ich nicht 
so kritisch.

Gruesse,

- Strubi

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Dass der dann ins Leere zeigt, wenn der Hersteller das PDF verschiebt

Ich würde die PDF ja gleich herunterladen. Das sollte man eh bei jedem 
Teilekauf machen (die Daten sind Bestandteil des Produkts, ohne die es 
relativ wertlos ist), wenn man nicht später im Regen stehen will. Dann 
kann der Hersteller seine Dateien verschieben wie er lustig ist.

Bei einer Webdatenbank könnte es da rechtliche Zwangsjacken geben, aber 
wenn die DB lokal auf dem Rechner ist (ist sowieso zu empfehlen - im Web 
dann vielleicht ein Clearinghouse), dann geht das wohl.

Da es aber zahlreiche Datasheet-Kataloge gibt, sind die Hersteller 
vermutlich eher offen für die Weitergabe. Das spart ihnen ja 
Traffic-Kosten, und auch ihnen eine langfristige Pflege der 
Datenblattbereithaltung, wenn sie auf die Lieferung bestimmter Produkte 
keine Lust mehr haben (aka "nicht wirtschaftlich ist").

Autor: Bernd Wiebus (berndwiebus) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Martin, Gastino und Rene.

>> Beitrag #1726735:
>> Viel kleiner:
>> Was ich als erstes nützlich finden würde, wäre ein tool, das es erlaubt,
>> die Bauteile in unterschiedlichen .libs / .mods hin und her zu schieben
>> und umzuverteilen, sowie eine Möglichkeit, komplette Gruppen von
>> Symbolen umzubenennen, und zum Beispiel mit einem Versionssufix /
>> Datecodesufix zu versehen.

> Momentan loese ich das Versions-Problem per SVN (dafuer habe ich separat
> ein Repository fuer alle lokalen Libraries):

1) Das ist nicht nur so ein Versionsproblem, weil die NAMEN der Symbole 
in der Library selber enthalten sind, und zwar vier mal pro Symbol, plus 
einmal für die komplette Library. Gerade das ist ja das Problem, nur die 
Librarys anhand ihres Dateinamens zu trennen langt nicht.

2) Local könnte mir SVN natürlich weiterhelfen, aber was ist, wenn ich 
die Librarys weitergebe, und zwei unterschiedliche Revisionen z.B. B und 
C existieren, wo Symbole mit gleichem Namen, aber versetztem Ankerpunkt 
existieren? Wenn, in der Reihenfolge des einlesens, zuerst die falsche 
Library gewählt wird, "hüpfen" mir die Symbole oder Module durch die 
Gegend. Das Problem ist mir leider nicht unbekannt.


>
> Heisst, jeder Projektordner hat einen versionskontrollierten
> lib/-Unterordner. Das kicad so gut mit SVN funktioniert, macht es
> eigentlich echt unschlagbar fuer Gruppenarbeiten.
>
> Ich wuerde in so einem Fall auch nicht versuchen, eine eigene
> Versionskontrolle zu erfinden, sondern eher Schnittstellen zu SVN oder
> git in kicad einbauen, um die jetzige Handarbeit noch bequemer zu
> machen.
>

Schon Richtig. Ich habe seit gut einem Monat ein SVN Repository auf 
meinem Rechner, aber habe es zeitlich noch nicht hinbekommen, mich in 
SVN einzuarbeiten. Im Gegensatz zu Euch fehlen mir eigentlich alle 
Informatik Grundlagen, und ich muss mich dort erst einarbeiten. Ich bin 
einer der letzten, der noch mit einem Rechenschieber in Klausuren 
gegangen ist, und einen ausgemusterten XT habe ich dann 95 zu meiner 
Diplomarbeit geschenkt bekommen.....vorher hatte ich keinen PC (Nein, 
ich bin nicht aus der EX-DDR) und jetzt, im Alter, lernt es sich eben 
nicht mehr so schnell.

> Die Frage ist nur, ob man wirklich eine Versionskontrolle PER Baustein
> innerhalb der Library braucht. Hier wuerde ich eher sagen: Keep it
> simple, man legt sich einfach mehrere Libraries mit ev. denselben
> Objekten an, und schaut, dass man die Versionsnummern im Griff hat.

Richtig. Aber wie oben gesagt, es langt nicht, nur die Librarys 
umzubenennen. Aber es würde langen, an den Symbolnamen per Suffix einen 
Datecode anzupappen bzw. zu aktualisieren......aber dazu fehlt eben das 
handliche Tool.

Um Module aus verschiedenen Modulbibliotheken selektiert 
zusammenzufassen, wird vorgeschlagen, sie in ein Dummyboard einzufügen 
und abzuspeichern. KiCAD legt dann eine separate Modulbibliothek nur für 
das Board an, wo alles ausgewählte enthalten ist.
Siehe: http://tech.groups.yahoo.com/group/kicad-users/message/7612
(Nicht vom Titel irritieren lassen)
Das geht grundsätzlich mit Schaltplänen genauso. Es fehlt allerdings der 
Button, um das Schreiben der Cache Bibliothek zu erzwingen. Sie wird 
aber automatisch angelegt, wenn Du den Schaltplan schliesst.
Das ist ein halbwegs bequemer Workaround zur Erstellung einer 
individuellen "Buddy-library", aber nicht zum Umbenennen......


> Wo wir gerade beim Thema SVN sind: Habt ihr euch schon ueberlegt,
> einfach mal das Projekt auf dem hiesigen (mikrocontroller.net sei dank)
> SVN-Server zu starten? Wenns ausartet und manche User Mist committen,
> kann man's spaeter immer noch regeln :-)
> Gleichzeitig koennten diverse User dann auch noch ihre Tools und
> Hilfs-Scripte hochladen, und wir merken dann ev. so nach und nach, was
> das Projekt noch braucht.

Ich hatte eine Mail an Andreas losgeschickt, und er hat mir am Samstag 
auch geantwortet. Er fragt, ob das denn soviele Dateien sind, daß das 
nötig ist......ich werde das mit ihm wohl noch diskutieren müssen. Die 
KiCAD Dateien, die ich selber angelegt habe, Projekte, Bibliotheken, 
Dokumentation, Librarys (Symbole und Module), building Blocks sind hier 
bei mir etwas 1100 Dateien. Nach aufräumen werden wohl 500-600 
übrigbleiben, von denen 50-100 für die Gruppe hier relevant sind......

Das, was im Wiki liegt, ist meist schon komprimiert.......schau mal in 
das Modul Zip file, wieviele Einzeldateien schon darin sind.....und da 
fehlt leider noch meistens die Doku, genau wie für die Symbole.

Jedenfalls würde ich Andreas bitten, mindestens Rene und Dich mit auf 
die Liste zu setzten, weil ich vorläufig mit SVN überhaupt noch nicht 
wirklich umgehen kann. :O) Der Rest mit Bedarf möge sich melden......

Zu Gastino:
>>> Die Komplexitaeten von XML nach irgendwas zu konvertieren waeren damit
>>> so ziemlich "im Griff" - in obigem Fall ist es C-Code, Dokumentation,
>>> VHDL-Registertabellen, usw. Du erstellst also eine XML-Datei mit der
>> Geraetebeschreibung,~~~~~~~~~~~~~~
>> Seid Ihr sicher, dass XML gegenüber einer recht einfach gehaltenen
>> Textdatei wirklich so große Vorteile bringt? Allein ~~~~~~~~~Das
>> Schlimmste ist aber, dass man mit Fehlern bei den Tags große
>> Datenbereiche der Datei "korrumpieren" kann, was bei einfacher
>> strukturierten Textdateien wesentlich unwahrscheinlicher ist.
> Das passiert dir z.B. mit XXE (XMLMind XML Editor) nicht.
> Hab mal eben nen Screenshot angetackert. Das Ding ist wirklich ne
> Meisterleistung, da alle Eingaben validiert werden, bzw. du nur das
> einfuegen kannst, was nach Schema-Beschreibung erlaubt ist, kannst Du
> als Autor kaum Mist bauen. Die ganzen Eingabemasken kannst du mit
> CSS-Stylesheets anpassen.

Mmmmh. So rein aus meinem Bauch und meiner Erfahrung heraus würde ich
bei zwei sonst gleichwertigen Verfahren, bei denen eine 
"Sicherheitsfunktion" einmal inhärent im Dateiformat und einmal im tool, 
mit dem die Datei bearbeitet wird, liegt, ersteres vorziehen.
Persönlich würde ich auch ein Cabrillo-Style ähnliches Textformat 
vorziehen......aber das hängt vieleicht auch damit zusammen, das ich 
auch kein XML kann. Cabrillo ist nicht elegant, aber ungemein 
fehlertolerant.

Ich arbeite mich hier zur Zeit eben nicht nur in KiCAD ein, sondern auch 
in Latex (wegen der Doku) und in Gambas (primitivst mögliche 
Programiersprache für den angedachten Fall (Das Umbenenn-Tool) und unter 
Linux) ein. Das ich Fortran, C und Pascal gemacht habe, ist 20 Jahre 
her, und GFA-Basic sogar 25 Jahre. :-(
Das SVN habe ich darum auch erstmal schleifen lassen.......

Zu Rene:
>einen Link zum PDF mit aufzunehmen finde ich sowieso schon mal gut.

Richtig. Als Idee toll.......

> Dass der dann ins Leere zeigt, wenn der Hersteller das PDF verschiebt,
>muesste man einfach mit einplanen.

Dass ist schon eher ein Problem, weil das klappt bei mir schon mit 
Jabrev nicht, weil ich die Datenblätter am Dienstrechner unter Windows 
habe und privat unter Linux. Immerhin habe ich die Ordnerstruktur immer 
identisch, und weiss also sofort, wo ich nachsehen muss, wenn es unter 
dem einen Pfad nicht gefunden wird. :-) Allerdings kocht das Problem 
sofort hoch, wenn ich meine Ordnerstrucktur ändere. Jabrev kann nicht 
selbstständig Ordnerbäume durchsuchen....Dann gehe ich mit dem Beagle 
ran. Dienstlich geht das wiederum nicht.


> Weiss nicht, wieviel Kooperation mit
> den Herstellern das braucht, man muesste pro Hersteller ev. den link
> fuers http get generieren und nur eine Datenbank ID abspeichern.

Wenn Die kooperieren, dann nur zu ihren Bedingungen. D.h. Du arbeitest 
mit einem Hersteller zusammen, und kommst mit dem nächsten in 
Konflikt.....So aus dem Bauch heraus würde ich da für strikte 
Unabhängigkeit plädieren.

> Datenblatt-Kraken sind, glaube ich, fast alle asiatisch...
> Das Problem, ein Datenblatt schlussendlich aufzufinden, finde ich nicht
> so kritisch.

Oh doch. Speziell bei musealem Kram......:-) Einige Firmen versehen 
Datenblätter für obsolete Bauteile mit einem Stempel, andere geben Sie 
nur noch auf Anfrage heraus: "Ich bräuchte für ein Redesign.....gut wenn 
man einen Firmennamen im Rücken hat...."

Ich speichere Grundsätzlich jedes Datenblatt, das mir in die Finger 
kommt. So steht man auch in der Firma nicht dumm da, wenn gerade mal das 
Internet oder auch einfach das Firmeninterne Netzwerk nicht geht. Von 
meiner 8,5 Gb großen PDF-Sammlung sind 7,2Gb E-Technik relevant (Beim 
Rest ist immer noch Physik und Mathe enthalten). Davon sind 1,2 Gb 
Datenblätter und 500Mb Applikationsberichte. Würde ich gerne zur 
verfügung stellen, aber ich fürchte, da sind oft Copyrights drauf. Und 
das ist nicht einheitlich, darum sitzten die Datenblattkraken ja auch in 
Asien.....
Wenn also jemand freien Serverplatz, gute Jurakenntnisse und Spass an 
gerichtlichen Auseinandersetzungen hat, soll er sich melden.......O)

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde so eine Bauteileverwaltung wie schon beschrieben mit Python + 
sqlite3 + websercer + CGI machen.

Lerne mal Python, Bernd! Du wirst über die Klarheit der 
Programmiesprache überrascht sein, und wie schnell man sich damit 
Werkzeuge programmieren kann. Die Standard-Tutorials sind sehr gut, 
einfach mal ein bisschen einlesen. Auch wenn es vielleicht neu für Dich 
ist, ich kann es nur wärmstens empfehlen. Mit Hintergrund in C und 
Pascal sollte das ziemlich leicht sein.

Es ist für KiCad-Libs gut geeignet, weil das alles recht einfache 
Textfiles sind.

Mir fehlt momentan die Zeit, das zu programmieren, aber sehr schwer ist 
es nicht. Mit etwas Glück packt mich der Rappel und ich mache es 
trotzdem einfach mal...

Autor: didadu (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier ist ein Beispiel für die von mir vorgeschlagene Methode.

Das ist gemacht mit einem Ad-hoc-Webserver mit CGI von hier:
http://user.baden-online.de/~pjanssen/ad-hoc-serve...

Dafür habe ich dann mit Python ein einfaches CGI-Script erstellt, das 
man lokal (oder auch im LAN) über diesen Webserver aufrufen kann. Dieses 
Script scannt ein Basisverzeichnis mit KiCad-Libraries ab und listet 
alle Symbole auf, die in diesen Dateien definiert werden, erstellt eine 
Liste, usw. Dieses Ergebnis wird dann im Browser angezeigt.

Die Datei beispiel.html zeigt das Ergebnis.

Um dieses Methode zu verwenden:
- Python installieren (ist bei Linux meist schon vorhanden).
- serve-from-here_withcgi.py in ein Verzeichnis tun. Die Datei muss 
ausführbar gemacht werden.
- Unterverzeichnis "cgi" erstellen.
- Die Datei index.py in das gerade erstellten Verzeichnis "cgi" tun. Sie 
muss ausführbar gemacht werden.
- In der Datei index.py das Basisverzeichnis der Library-Dateien 
einstellen.
Damit ist die Installation abgeschlossen.
Aufruf:
- Die Datei serve-from-here_withcgi.py starten.
- Mit dem Browser den URL "localhost:8008/cgi/index.py" aufrufen.

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Bernd,

Bernd Wiebus schrieb:
> 2) Local könnte mir SVN natürlich weiterhelfen, aber was ist, wenn ich
> die Librarys weitergebe, und zwei unterschiedliche Revisionen z.B. B und
> C existieren, wo Symbole mit gleichem Namen, aber versetztem Ankerpunkt
> existieren? Wenn, in der Reihenfolge des einlesens, zuerst die falsche
> Library gewählt wird, "hüpfen" mir die Symbole oder Module durch die
> Gegend. Das Problem ist mir leider nicht unbekannt.

Ja, das ist garstig. Deswegen knuepfe ich jedes Projekt an eine 
bestimmte Revision der library fest. Ich vergass noch, in dem Zuge einen 
weitere Unschoenheit zu erwaehnen: Wenn man diese lokal aus SVN 
ausgecheckte fixe Revision ins Projekt einbinden will, traegt kicad in 
der .pro-Datei die absoluten Pfade ein. Ich habs bisher nur ueber 
Modifikationen mit dem Texteditor hinbekommen, relative Pfade zu 
benutzen.

Deswegen waere mein Vorschlag - auch wenn ein SVN-Repo fuer ein-zwei 
Files zunaechst unsinnig erscheint - gleich mit der ersten 
Prototypen-Version im SVN loszulegen.

In neue Tools einlernen ist zugegebenermassen garstig, koennte dir aber 
den "Tortoise SVN"-Client empfehlen, das macht die Sache einfacher. Da 
du bei SVN alles zurueckdrehen kannst, sehe ich auch kein Problem, 
einfach mal blindlings loszuschweinigeln, die Dateistruktur kann man 
spaeter verbessern.

Vielleicht kristallisiert sich dann auch besser heraus, wie man optimal 
mit verschiedenen Library-Revisionen arbeitet. Ich koennte mir 
vorstellen, dass sich einige Extensions hacken lassen, um wenigstens den 
Revision-Tag in die Library mit aufzunehmen, und eine Synchronisation 
mit dem Schematic/PCBdesign zu erzwingen oder Warnungen zu schmeissen.

Was du zum Thema Unabhaengigkeit von den Herstellern sagst, stimmt 
eigentlich komplett. Ich unterschreibe das mal.

Soweit dazu, muss mir nu mal euern weiteren Input erst reinziehen und 
verstehen.

Gruesse,

- Strubi

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das klingt sehr nach "dependency hell". Die wurde in Debian erst mit der 
Paketverwaltung gelöst, die die Abhängigkeiten selbstständig auflösen 
kann.

Wenn man die KiCad-Module hackt, um Symbol- (oder Library-)Revisionen 
zuzulassen, muss man auch in der Benutzeroberfläche die Möglichkeit 
haben, diese auszuwählen und zu ändern (falls die Revision nicht 
stimmt). Das klingt nach größerem Aufwand. Wenn ein Symbol neue 
Ansatzpunkte hat, müssen die auch neu "verschaltet" werden. Sonst könnte 
es ganze fiese Fehler mit vertauschten Anschlüssen geben, die aber nicht 
ohne weiteres bemerkt werden...

Was relativ einfach ginge, wäre eine Aufnahme einer Revisionsnummer als 
Kommentarzeile in den Libraries. Das stört KiCad nicht, aber man kann 
dann damit arbeiten, indem man sich Listen erstellen lässt, die kann man 
dann mit seiner Datenbank abgleichen und ggf. Abweichungen, die 
Aufmerksamkeit brauchen, anzeigen lassen.

Autor: Bernd Wiebus (berndwiebus) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo didadu.

> So, hier sind drei Listen der Inhalte der Felder "Value", "Device" und
> "Package" der exportierten BOMs aller .sch-Dateien (also von
> Schaltplänen), die hier auf MK als öffentliche Attachments gepostet
> wurden (ca. 470 Stück).

Zu Devices.text: An erster Stelle steht R-EU_0207/10. Standard 
Widerstand im 10mm Raster. Throuhole ist hier immer wohl noch das 
gängigste. An zweiter Stelle steht LED5mm . Das sind die ganzen Uhren 
mit den vielen LEDs. :O) Dann an vierter Stelle R-EU_R0805. SMD ist also 
auch im Selbstbau gut im kommen.  An fünfter Stelle "Device" und an 
sechster Stelle nur Leerzeichen, was zeigt, das die Leute bei Erstellung 
eigener Devices nicht besonders phantasievoll in der Namensgebung sind. 
:O)

> Lerne mal Python, Bernd! Du wirst über die Klarheit der
> Programmiesprache überrascht sein, und wie schnell man sich damit
> Werkzeuge programmieren kann. Die Standard-Tutorials sind sehr gut,
> einfach mal ein bisschen einlesen. Auch wenn es vielleicht neu für Dich
> ist, ich kann es nur wärmstens empfehlen. Mit Hintergrund in C und
> Pascal sollte das ziemlich leicht sein.

Bevor ich mich Gambas zuwendete, habe ich mich an Python 
versucht.....mein Problem bin ich selber, und das ich bei 
Objektorientierung einfach an der Grenze meiner Intelligenz bin. :-(
Dummerweise verstehe ich weniger als ein viertel Eurer Diskussion über 
Datenbanken. Ich habe da schlichtweg kein bisschen Ahnung von.
Und ich habe oft das Gefühl, hier an den anderen Diskussionsteilnehmern 
vorbeizureden und zu verstehen.

> Hier ist ein Beispiel für die von mir vorgeschlagene Methode.
> Das ist gemacht mit einem Ad-hoc-Webserver mit CGI von hier:
> http://user.baden-online.de/~pjanssen/ad-hoc-serve...
> Dafür habe ich dann mit Python ein einfaches CGI-Script erstellt, das
> man lokal (oder auch im LAN) über diesen Webserver aufrufen kann.
> ~~~~~~~~~~

HERZLICHEN DANK! Ich habe das Python Package noch von meinen eigenen 
Python versuchen stehen.....
Ich fürchte aber, ich werde erst am nächsten WE dazu kommen. Und vorher 
muss ich mich erkundigen was CGI ist......:-( Ich bin zimlich aus der 
Zeit gefallen denke ich.


> Wenn man die KiCad-Module hackt, um Symbol- (oder Library-)Revisionen
> zuzulassen, muss man auch in der Benutzeroberfläche die Möglichkeit
> haben, diese auszuwählen und zu ändern (falls die Revision nicht
> stimmt).

Das kann man. In der tat. Oben unter "Einstellungem", und dann 
"Bibliotheken". In älteren Versionen hies es noch "Extras", und dann 
"Bibliotheken und Pfade".
Allerdings wählt KiCAD und Symbole und Module nach SYMBOL-NAMEN und 
MODUL-NAMEN aus den angegebenen Librarys in den angegebenen Pfaden aus.

Hat man mehr als eine Library, und befinden sich dort in 
unterschiedlichen Librarys Symbole oder Module mit gleichem NAMEN, so 
wird das erste gefundene benutzt.

Das ist eigentlich kein Problem, wenn man die Librarys immer passend
an das Projekt bindet. Was übrigens automatisch nach Auswahl einer 
Library passiert.

Es wird aber zum Problem, wenn man an einer Schaltung arbeitet, mit 
schon gewählter Library, und dann als hierarchischen Unterschaltplan 
einen
externen Schaltplan einbindet, und auch dessen -cache.lib verwendet.
Enthält diese Library nun ein Symbol oder Modul mit gleichem NAMEN wie
in den verwendeten Librarys das aus einer anderen Version stammt, hängt 
es vom NAMEN der Librarydatei ab, welche in alphabetischer Reihenfolge 
zuerst dran sind unf folglich verwendet werden. Wollte man die 
-cache.lib nicht verwenden, hat man u.U. nicht alle Symbole oder Module 
parat.


> Was relativ einfach ginge, wäre eine Aufnahme einer Revisionsnummer als
> Kommentarzeile in den Libraries. Das stört KiCad nicht, aber man kann
> dann damit arbeiten, indem man sich Listen erstellen lässt, die kann man
> dann mit seiner Datenbank abgleichen und ggf. Abweichungen, die
> Aufmerksamkeit brauchen, anzeigen lassen.

Es ist weniger sinnvoll, die Versionsbezeichnung, oder einen Datecode in 
einen Kommentar zu schreiben, als in den Namen des SYMBOLS oder MODULES!
Weil im NAMEN KANN KiCAD das auswerten, und dann entsteht das Problem 
nicht. ;-) Im obigen Falle häette dann das Symbol/Modul den Suffix 
"RevG5" oder "16042010" als aktuellen Datecode. In der -cache.lib oder 
der Projekt.mod stände der gleiche Name mit anderem Suffix "RevF3" oder 
Datecode "25022009".

Es gibt mit Sicherheit smartere Lösungen, aber der Momentane 
Entwicklungsstand von KiCAD legt diese Vorgehensweise nahe.

Mit freundlichem Gruß: Bernd wiebus alias dl1eic

http://www.dl0dg.de

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> was CGI ist

CGI heißt "Common Gateway Interface" und bezeichnet eine Methode, wie 
Daten, die vom Webbrowser an den Webserver geliefert werden, vom 
Webserver an eigene Programme weitergegeben werden -- und zurück --, 
sodass die eigenen Programme letztlich, vermittelt durch den Webserver, 
mit dem Webbrowser kommunizieren können.

Anders gesagt, wenn ich am Webbrowser klicke, soll mein Programm die 
Daten bekommen, und wenn mein Programm "print" sagt, soll es im Browser 
angezeigt werden.

Wegen der Objektorientierung würde ich mir auch keine großen Gedanken 
machen. Einfach mal in die Software reinschauen, vieles dürfte dann 
schon mehr oder weniger intuitiv einleuchten.

---

Das Seltsame ist, dass ich selbst bisher kaum mit KiCad gearbeitet habe, 
weil Eagle halt etwas bequemer ist und eine etwas flachere Lernkurve zu 
haben scheint. Warum mache ich also hier mit? Weil ich grundsätzlich 
freie Software besser finde und eigentlich lieber benutzen möchte.

Eine Hürde für mich war, dass ich die Symbole nicht fand. Die zweite war 
die Sache mit der nachträglichen Package-Auswahl und -Zuordnung, das war 
mir irgendwie zu unflüssig (dazu kommt aber auch, dass ich lange kaum 
mit Elektronik gearbeitet habe, und das Feld hat sich doch verändert). 
Und was ist überhaupt "back-annotation"? Die dritte Hürde war mangelnde 
Erfahrung mit dem Layouten überhaupt.

Nun kenne ich aber schon etwas Eagle, also ist die Hürde 3 schon fast 
genommen. Allerdings kann ich auch mit Eagle nicht wirklich flüssig 
arbeiten... So gesehen nähert sich das an. Problem 2 ist in Eagle gut 
gelöst: Umschalten auf 1 Klick, hin und her. Bequemer geht's nicht. Da 
lässt KiCad zu wünschen übrig. Und Problem 1 habe ich mit Eagle auch. 
Also auch hier: Annäherung.
Ich muss mir das Programm wohl mal wieder anschauen. Möglicherweise 
zeigen sich dann noch weitere Probleme... Vielleicht mit dem Drucken? 
Na, ich werd's ja sehen.
Kann man KiCad eigentlich scripten? Gibt's eine API für 
KiCad-Funktionen, z.B. mit Python-Bindings?

Ein weiterer Punkt ist aber auch: Wie könnte man mehr User zu KiCad 
kriegen? Je mehr es sind, desto eher werden auch Probleme gelöst, 
Tutorials geschrieben usw. Ideen dafür:
- Die genannten Probleme lösen.
- Manche Dinge so gut machen, dass sie schon in sich ein Zugpferd sind. 
(Ideen dafür?)
- Mehr große und attraktive Platinen entwickeln und hier reinstellen, 
damit die Leute KiCad nehmen, um sie nachbauen und verändern zu können.
- Einen Leitfaden erstellen: "KiCad für Eagle-Nutzer", so nach dem 
Prinzip "Linux für Umsteiger von Windows", der die Äquivalenzen und 
Workarounds für die Unterschiede nennt.
- Eine Liste der jeweiligen Vorteile und Nachteile der Softwares 
erstellen. Nicht ideologisch, sondern rein pragmatisch geschrieben.
- Sämtliche Eagle- (und andere) Schaltpläne dieser Website umwandeln in 
KiCad und eine tolle indizierte Sammlung mit Index und Bildern anlegen, 
die NUR die KiCad-Versionen zeigt.
- Import-Funktion für Eagle2KiCad in KiCad bauen. Oder zumindest einen 
Export aus Eagle mit einem Eagle2KiCad.ulp, um den Umstieg zu 
erleichtern.
- Werbung machen mit einer benutzerfreundlichen, modernen Website.

Autor: Martin S. (strubi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Bernd Wiebus schrieb:
> Es ist weniger sinnvoll, die Versionsbezeichnung, oder einen Datecode in
> einen Kommentar zu schreiben, als in den Namen des SYMBOLS oder MODULES!
> Weil im NAMEN KANN KiCAD das auswerten, und dann entsteht das Problem
> nicht. ;-) Im obigen Falle häette dann das Symbol/Modul den Suffix
> "RevG5" oder "16042010" als aktuellen Datecode. In der -cache.lib oder
> der Projekt.mod stände der gleiche Name mit anderem Suffix "RevF3" oder
> Datecode "25022009".

Lass mich es mal anders formulieren: Zum eindeutigen identifizieren des 
Moduls brauchen wir einen weiteren "key" (da kuerzer als "schluessel" 
nehme ich mal die englische Version).
In der Datenbank (bzw dem Satz aus Lib-Files) duerften dann durchaus 
mehrere Komponenten mit dem gleichen Namen vorkommen, aber Name und 
Revision macht die Komponenteninstanz eindeutig.

Im EESchema kann man ja bereits einen Fields-Eintrag pro Symbol mit 
einer Revisions-Nummer versehen. Diese Revisionsnummer muss zum Symbol 
passen, sonst Warnung. Problem: Es gibt momentan keine Felder per 
Komponentendefinition fuer einen $Rev:$-SVN-Tag (zur Erlaeuterung: Wenn 
entsprechend per svn:keywords konfiguriert, traegt SVN in Textfiles mit 
einem solchen $Rev:$-Tag während des "svn commit" die Revision ein, also 
steht da dann z.B.: "$Rev: 42 $")
Das einfach in eine extra Text-Definition einzutragen, klappt ansich 
(siehe attachte chip.lib), aber die $Rev: $ wird im EEschema/Lib editor 
nicht richtig angezeigt (zumindest in meiner Version). Und anzeigen 
wollen wir es schlussendlich wohl auch nicht.

Was nu also in kicad fehlt, waere eine vernuenftige Erweiterung, am 
besten generisch formuliert, d.h. die Moeglichkeit fuer den User, einen 
weiteren "key" zum Auffinden von Symbolen in den Libraries 
hinzuzufuegen.
So, und wer programmiert uns das in kicad rein?

Zu didadu:
habe mal dein Script ausprobiert, funktioniert 1a. Du hast Dir damit den 
Schuh mit dem Parser fast schon angezogen :-)
Die Datenbank bekaemen wir also wohl irgendwie gefuellt - und fuer's 
erste Fuellen ist es wohl zunaechst wirklich besser, eine gut designte 
Kicad-Lib in was auch immer zu uebersetzen.

Habe nur noch ueber einen Aspekt sinniert: Der Gag an einem Online-Tool 
a la Kicad Component Builder ist ja, dass die erstellten Rohdaten gleich 
in eine Datenbank gespeichert werden koennten. Ein User, der sich 
Library-Daten runterlaedt und lokal verbessert, aber nicht wieder 
hochlaedt (ja, auch ich bin oft so faul), dient der Gemeinschaft nicht 
unbedingt. Das schreit also fuer das weitere Unterhalten und Auffuellen 
der Datenbank nach einem Online-Tool...

Habe leider keine Emailadresse von dem Autor des KiCoBu, sonst haette 
ich den schon mal gepiesackt, was er von einer Erweiterung haelt, oder 
ob er den Source rausgibt.

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Schuh mit dem Parser

Naja, der "Parser" ist bisher kaum mehr als ein "grep DEF" in 
Python-Form.
Der nächste Schritt wäre das Herstellen von Grafiken, um auch mal was zu 
sehen. Ansonsten das Einlesen in eine DB. (Aber dann geht's los mit der 
Verwalterei, vor allem beim Neueinlesen, bei Updates usw., da muss man 
dann alles immer wieder vergleichen und mit Konflikten umgehen.)

Martin S. schrieb:
> Kicad Component Builder

Vielleicht will er gerne selbst die Daten sammeln... (und für sich 
behalten? so wie google und so viele andere klautsourcer).
Man kann ja höflich anfragen.
Vielleicht steuert er ja die Bibliotheken zu so einem Projekt bei. (Wer 
weiß, vielleicht liest er hier mit.)

Dieser Builder baut anscheinend hauptsächlich ICs. Aber was ist mit den 
anderen Komponenten? Gerade da ist die Arbeit des Selbststrickens ja 
nerviger. Und mit "Componenten" meint er wohl auch nur "Symbole", nicht 
Footprints. Eine Sammlung aller Footprints wäre auch nicht schlecht. 
Aber die sind nicht in den .lib drinnen, die auf der Website generiert 
werden (wohl nur als Default-Footprint referenziert).
Dieser Symbol-Builder ist somit nicht sehr schwer nachzubauen, denke 
ich. Und man kann es besser machen. Dann könnte man mehr Zulauf kriegen 
... um die Daten zu sammeln.
Fairerweise könnte man ein Klickfeld vorsehen -- standardmäßig markiert 
-- das sagt: "Symbol in öffentliche Bibliothek aufnehmen". (Oder die 
Nutzungsbedingungen des besseren Builders ausdrücklich in diesem Sinne 
ankündigen.)

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> leider keine Emailadresse von dem Autor des KiCoBu
Tipp: whois => http://www.pagesjaunes.fr/ (Name, Vorname, Ort) => 
Anrufen

Autor: didadu (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal weiter am Parsen gearbeitet. (Die beiden Scripts müssen 
BEIDE in das "cgi"-Verzeichnis (s.o.) getan werden.)

Nun erscheinen beim Scannen der Libraries zusätzlich solche Infos:
======================================== EESchema-LIBRARY Version 2.3 Date: 4/5/2007-07:37:04
Device: LM339 (Units: 4)
Aliase: ['LM139', 'LM239', 'LM2901', 'LM3302']
Polyline (4 points): (-200,200) (200,0) (-200,-200) (-200,200)
Pin 3: V+ (Power In), unit 0 (-100,400)
Pin 13: ~ (Output), unit 4 (500,0)
Pin 2: ~ (Output), unit 1 (500,0)
Pin 1: ~ (Output), unit 2 (500,0)
Pin 14: ~ (Output), unit 3 (500,0)
Pin 10: - (Input), unit 4 (-500,-100)
Pin 4: - (Input), unit 1 (-500,-100)
Pin 6: - (Input), unit 2 (-500,-100)
Pin 8: - (Input), unit 3 (-500,-100)
Pin 9: + (Input), unit 3 (-500,100)
Pin 11: + (Input), unit 4 (-500,100)
Pin 5: + (Input), unit 1 (-500,100)
Pin 7: + (Input), unit 2 (-500,100)
Pin 12: GND (Power In), unit 0 (-100,-400)
----------------------------------------
================================================================================

Bei mir tauchen bei einigen Bibliotheken ein paar Fehler auf, die kann 
man auf der Ausgabeseite schnell mit "***" finden.

Neu ist dabei übrigens die Ausgabe der ALIAS-e, die in den Libs 
definiert sind.

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
didadu schrieb:
> Neu ist dabei
außerdem auch die Ausgabe der (ggf.) definierten Footprints.

Footprints: ['SO16E', 'SO16N', '16DIP300', '16DIP-ELL300', 'SOJ28_WIDE', 
'28dip300', 'CP*', 'SM*', 'R?', 'SM0603', 'SM0805', 'C?', 'SM*', 'R?', 
'SM0603', 'SM0805']

Autor: didadu (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier eine verbesserte Version des Library-Parsers. Die Fehler treten 
nicht mehr auf. Er scannt jetzt alle meine Libs, auch die umfangreiche 
neue SymbolsSimilarEN60617+oldDIN617-RevD3-en.lib "AKTUELLE Version!" 
von hier http://www.mikrocontroller.net/articles/KiCAD#Bibliotheken

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir fällt beim durchgehen der Ergebnisse auf, dass in der Bibliothek 
SymbolsSimilarEN60617+oldDIN617-RevD3-en.lib die T-Zeilen nicht der 
Beschreibung auf der
Seite 
http://en.wikibooks.org/wiki/Kicad/file_formats#T_...
entsprechen. Dort steht als Definition:

T direction posx posy text_size text_type unit convert text
* direction = Direction of text(0=Horizintal, 900=Vertical(default))
* text_size = Size of the text
* text_type = ???
* text = Text to be displayed. All ~ characters are replaced with 
spaces.

In der Lib treten aber mehr Felder auf, und zwar NACH dem Feld "text", 
das nach der Beschreibung das letzte sein sollte, z.B.:

T 0 800 450 60 0 0 0 AC Normal 0 C C

Stimmt die Lib nicht, oder ist die Beschreibung unvollständig?
Wo gibt es eine richtige Beschreibung? Mit welchem Tool wurde die Lib 
erstellt?

Dazu fällt mir ein, dass ein validierender Parser vielleicht nützlich 
wäre. Dazu braucht man aber eine definitive Definition der Formate. (Und 
die gibt's vermutlich direkt oder indirekt auf dem KiCad SVN.)

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Libraries auf Launchpad:
https://code.launchpad.net/~kicad-lib-committers/k...

"How can I contribute custom footprints to the project?" =>
https://answers.launchpad.net/kicad/+question/106798

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier gibt's auch Symbole, einfach mal eine Rubrik anklicken:
http://ftp.sunet.se/geda/tools/symbols/library/index.html
Schön gemacht! Sowieso sind bei dem Programm schon zahlreiche Symbole 
und Footprints dabei, und auch kategorisiert.

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und hier sind noch ein paar mehr Programme, die vielleicht auch 
konvertierbare Symbole haben:
http://en.wikipedia.org/wiki/Wikipedia:WikiProject...

Autor: Rene B. (yob) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Bernd Wiebus schrieb:
>> Es ist weniger sinnvoll, die Versionsbezeichnung, oder einen Datecode in
>> einen Kommentar zu schreiben, als in den Namen des SYMBOLS oder MODULES!
>> Weil im NAMEN KANN KiCAD das auswerten, und dann entsteht das Problem
>> nicht. ;-) Im obigen Falle häette dann das Symbol/Modul den Suffix
>> "RevG5" oder "16042010" als aktuellen Datecode. In der -cache.lib oder
>> der Projekt.mod stände der gleiche Name mit anderem Suffix "RevF3" oder
>> Datecode "25022009".

> Im EESchema kann man ja bereits einen Fields-Eintrag pro Symbol mit
> einer Revisions-Nummer versehen. Diese Revisionsnummer muss zum Symbol
> passen, sonst Warnung. Problem: Es gibt momentan keine Felder per
> Komponentendefinition fuer einen $Rev:$-SVN-Tag (zur Erlaeuterung: Wenn
> entsprechend per svn:keywords konfiguriert, traegt SVN in Textfiles mit
> einem solchen $Rev:$-Tag während des "svn commit" die Revision ein, also
> steht da dann z.B.: "$Rev: 42 $")
> Das einfach in eine extra Text-Definition einzutragen, klappt ansich
> (siehe attachte chip.lib), aber die $Rev: $ wird im EEschema/Lib editor
> nicht richtig angezeigt (zumindest in meiner Version). Und anzeigen
> wollen wir es schlussendlich wohl auch nicht.
>
> Was nu also in kicad fehlt, waere eine vernuenftige Erweiterung, am
> besten generisch formuliert, d.h. die Moeglichkeit fuer den User, einen
> weiteren "key" zum Auffinden von Symbolen in den Libraries
> hinzuzufuegen.

Jap,Kann ich nur zustimmen ! Sehr schöne Idee mit dem SVN-Tag.

> So, und wer programmiert uns das in kicad rein?

Hm, ich. Nicht ganz ;). Ich habe eine andere Idee die mir schneller 
durch den Kopf geschossen ist beim lesen deiner ersten Zeilen. Achtung, 
ich hol mal aus.

Autor: Rene B. (yob) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Abend,

Ich habe eine Frage zur Realisierbarkeit mit Python. @didadu 
(Python-Crack ^^) und alle anderen auch ;-). PS: installiert ist es aber 
noch nie benutzt :)!

Grundidee: (noch nicht ausgereift !!!, irgendwas hab ich bestimmt noch 
nicht bedacht)

(Manuell) svn:keywords im ersten Ordner des SVN-Projekarchives 
definieren (rekursiv natürlich). Somit kann man bei allen Dateien die 
Revisionsnummer, Autor, Datum usw. abfragen.

Python-Script vor dem 1. Übertragen (nicht das aller allererste 
zwingend)  zum SVN-Projektarchiv:
------------------------------------------------------------------------ 
-----------------------------------------------------------

>>>1.Schritt einfügen/ersetzen der Standard-SVN-Tags

#
# CPC1017N $Id$ <---
#
DEF CPC1017N U 0 0 Y Y 1 F N
F0 "U" 0 350 60 H V C CNN
F1 "CPC1017N" 0 -357 60 H V C CNN
DRAW

-----

EESchema-DOCLIB  Version 2.0  Date: 04/03/2010 11:31:51
#
$CMP CPC1017N
D opto mos $Id$ <---
K SWITCH OPTO
F opto/cpc1017n.pdf
$ENDCMP
#

>>>2.Schritt die Dateien per Kommandozeile auf das SVN Projektarchiv übertragen
-> dadurch werden die Tags mit Informationen gefüllt/ersetzt, wie ihr 
wollt :-)!

>>>3.Schritt die Dateien vom SVN Projektarchiv wieder  auschecken zum auslesen der 
SVN-Taginformationen
-> Taginformationen in den Dateien enthalten.

-----

$Tag: dateiname Revisionsnummer Datum Uhrzeit Autor $

-----

#
# CPC1017N $Id: analog_switches.lib 13 2010-06-02 15:00:52Z PC-Username 
$ <--- hier stört es Kicad überhaupt nicht! (reine Praxisbestätigung ;) 
)
#
DEF CPC1017N U 0 0 Y Y 1 F N
F0 "U" 0 350 60 H V C CNN
F1 "CPC1017N" 0 -357 60 H V C CNN
DRAW

-----

EESchema-DOCLIB  Version 2.0  Date: 04/03/2010 11:31:51
#
$CMP CPC1017N
D opto mos $Id: analog_switches.dcm 13 2010-06-02 15:00:52Z PC-Username 
$ <--- (ebenso)
K SWITCH OPTO
F opto/cpc1017n.pdf
$ENDCMP
#

------

>>>4.Schritt Dateien erneut einlesen (Dateinamen merken!) und SVN-Taginformation 
auslesen

>>>5.Schritt ausgelesene SVN-Taginformation als Suffix in dazugehörigen Dateinamen 
schreiben

>>>6.Dateien zum SVN-Projektarchiv übertragen

>>>7.Fertig :-))

Beim übertragen könnte man für die genauen vielleicht auch noch die 
Revisierung beachten damit diese nicht so schnell in die Höhe schießt.

Immer wenn man fertig ist mit dem Bearbeiten Kicad-libs führt man das 
Python-Script aus und die Magie nimmt ihren lauf und man hat am Ende auf 
dem SVN-Server (oder im Projektarchiv, offline) sowie im aktuellen 
Arbeitsordner seine Kicad-libs mit zusätzlichen Revisionsinformationen 
in den Dateien und im  Dateinamen.
Zudem erscheint die veränderte Description in Kicad in der Unteren 
Statuszeile im Bibliothekseditor, Shematic & Layout beim anklicken das 
jeweiligen Symbols.

Dieses Script könnte man bestimmt mit dem Analyse Script so kombinieren 
das man 2 Fliegen mit einer Klappe schlägt. Sammeln und richtiges 
Revisieren.

Tests:
-----
Die .lib & .dcm Dateien werden immer zur selben Zeit erstellt, außer man 
editiert selbst mit einem Editor in den Dateien. Die Informationen 
bleiben bei Bearbeitung der Dateien & erneutem abspeichern erhalten.

Damit umgeht man Kicad  ansich zwar ganz schön aber es würde die 
Problemstellung der direkten Revisierung und Benennung von Kicad-Dateien 
oder auch zukünftigen anderen Dateien lösen.

So nun dürft ihr meckern und Einwände bringen oder Probs aufzeigen. 
Tipps wären auch gut ;).


---
VG, Rene

Autor: Rene B. (yob) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch ein Bild mit veränderter Description in Kicad.

---
VG, Rene

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es geht auch noch ein weiteren Hack, der aber nicht richtig 
funktioniert. Du editierst mit einem Texteditor die F1-Zeile:
DEF CHIP U 0 40 Y Y 1 F N
F0 "U" 0 0 60 H V C CNN
F1 "CHIP_$Rev: 5 $" 0 300 60 H V C CNN

Damit kannst du explizit die Revision im Namen verankern. Das geht auch 
beim ersten Mal Laden, dann wird leider intern in der cache.lib der Text 
aus der F1-Zeile, also "CHIP_$Rev: 5 $" in die DEF-Zeile uebernommen, 
und der Parser motzt, da er die DEF nicht richtig einlesen kann, da dort 
die Anfuehrungszeichen fehlen und der Rev-Schlonz wie mehrere Argumente 
erscheinen. Das passiert auch beim Editieren mit dem Library-Editor, 
dann ist das Bauteil ploetzlich weg aus der Auswahl-Liste (wegen obigem 
Parserproblem).

Diese Art Versionstagging per Lib-Datei hat ein echtes Minus: Bei jeder 
Aenderung einer Komponente in der Lib muss man alle anderen Symbole die 
derart "hart" codiert (mit Name-Rev-Schluessel) sind, im Schematic 
nachfuehren, auch wenn sie sich gar nicht geaendert haben. Das ist echt 
Kaese.

Abgesehen davon, dass es nicht richtig tut, finde ich es deswegen immer 
noch einfacher, eine lokale Kopie der Library im Projektverzeichnis zu 
unterhalten. Wobei mir allerdings die Uebersicht, welche Komponenten 
geaendert wurden, verloren gehen kann, und ich mit svn diff alles 
ueberpruefen muss, wenn ich eine aktualisierte lib ("svn up") in einem 
anderen Projekt nachfuehren will.

Wenn man das also sauber mit SVN machen wollte, muesste jedes Symbol in 
ein einzelnes File, damit man pro Symbol eine Revisionsnummer kriegt.

Oder man kriegt kicad dazu, mit einem internen "diff" festzustellen, 
welches Symbol sich geaendert hat, und die zur Library zugehoerigen 
Revision-IDs werden automatisch fuer die unveraenderten Symbole 
synchronisiert. Bei den anderen heissts: Bitte updaten, wurde geaendert.

Ich muss zugeben, ich schmeisse erst mal den Bettel vor solchen 
Revisionierungsfragen, das ist mir auf der Ebene zu komplex, deswegen 
eben auch der Gedanke, das von einer Datenbankseite (kicad-unabhaengig) 
aus mal aufzuziehen.

Oder die Frage mal den kicad-Entwicklern vorlegen.

Vielleicht muessten wir diese SVN-Tricks auch mal gesammelt 
dokumentieren (auf englisch).

Gruesse,

- Strubi

Autor: Yob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wenn man das also sauber mit SVN machen wollte, muesste jedes Symbol in
>ein einzelnes File, damit man pro Symbol eine Revisionsnummer kriegt.

Davon bin ich ausgegangen. Nach meinem Kenntnissstand werden fast alle 
Bibliotheken so in der Entwicklung gehandhabt um eine maximale 
Flexibilität zu erzielen. Größere Teilbiliotheken wie es zum Beispiel 
Bernd hier im Forum einstellt sind komplett Bibliotheken mit einer 
festen Versionsnummer (tag).
Ich würde die einzelnen Datei ebnso wieder per Script und entsprechnder 
Ordnerstruckter im SVN-Projektarchiv automatisert erstellen lassen.

Bei der ~Cache.lib im jeweiligen Projekt sehe ich das genauso. Diese 
bildet einen festen Stand des Projektes wieder. Eine Veränderung am 
Projekt ist eine Instandhaltung/Wartung. Zudem ist hierbei auch immer 
ein Nutzereingriff erforderlich, sei nur die Prüfung auf Richtigkeit.

Das Kicad mit ~Cach.lib arbeitet und die Informationen nicht direkt im 
.sch speichert sondern wieder comp einfügt ist ansich mist. Somit wirds 
nur komplizierter.

---
VG, Rene

Autor: Yob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Datenbankseite (kicad-unabhaengig)

Hm, ich würde eher eine Datenbank aufsetzen welcher per SVN oder andere 
Quele mit einer festen Bibliotheksversion geüllt wird. Diese an Kicad 
angubunden als Ersatz für ~cache.lib. Dazu eine entsprechende Anpassung 
in Kicad so dass man unabhängig vom Projekt oder Schaltplan usw. auf 
alle Symbole und Footprints zugreifen kann und somit Konflikte durch 
manuelles hin- & herkopieren vermeidet. Zudem könntet ihr man die Ideen 
der Key-erweiterung zu den .libs einbauen. Das wäre ein echt guter 
Mehrwert.
Später könnte ma die editoren vieleicht von Kicâd loslösen und auf einer 
Website einbinden für weitere Aquisen.

Eine unabhängigkeit von Kicad ist ansich natürlich perfekt für die 
Marktplatziereung. Mir ist momentan nicht bekannt wo eine solche 
Datenbank ebenso sehr nützliche wäre,  nach dem Motto es reicht so wie 
es ist aufgrund der längeren Entwicklungszeiten der auf dem Markt 
verfügbaren CAD-Produkte.

Ich gebe dir Recht wir sollten mal einpaar Sachen in ein Dokument 
bannen.

---
VG, Rene

Autor: puffel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es eigentlich außer diesem Thread eine Art Homepage, wo Bernd's 
Projekt etwas detaillierter beschrieben ist bzw. wo die ganzen Infos, 
Quellen und Diskussionen verfügbar sind?

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Damit der Thread nicht ganz einschlaeft:

Ich versuche grade in Zeit, die neben dem "serioesen" Arbeiten bleibt, 
mich ein bisschen in diverse Frameworks einzuspielen, die 
Datenbank/Userverwaltung usw. vereinfachen.
Herrn Rohrbacher, der den kicad library component builder geschrieben 
hat, habe ich kontaktiert. Vielleicht liest er hier auch mal mit.
Wenn sich jemand hier gut mit typo3, Zope, oder sonstigen CMS, die man 
leicht um Lagerverwaltungen erweitern kann, auskennt, soll er sich doch 
melden. Ich bin ansich fuer den Job nicht der Richtige, versuche nur 
gerade mit geringstem Widerstand und hoffentlich groesstmoeglicher 
Amortisation was zum Laufen zu kriegen.

Wie ist denn der Status mit dem SVN?
Apropos, ich hab noch etwas Doku zum SVN hochgeladen, bisher allerdings 
nur im englischen Wiki:

http://kicad.sourceforge.net/wiki/index.php/Versio...

Vielleicht sollten wir die Diskussion auch auf den Wiki verlagern und 
unsere gesammelte Expertise dort manifestieren.

Gruesse,

- Strubi

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ob Andreas Lust hat, auf dem MK.net-Server eine Datenbank-API für sowas 
einzurichten, mit der User-Programme zur Bibliothekenverwaltung 
kommunizieren können?

Das müsste nicht sehr umfangreich sein, es reicht ja, wenn man sie nach 
Teilen durchsuchen ('SELECT name FROM bauteile WHERE name LIKE 
"%suchbegriff%" AND type = "KiCad"'), abrufen ('SELECT libdata FROM 
bauteile WHERE name = "<name>" AND type = "KiCad"') und Teile hochladen 
('INSERT INTO bauteile VALUES name, libdata') kann. Wenn das dann direkt 
den Text als Text ausgibt, reicht es für User der Webschnittstelle, und 
die Tools können auch recht einfach damit arbeiten. Der Traffic bleibt 
damit vielleicht auch überschaubar.

Dann können wir Scripte machen, die für die Synchronisation der eigenen 
neuen Teile mit der Zentrale sorgen.

Wenn irgendwann zuviele Leute zu lange Listen absaugen, könnte man 
einfach ab und zu die Gesamtbibliothek, nach Software sortiert, bei 
Sourceforge als Gesamtpaket abladen. Auf diese Download-Möglichkeit 
könnte man in einer zusätzlichen Kommentarzeile ('#Parts data from 
mikrocontroller.net\n#You can download the complete database for your 
software from http://partslib.sourceforge.net/files", oder wie der 
richtige URL dort dann heißen wird) am Anfang der Teile-libdaten 
hinweisen.

Das Backend könnte man ihm komplett liefern, wenn er es aus 
Arbeitsüberlastungsgründen nicht selbst machen möchte, aber das Projekt 
unterstützt.

Die Hauptfrage wäre dann ein Sinnvolles und eindeutiges 
Benennungsschema.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi didadu,

Die mysql-db plus serverspace koennte ich auch sponsorn, die Jungs von 
MC haben sicher genug am Hals. Mir geht's vor allem aber um ein 
benutzbares Front-End. Wenn du denkst, der Zeitpunkt waere schon 
gekommen, mit einer zentralen DB zu experimentieren, kein Problem, nen 
DB-User fuer vollen Zugriff (auf die 'components' datenbank) kann ich 
ad-hoc einrichten. Traffic ist kein Problem. Schick mir einfach ne PM, 
dann richte ich das mal mit ner rohen DB ein und du kriegst ne userid.
Werde mal heute Abend noch nach Lagerverwaltungs-Systemen googeln, da 
muss es doch was geben, was sich irgendwie aufbohren laesst.

Gruss,

- Strubi

Autor: gerd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Strubi schrieb:
> Werde mal heute Abend noch nach Lagerverwaltungs-Systemen googeln, da
> muss es doch was geben, was sich irgendwie aufbohren laesst.

Würde das nicht schon gehen: Part-DB RW - Lagerverwaltung

- gerd

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Strubi,

Natürlich könnte ich das Python-Script weiter aufbohren, sodass es die 
ganzen Daten gleich mit dieser DB abgleicht. Dann könnte man mal etwas 
intensiver Teiledaten sammeln.

Allerdings überrollt mich das jetzt gerade alles etwas...

Aber ich denke trotzdem schon mal etwas weiter.

- Das Programm (KiCad, gEDA, Eagle) sollte man unbedingt angeben.
- Die Version ("KiCad-LibDBsync_v0.1") des Upload-Programms auch, damit 
man, wenn man mal was ändern will an der API bzw. dem Datenformat, das 
serverseitig mit Plugin-Modulen für unterschiedliche Formate richtig 
sortieren kann, wenn man später merkt, dass es notwendig wird, aber die 
Leute natürlich nicht alle gleich die neue Software verwenden.
- Für Testzwecke sollten wir vielleicht zunächst ein "Test"-Flag 
einführen? (Oder man erschlägt das gleich mit der Version, s.o.)

Und Richtlinien für eine einheitliches Benennungsschema wären auch nicht 
schlecht.

Was mir auch noch gefallen würde, wäre die Einbindung von Daten zum 
leichten und schnellen Auffinden von Vergleichstypen. Also in etwas das 
Prinzip, dass ein "BC237" einfach nur ein "TUN" ist (das kenne ich aus 
der elektor-Terminologie). Etwas genauer könnte man es aber schon haben. 
Ich stelle mir das so vor, dass man bei einer Schaltung ja nicht 
unbedingt einen bestimmten Typ braucht, sondern eine Anforderung 
vorliegt wie: "Ich brauchen einen bipolaren PNP-Transistor mit einem ß 
zwischen 25 und 28, der einen maximalen Kollektorstrom von 35 mA 
aushält, bei einer Spannungsfestigkeit von X Volt." Optional mit "im 
Gehäuse soundso". Dann kann er mir auswerfen, welches Teil in meinem 
Lager oder in der Datenbank meiner Lieferanten auch geeignet wäre. Je 
gröber die Mindestanforderungen in einer Schaltung sind, desto mehr 
Auswahl hat man, und muss nicht lange suchen. Gerade auch interessant 
bei Lieferengpässen. :-/

Interessant wäre auch eine Funktion/Ein Script, die aus einer ganzen 
Schaltung ein Bauteil macht. Also ein .sch inklusive Board in eine .lbr 
umwandelt. Dann kann man sich leichter Elektronik-LEGOs definieren. Man 
muss dann nur die Anschlusspunkte möglichst sinnvoll definieren UND im 
Board platzieren, damit man diese Module, die dann in der Lib sind, 
leicht miteinander verbinden kann. Offensichtliche Kandidaten sind ja: 
"ATmegaXXX inkl. Quarz, pF-Cs, Reset-R, ADC-L, ADC-C", "Spannungsregler 
inkl. Anschlussklemmen, C-Elko und 2 Kerkos", usw.

Hilfreich wäre vielleicht auch, wenn man sich in KiCad solche Scripte 
auf Buttons oder Menüpunkte legen kann, also ein Erweiterungsframework.

Vielleichts gibt's das alles schon; ich habe danach noch nicht so genau 
gesucht.

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
didadu schrieb:
> Elektronik-LEGOs

Die Frage wäre dabei für mich (momentan), wie leicht man so eine 
"Modul-Lib" wieder in die Einzelkomponenten (aber nicht weiter!) 
aufsplitten kann, wenn man Teile davon umrouten will (vor allem auf dem 
Board, das man routet). D.h., ob die GUI von KiCad für sowas eine 
geeignete Funktion bereitstellt oder man da noch was implementieren 
müsste.

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gerd schrieb:
> Würde das nicht schon gehen: Part-DB RW - Lagerverwaltung

Why not. Ich mag allerdings Python lieber als PHP. Da braucht man gar 
nichts installieren (außer Python), und einen Webserver und sqlite hat 
das auch schon integriert.

Ich wünsche mir für so eine Parts-DB auch eine Importfunktion, die aus 
den elektronischen Bestätigungs-E-Mails oder Rechnungen der Lieferanten 
die Bauteilemengen und -bezeichnungen extrahieren kann, damit ich sie 
per Mausklick updaten kann (oder direkt eine API beim Lieferanten 
kontaktiert).

Wie mir scheint, geben die Hersteller von Bauteilen auch gewisse Daten 
raus. Z.B. Simulartordaten und Footprints für bestimmte Programme. 
Vielleicht auch komplette Bauteilelisten. Vielleicht kann man da ja 
Converter für schreiben. Ich hoffe, derartige Daten sind kostenlos und 
frei verfügbar. Müsste mal jemand anfragen und auf den Homepages gucken, 
wie das so läuft. Vielleicht hat auch hier schon einer Ahnung davon und 
kann es einfach sagen, oder gar Listen hier hochladen.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gerd:
Danke fuer den Hinweis - wieso sehe ich das jetzt erst? Mal damit 
rumspielen. Scheint nur keine User-Verwaltung zu haben, aber das duerfte 
das geringste Problem sein.

didadu:
Einige Hersteller geben BSDL- oder UCF-Files raus, die lassen sich in 
Pin-Listen parsen. Generiere hier auch rohe LIB files draus, die muss 
ich nur selber manuell in parts splitten. Lohnt sich fast schon ab 
LQFP-44.

Wenn ich dich richtig verstehe, willst du quasi ein hierarchisches 
Schema mit exportierten PinSheets in eine LIB-Komponente backen. Ich 
denke, das kriegt man auch mit nem Python-Script relativ einfach hin. 
Weiter objektorientiert geht das ganze vermutlich nur mit grundlegenden 
architektonischen Veraenderungen an kicad, da gaebe es noch die 
Knackpunkte der Annotation.

Ich schau mal, wie leicht ich die part-db mit footprints gefuellt 
bekomme...

Gruesse,

- Strubi

Autor: Strubi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Followup in Kuerze:

- parts-db angeschaut: Ist wirklich gut gemacht, aber die Komplexitaet 
"unserer" Datenbank wuerde das Framework sprengen. Dummy-Datensaetze aus 
kicad-LIB-Verzeichnissen generieren: Siehe index.py (didadu's 
aufgebohrtes Script).
- Mal in div. Python-CMS reingeschnuppert: web2py, django, ev. kommt 
noch pylons dazu.
- typo3 (PHP) hat einige Shop-Systeme als Extensions verfuegbar. So 
etwas eignet sich IMHO am ehesten zum Aufbohren. Warte noch auf den 
Experten, der schreit: Nimm DAS, damit geht's.
- Vorteil der Python-Loesungen scheint mir: Datenbankstruktur wird im 
Script selber beschrieben, Aenderungen/Migrationen also leichter.


Favorisiere ebenfalls Python, der Code ist einfach generell 
wiederverwertbarer. Aber fuer die Python-CMS habe ich noch kein 
adaequates Shop-System im OpenSource gefunden.

Gruesse,

- Strubi

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Strubi schrieb:
> Mal in div. Python-CMS reingeschnuppert: web2py, django, ev. kommt
> noch pylons dazu.

Die würde ich alle nicht verwenden.
Ich habe mir solche Systeme auch schon mehrmals angeschaut, um sie evtl. 
für ein Projekt zu benutzen, aber letztlich jedes Mal verworfen. Da 
kommt eine Komplexität und eine Abhängigkeit von den externen 
Entwicklungen ins Projekt, die ziemlich nerven kann, man verbringt dann 
mehr Zeit damit, Das System(TM) zu verstehen, als seine eigene 
Funktionalität zu programmieren. Das ist wohl eher was für Leute, die 
damit beruflich immer wieder neue Websites machen, also ständig damit zu 
tun haben und eh auf dem Stand bleiben.
Sowas ist meiner Meinung nach hier gar nicht nötig, da die gebrauchten 
Funktionen eher überschaubar sind.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
didadu schrieb:
> Die würde ich alle nicht verwenden.
> Ich habe mir solche Systeme auch schon mehrmals angeschaut, um sie evtl.
> für ein Projekt zu benutzen, aber letztlich jedes Mal verworfen. Da
> kommt eine Komplexität und eine Abhängigkeit von den externen
> Entwicklungen ins Projekt, die ziemlich nerven kann, man verbringt dann
> mehr Zeit damit, Das System(TM) zu verstehen, als seine eigene
> Funktionalität zu programmieren. Das ist wohl eher was für Leute, die
> damit beruflich immer wieder neue Websites machen, also ständig damit zu
> tun haben und eh auf dem Stand bleiben.

Verstehe deine Bedenken. Finde allerdings web2py auf den ersten Blick 
ueberschaubar.

> Sowas ist meiner Meinung nach hier gar nicht nötig, da die gebrauchten
> Funktionen eher überschaubar sind.

Welche Alternative gibt es denn?
Ohne Framework wuerde ich die Sache nicht anfangen, das wird 
erfahrungsgemaess sehr schnell sehr komplex, die Einarbeitung in ein CMS 
amortisiert sich spaetestens, wenn du 10 Features auf der Wunschliste 
hast.
Die Community wird sehr schnell haben wollen, was sie z.B. auf der 
Farnell-Webseite bekommt. Wenn du dann anfangen musst, erst mal die 
erfundenen Raeder rund zu kriegen, springen dir die User ab.

Habe allerdings keine Einwaende dagegen, wenn du alles "standalone" 
schreiben wuerdest, wenns schoen modular ist und einen HTML-Writer oder 
andere 'abstraction layer' fuer die Ausgabe benutzt, laesst es sich ja 
einbinden.

Gruesse,

- Strubi

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Strubi schrieb:
> Die Community wird sehr schnell haben wollen, was sie z.B. auf der
> Farnell-Webseite bekommt.

Ähhhh ... was schwebt Dir denn da vor? Ich vermute, wir sind gerade out 
of sync. Ich dachte an eine viel einfachere Sache:

Und zwar einfach an ein DB-Backend zum gemeinschaftlichen Sammeln der 
existierenden Symbole/Footprints und zum gegenseitigen Synchronisieren. 
Also gar keine große Weboberfläche, sondern nur ein DB-System zum Hoch- 
bzw. Herunterladen von Listen und Textdateien ohne Formatierung.

Die GUI wäre dann primär der Simpel-Webserver auf dem lokalen Rechner.

Evtl. könnte man auf dem Server noch ein Webformular mit Suchmaske 
vorsehen, der als Ergebnis eine Liste von Teilen ausgibt und Symbole und 
Footprints anzeigt, aber auch das ist eigentlich kaum nötig, weil der 
lokale Access-Client das schon leistet.

Abgesehen von der Grafikanzeige (und die muss man nicht gleich zu Anfang 
machen) wäre das Webserver-Backend eine kurze php-Datei.
Gespeichert würden die Daten dann ja sowieso auch noch mal lokal 
(sqlite).

Also KISS. Quick and ... clean.

Wenn die Community viel mehr haben will, muss man vielleicht auch ein 
paar Mitarbeiter dafür finden.

Aus meiner Sicht hat das momentan eine einfache aggegierende und 
explorative Funktion ("mal schauen, was es bei den Usern so gibt und wie 
wir das gemeinsam nutzen können").
Was im Web so zu finden ist, fand ich nicht gerade sehr umfangreich, und 
ich denke, wenn es KiCad-User gibt, dann gibt es auch einige mehr Teile, 
als ins Web gestellt werden.
Je aufwandsfreier und je weniger intrusiv es möglich ist, seine Arbeit 
mit anderen zu teilen, desto mehr Leute werden das hoffentlich tun. 
Außerdem erfährt man so -- macht man so für alle sichtbar -- wo die 
Usercommunity gemeinschaftlich steht.

Eine Schwierigkeit ist ja, dass die Libverwaltung der Softwares sich 
heutzutage noch zu viel um den jeweils eigenen Bauchnabel dreht, d.h. 
nicht auf Austausch mit anderen optimiert sind. Das ist ok, aber den 
Austausch-Layer kann man hinzufügen. Der sammelt und zentralisiert das, 
was der User in zahlreichen unübersichtlichen Dateien auf seinem Rechner 
hat und hilft ihm damit schon mal selbst, was ein Grund ist, so eine 
Software zu nutzen, und die zu schaffende Austauschfunktion erschließt 
(auf Wunsch) alle diese Daten für alle und verbindet die Robinsons mit 
einem größeren Ganzen, mit dem man dann schneller gemeinsam weiterbauen 
kann.

Aufbohren für einen komfortableren Direktzugriff kann man so ein Backend 
später immer noch. Aber selbst da frage ich mich, wozu eigentlich, wenn 
man die Daten eh schon mit dem lokalen Client durchsuchen, auswählen und 
anzeigen kann?

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die benötigte Funktionalität ist doch diese:
- Ich will was bauen mit einem Teil.
- Wo ist das Teil in der Lib?
- Die Sucherei beginnt, und fängt schnell an zu nerven.
- Hm, gibt es das überhaupt schon?
- Anscheinend nicht.
- Na, schauen wir mal im Internet.
- Mehrere Seiten, alle unterschiedlich, teilweise nicht sehr praktisch. 
Ob es da was Neues gibt seit dem letzten Besuch, ist praktisch nicht zu 
erkennen. Gibt es neue Seiten? Mal schauen mit google.
- Mist, ich muss es selbst machen. Na ok.
- Man macht es. Baut seine Schaltung, ist zufrieden.
- Alle anderen: Genauso.
- Und alle bleiben dabei.
- Wenn ein Neuer mal was sucht und in einem Forum fragt, wird er mehr 
oder weniger unwirsch auf das oben beschriebenen Verfahren verwiesen. 
Soll er doch selbst suchen.
- Und so, viel Zeit geht verloren mit Sucherei und nochmals Sucherei.

Es geht ja nur darum, diesen Prozess abzukürzen und zu vereinfachen. 
Also den Computer und das Web für das zu nutzen, für das sie gemacht 
sind: dem Menschen zu dienen, statt ihn in neue Labyrinthe zu werfen.
Wenn die Software das leistet, reicht es. Alles andere ist meiner 
Meinung nach nicht wirklich erforderliches Beiwerk.

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Strubi schrieb:
> index.py (4,9 KB, 1 Downloads)
> partdb.py (900 Bytes, 1 Downloads)

Hab mir das jetzt mal angeschaut. Das ist also ein Importer, mit dem man 
die Bezeichnungen der Teile, die in den auf dem eigenen Rechner 
vorhandenen Libs definiert werden, in die PartsDB einliest.

Dazu fallen mir mehrere Dinge ein:
- Sowas macht man nicht nur einmal, sondern aller Voraussicht nach 
mehrmals. Dann muss der Importer also mit dem vorhandenen Inhalt 
abgleichen können, damit man keine Dubletten erhält.
- Wenn man Libs aus dem Web von unterschiedlichen Leuten hat, haben die 
Teile keine einheitlichen Bezeichnungen. Mal ist die volle Bezeichnung 
inkl. Varianten genannt, mal nur der grobe Typ. Der eine schreibt "C" 
vor seine Cs, der andere nur MKP 10 µ, der eine mit Spaces, der andere 
ohne, usw.
Das tiefere Problem dahinter ist, einmal mehr, die babylonische 
Sprachverwirrung der Leute. Jeder benennt die Dinge anders.

Der kanonische ("offizielle") Name wäre die volle Bezeichung des 
Herstellers. Also seine Bestellnummer. Bei LEDs enthält das sogar die 
Bins... Dann wären die Teile eindeutig identifiziert.
Diese Bezeichnungen sind aber unhandlich und nicht allen Usern bekannt.
Außerdem verwenden die Händler meist eigenen Bezeichnungen, mehr oder 
weniger verkürzend, die den Usern möglicherweise geläufiger sind.

Man braucht also im Prinzip ein Mapping der unterschiedlichen geläufigen 
Bezeichnungen auf die realen Teile.

Hinzu kommt, dass den Usern teilweise egal ist, was für ein Teil sie 
GENAU haben. Also ob der C von Hersteller X oder Hersteller Y kommt. Er 
will nur "einen Elko mit 220 µ 35 V". Anschlussfrage: "Wie groß ist der 
eigentlich?", und da geht's dann wieder los. Radial oder axial? 
Hersteller? usw.

Der Bastler, der es gewohnt ist, in seine Teilekiste zu greifen, ist 
schnell überfordert mit Detailangaben. Ihm muss man sie möglichst 
verbergen, bzw. die Auswahl so intuitiv wie möglich halten, vor allem 
immer mit Bildern und Abmessungen der Symbole und Footprints. Derartige 
Auswahlmöglichkeiten sollten möglichst nur einmal nötig sein. Also nicht 
einmal lange suchen, um den C zu finden, und dann in einem späteren 
Programmteil WIEDER rein in die Bibliotheken, um WIEDER lange den 
Footprint zu suchen. Ändern ist ok, aber zweimal den Nerv, bitte nicht.

Der Profi hingegen wird wohl wissen, was er genau will. Er nutzt sein 
Toll ja auch häufiger und kennt sich somit besser aus. Da ist der 
Detailreichtum ein Plus. Aber auch er würde eine Auswahlmöglichkeit zu 
schätzen wissen, aber dazu müssen die Hersteller- bzw. Händlerdaten 
integriert (bwz. integrierbar) sein, und dann ist es auch für ihn ein 
Vorteil und sogar eine Arbeitsbeschleunigung, sofern es gut gemacht ist.

Die Auswahl erfolgt immer hierarchisch. Dabei gibt es jedoch 
unterschiedliche Hierarchien.
Der eine denkt: C - 10n - Rasterabstand 2 Lochrasterpunkte
Eine andere: C - Wima MKP - 630V - wie groß? sind die Werte zwischen 10 
und 47n?
Noch ein anderer: Ich hab hier diesen C in der Hand, der genau passt, 
und brauche mal schnell den Footprint dazu. Also will er klicken auf: C 
- Radial - 2 Rasterpunkte Abstand (Hersteller egal, Wert sekundär, weil 
ja erstmal nur zum Probieren getestet wird).

Wenn man diese unterschiedlichen Hierarchien in eine einzige Bezeichnung 
pressen muss, wird immer der jeweils andere Teil der User eine 
nichtoptimale Suche haben und seine Teile nicht finden, also genervt 
sein.

Wenn man ein simples Klickinterface haben will, muss man also 
nacheinander über verschiedene Stufen seine Parameter auswählen können. 
Eine Art parametrische Suche als Klickhierarchie. Mit Klick geht sicher 
schneller als mit diesen Listenfeldern auf den Webseiten. Das geht 
deswegen, weil die Fragestellung eine andere ist. Man sucht ja weniger, 
welches Teil überhaupt passt, sondern versucht, das Abbild der schon 
ausgewählten Realität in der Lib zu finden.

Um da hinzukommen, muss man die existierenden Daten in den Libs 
allerdings neu aufbereiten, also entsprechend kategorisieren. Das kann 
man wohl zum Teil automatisieren, wenn man erstmal eine Suchfunktion hat 
und ein ergonomisches Klickinterface für die Kategorisierung, aber 
vermutlich bleibt ein manueller Teil.

All mein Gelaber wieder mal nur, um die Konzeption der Sache möglichst 
klar im Kopf zu haben. ;-)

Aus dem Gesagten folgt auch, dass man für jeden Hersteller bzw. 
Lieferanten diese Kategorien herausarbeiten muss, um sie den Libs so 
automatisch wie möglich (Qualersparnis) zuordnen zu können.

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Illustration: Auch sowas kann man parsen und gemeinschaftlich verfügbar 
machen, um eine Bauteiledatenbank herzustellen:
Vielen Dank für Ihre Bestellung, [...]
Folgende Daten haben Sie an uns übermittelt:

Ihre I-Net Nummer (bei Rückfragen bitte angeben): XXXXXX

[...]
                                                                     Gesamtpreis
Artikelnummer    Bezeichnung                          Anzahl                    
________________________________________________________________________________
TMC 428-PI24     Schrittmotor-Controller SO-24             1          12,95 Euro
SA 56-11 RT      7-Segment-Anzeige, rot, 14,2mm, gem.     10           4,50 Euro
TORX 173         Toshiba LWL-Empfänger, Simplex            2           6,60 Euro
TOTX 173         Toshiba LWL-Sender, Simplex               2           7,30 Euro
LWL TOS 8        2X Toslink-Stecker, Ø= 5,0mm, 5,0 Met     2           6,60 Euro
1N 5822          Schottky Diode, DO201AD, 40V, 3A         10           2,10 Euro
1N 5819          Schottky Diode, DO41, 40V, 1A            10           0,60 Euro
1N 5818          Schottky Diode, DO41, 30V, 1A            10           0,60 Euro
FIN 40.52.6 12V  Bistabiles Steckrelais, 12V, 2 Wechsl     1           5,60 Euro
LM 393 DIP       Comparator,  DIP-8                        5           0,75 Euro
LM 393 D SMD     Comparator,  SO-8                         5           0,95 Euro
BF 245A          Transistor HF N-FET TO-92 30V 0,025A     10           1,50 Euro
2W DRAHT 0,33    Draht-Widerstand 2W, 10% 0,33 Ohm         5           1,15 Euro
BUZ 171          Transistor P-FET TO-220AB 50V 8A 40W      3           8,25 Euro
SB 540           Schottky Diode, DO201, 40V, 5A            5           1,50 Euro
FT 114-61        Ferritring 5961001001                     1           2,50 Euro
FT 82-61         Ferritring 5961000601                     1           1,50 Euro
RIK 10           Ringkern aus Ferroxube, N30               1           0,71 Euro
RIK 12           Ringkern aus Ferroxube, N27               1           0,77 Euro
RIK 20           Ringkern aus Ferroxube, N30               1           1,40 Euro
T 106-26         Eisenpulver-Ringkern                      5           5,75 Euro
BC 337-40        Transistor NPN TO-92 45V 0,5A 0,625W     10           0,40 Euro
KUPFER 0,5MM     Kupferlackdraht, Ø 0,5mm, Länge: 23M      1           1,65 Euro
ENC 28J60-I/SO   Ethernet Controller, Stand-Alone, SOI     1           2,55 Euro
ENC 28J60-I/SP   Ethernet Controller, Stand-Alone, S-D     1           2,60 Euro
SMD-0805 27,0    SMD-Chip-Widerstand, Bauform 0805, 27    10           0,82 Euro
SMD-0805 270     SMD-Chip-Widerstand, Bauform 0805, 27    10           0,82 Euro
L-0805F 10µ      SMD-Induktivität, 0805, Ferrit, 10µ       5           1,10 Euro
BAT 43 SMD       Schottky Diode SMD, Mini-Melf, 30V, 0    10           1,00 Euro
BAT 43WS         SMD-Schottky-Dioden, SOD323F, 30V, 0,    10           0,50 Euro

Da bräuchte man natürlich für jeden Hersteller (und jede Änderung seiner 
Verfahren) ein Modul.

Dann hat man die Teile in seiner Inventur und kann ihnen die 
Bauteile-Libs zuordnen. S. meine vorangehende Mail.

Man kann mit Python auch Mailboxen auslesen. Wenn jemand also viel 
bestellt und die Bestätigungs-Emails in seiner Mail-Software nicht 
löscht, kann man da einiges zusammenbekommen -- vollautomatisch.

Man kann sich gut vorstellen, dass gerade diese Bezeichnungen für viele 
User die geläufigsten sind, mit denen sie ihre Teile am leichtesten 
finden würden.
(Und wem gehört die Sprache? Man muss sie miteinander teilen dürfen, um 
überhaupt präzise miteinander über die Dinge kommunizieren zu können.)

Hilfreich wäre also auch ein Filterkriterium "gekauft bei", und das 
Einscannen solcher Bestelllisten wird aufgrund des Aspekts der 
sprachlichen Gewöhnung an bestimmte Bezeichnungen ja fast zu einer 
Notwendigkeit.

Im Grunde wäre es nett, wenn die Händler für ihre User die Footprints 
aller Teile auf der Website vorrätig hielten.

Als Service könnten sie mit den Bestätigungs-Emails sogar einfach immer 
alle Daten mitschicken. (Ggf. auf Wunsch)

Warum sollte die Community nicht ein Tool für sowas bereitstellen, das 
die Lieferanten dann auf ihrem Webserver installieren bzw. in ihren 
Ablauf integrieren können?

Jeder Hersteller und Händler kann hier seine Listen posten, das würde 
dem Projekt helfen. Es müssen ja nicht gleich alle Infos drinstehen (und 
Preise sind eh variabel), aber man sieht ja eh, dass sie uns, den 
vergleichenden Marktteilnehmern, kollektiv gesehen doch nicht entgehen. 
Warum dann nicht den Usern helfen, die Teile auch rationell zu nutzen? 
Am Ende verkaufen sie vermutlich insgesamt alle mehr, weil dann auch 
mehr (weil einfacher) damit gebaut werden kann.

Also, postet eure Listen hier! Ich wünsche mir Listen mit:
Bestellbezeichnung - Beschreibung - exakte Herstellerbezeichnung - 
Gehäuse. Dann können unsere Tools die Teile und somit deren Libs und 
Footprints für die Verwendung in Schaltplan und Platinen leicht 
auffindbar machen.

Und am besten gleich die Libs dazu, falls existent. Die Händler sollten 
sie selbst bei ihren Lieferanten anfordern! Eine entsprechende Nachfrage 
führt dann vielleicht dazu, dass diese Dinge von den Herstellern gleich 
mitgeliefert werden, wie ja auch schon die Datenblätter.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
didadu schrieb:
> - Sowas macht man nicht nur einmal, sondern aller Voraussicht nach
> mehrmals. Dann muss der Importer also mit dem vorhandenen Inhalt
> abgleichen können, damit man keine Dubletten erhält.

Haste voll recht. War ja erst mal ein "billiger Hack" :-)

Den anderen Aspekten des Suchens stimme ich voll zu - nebenbei: Farnell 
treibt trotz seiner Komplexitaet des oefteren zur Verzweiflung, weil man 
manche Dinge einfach nicht findet.
Genau da steckt der Teufel im Detail, und es ist teuflich schwer, bei 
all dem Wildwuchs benutzerfreundlich zu bleiben/werden.
Da fuer dieses Projekt erwartungsgemaess kein allwissender 
Datenbankorganisator existieren wird (oder naja, wir werden uns 
eventuell an Bernds Kicad-Library-Schema orientieren), wird es im 
Endeffekt bei der Community liegen, sinnvolle Daten zu generieren.

Die Mammutaufgabe, einen "Google-Algorithmus" fuer die gespeicherten 
Parts/Footprints zu schreiben, haette ich auch hinten angestellt, wie 
auch die Feinheiten, die du beschreibst - denn das koennte man ja alles 
auch per Google auffinden.

Prinzipiell will ein Kicad-Library-User, der morgen seinen 
Platinenprototyp fertig haben will, ja nur folgendes:

1. Symbol
2. Zugehoeriger Footprint

Welche Teile darauf passen, muessen IMHO in eine andere Tabelle.
Also: Bauteil XY-1234 (id) vom Hersteller (->hersteller) passt zu: 
(->symbol,->footprint). Die ganzen Eigenschaften unterzubringen, ist 
tierischer Sisyphos, wuerde ich einfach an die Hersteller auslagern (und 
nur ein Link-Interface zur Distributor-Webseite implementieren)

Um die ganzen User-spezifischen Klassifizierungs-Schluessel zu 
ermitteln, wuerde ich erst mal eine Moeglichkeit vom Framework her 
schaffen, einen Datensatz zu taggen.

Beispiel:
Als fixe Eigenschaften eines Kondensators in der Tabelle:

[Wert] [Footprint] [Hersteller] [Bauform] [MaxVolt] [Typ]      [Tags]
1uF    0604        (42)         (SMD)     16        (Ceramic)  (cheap), 
(low esr)

Die Eintraege in () waeren ueber weitere Tabellen indiziert.
Die Tags-Tabelle muss irgendwer mal saeubern und klassifizieren.

Um nach und nach eben diese ganzen Wunschfeatures einzufuehren, wollte 
ich mich moeglichst wenig mit Details wie Dropdown-Boxen und 
Tagging-Mechanismen beschaeftigen, sondern das moeglichst an ein 
CMS-Framework auslagern. Dann hat man auch eher die Moeglichkeit, 
Erweiterungen einzufuehren, dass sich jeder User mit seiner 
Herangehensweise "zuhause" fuehlt. Genau dort steckt, denke ich, der 
Hirnschmalz der diversen CMS-Systeme.

Da ich das ganze wie erwaehnt ja an einer andern Baustelle (Verwaltung 
von unzaehligen Geraetebeschreibungen) eh einsetzen will, wuerde ich 
sagen, wir prototypen einfach mal munter weiter, und schauen, was 
rauskommt, bevor wir uns zu sehr den Kopf zerbrechen.

Autor: Mine Fields (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe mir den Thread durchgelesen und finde das Projekt schon sehr 
interessant, allerdings habe ich durch viele Details ein bisschen den 
Überblick verloren. Ich würde mir von dem Vorhaben folgendes 
versprechen:

- Eine Internetdatenbank für Bauteile, die zwar primär für Kicad 
aufgebaut wird, theoretisch aber auch von anderen Programmen verwendet 
werden kann.

- Eben eine Anbindung an Kicad, wobei ich aus der Internetdatenbank 
meine eigene lokale Library für meine Zwecke zusammenbauen kann. Die 
parametrische Suche sollte aber immer noch möglich sein.

- Einbindung möglichst vieler Bauteileparameter und Zusammenfassung von 
Bauteiltypen (z.B. Widerstände, Transistoren, Operationsverstärker) für 
eine parametrische Suche (um z.B. das Finden von Ersatztypen zu 
erleichtern)

- Was aber meiner Meinung ein absolutes No-Go ist, dass Bauteile 
gleichen Types verschiedene Symbole haben. Ein Bipolartransistor 
beispielsweise soll in meinem Design immer gleich aussehen! Man müsste 
also auch eine getrennte Symboldatenbank führen, bei denen man sich 
seine Lieblingssymbole für diese Standardbauteile heraussuchen kann. In 
der Bauteildatenbank wird also für solche Standardteile nur eine 
Referenz hinterlegt. Bei komplexeren Bauteilen macht das natürlich 
keinen Sinn mehr.

Soviel zur Datenbank. Ist Bernd eigentlich noch aktiv hier? Er hat schon 
ewig nichts mehr geschrieben. Für ihn wären nämlich dann noch die 
folgenden Ausführungen (die werde ich aber vielleicht bei Gelegenheit 
auch direkt an die Kicad-Entwickler wenden):

Was mich an der Bauteileverwaltung bei Kicad auch noch stört:

- Ich möchte das Bauteilfenster als Dialog immer offen haben und nicht 
als modalen Dialog eingebunden haben. Ist sicher Geschmackssache, aber 
sollte als Option möglich sein.
- Die parametrische Suche fehlt (wie ja schon erwähnt).
- Die Größenverhältnisse der Symbole sind absolut irrsinnig 
(Kondensatoren und Widerstände sind z.B. viel zu groß)

Und wer hat sich eigentlich das Konzept ausgedacht, dass Power-Pins wie 
Bauteile gehandhabt werden? Ist ja bei Eagle genauso. Ich kenne Systeme, 
da ist das viel eleganter gelöst: Man hat eine eigene Symbolgruppe für 
Power-Pins und globale Signale (letzteres gibt es bei Kicad ja). Diese 
kann man dann nach Belieben benennen.

Man ist also nicht auf die festen Power-Benennungen angewiesen. Das ist 
ganz nett, wenn man zum Beispiel mit mehreren galvanisch getrennten 
Bereichen arbeitet und diese mit einem Suffix kennzeichnen möchte.

Autor: didadu (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier ist ein Parser für Bestelllisten eines (bestimmten) Lieferanten.

Meine Vorstellung ist, dies dazu zu nutzen, um entweder:
- seine entsprechenden E-Mails durch Kopieren-Einfügen in ein Textfeld 
des Browser-Interfaces zu übertragen und dann in die DB einzulesen (wenn 
die Bestellbestätigungen eintreffen und man sie checkt)
oder:
- einen Mailfolder, in dem man seine Bestellungen speichert, automatisch 
auszulesen, um die Datenbank mit den früheren Bestellungen zu füllen.

Offensichtlich braucht man für jeden Lieferant so einen "Connector".

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Strubi schrieb:
> wird es im Endeffekt bei der Community liegen, sinnvolle Daten zu generieren.

Bingo. Die Lieferanten sind alles "nur" Leute, die das für Geld machen. 
Also machen sie das, was für sie selbst notwendig ist, und das, was für 
den Verkauf unerlässlich (oder gesetzlich vorgeschrieben) ist. Jeder 
Lieferant wieder neu und für sich. Organisieren und in eine 
übergreifende Struktur müssen wir es bringen, weil da jeder sein eigenes 
Pflänzen hegt. Ist ja auch legitim, jede Firma hat eigene Vorstellungen, 
und Freiheit bringt das mit sich. Aber vergessen wir nicht, dass sie uns 
so nebenbei ihre Sprachverwirrung aufzwingen, was uns bis zur 
Vereinheitlichung zahlreiche Probleme bereitet und einen gewissen Teil 
unseres Lebens (sicher meist ohne böse Absicht) zu einer Hölle macht, 
die sie nicht sein müsste, wenn man gleich etwas gemeinsames 
organisiert. Stichwort "Formatkrieg" (s. Wikipedia, z.B. 
Edison/Westinghouse).

> Die Mammutaufgabe, einen "Google-Algorithmus" fuer die gespeicherten 
Parts/Footprints zu schreiben, haette ich auch hinten angestellt, wie auch die 
Feinheiten, die du beschreibst - denn das koennte man ja alles auch per Google 
auffinden.

Nun ja, ich stehe bei jedem Entwurf konkret vor dem Problem, die Symbole 
und Footprints zu finden. Daher wird das wohl eher eine meiner ersten 
Ansätze Prioritäten sein.

> ein Kicad-Library-User

Ich will mich da nicht nur auf KiCad festlegen. gEDA ist vielleicht auch 
nicht schlecht. Da gibt's immerhin Simulatoren. Auch für KiCad?
Eine Teilebibliothek ist an sich nicht vom CAD-Programm abhängig, da 
sich alle Daten zunächst nur auf die Teile beziehen: 
Herstellerbezeichnung, Aussehen (Foto/3D-Datei), Symbol, Footprint, 
Pinzahl, elektrische Eigenschaften, usw.
Das Programm kommt erst am Schluss. Also müsste im Grund auch ein 
programmunabhängiges Format für das alles her. Da das aber (für mich) 
momentan mangels Überblick zu schwierig ist, optiere ich dafür, erstmal 
die freien Bibliotheken zu sammeln und die Teiledaten im jeweiligen 
Format zu speichern, wobei man ich sie kennzeichnen will, um sie zu 
unterscheiden.

> Eigenschaften eines [Teils] in der Tabelle

Ja, so in etwa. Ich würde aber erstmal nichts indizieren, sondern 
einfach alles im Klartext eintragen, weil die Programmierung sonst so 
umständlich wird. Die Normalformen der DBs würde ich erst in einem 
späteren Schritt herstellen. Man ist ja eh erstmal noch am groben 
Sammeln der wichtigsten Daten.
Ich würde aber immer auch Benutzertags zulassen wollen. Von mir aus soll 
ein Komitee sich da was schlaues ausdenken, aber mit eigenen Tags kann 
ich sowas sehr leicht an meine Bedürfnisse anpassen und für meine 
Projekte oder sonstwas kategorisieren.

> Details wie Dropdown-Boxen

Geht mir genauso. Aber man kann auch mit Klicklinks arbeiten, solch 
Programmcode ist einfacher und übersichtlicher. Vor allem: es ist für 
den Benutzer übersichtlicher, weil man die ganze Liste im Blick hat. Ok, 
immer ist das nicht die beste Lösung, aber ... mal sehen.

> wir prototypen einfach mal munter weiter, und schauen, was rauskommt

Genau :-)

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ein Bipolartransistor
> beispielsweise soll in meinem Design immer gleich aussehen! Man müsste
> also auch eine getrennte Symboldatenbank führen, bei denen man sich
> seine Lieblingssymbole für diese Standardbauteile heraussuchen kann. In
> der Bauteildatenbank wird also für solche Standardteile nur eine
> Referenz hinterlegt.

Ja, würde ich auch so sehen. Es gibt ja z.B. unterschiedliche Normen.
Da sollte man vielleicht einen allgemeinen Schalter vorsehen (das 
erschlägt sicher die meisten Fälle), aber warum nicht auch persönliche 
Präferenzen ermöglichen. Es würde ja z.B. schon reichen, wenn die 
Symbole immer in der Häufigkeit der eigenen Verwendung aufgelistet 
werden. Dann stehen die Lieblingsteile immer oben in der Liste.

> Die Größenverhältnisse der Symbole sind absolut irrsinnig
Könnte ein Programm evtl. automatisch normalisieren.
Oder halbautomatisch. Halbautomatisch ist aber immer mehr aufwand, weil 
man sich ein Benutzerinterface überlegen und programmieren muss.

Man könnt auch Tests machen, z.B. ob Teile alle auf einem bestimmten 
Raster liegen. KiCad und gEDA arbeiten (zum Glück beide) mit mil (1/1000 
Zoll). Da braucht man z.B. nur durch 200 zu teilen und sich den Rest 
anschauen, um zu wissen, ob ein Teil auf 2-Loch-Raster ist. Wäre doch 
ein praktisches Auswahlkriterium. :-)

Autor: Mine Fields (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
didadu schrieb:
> Ja, würde ich auch so sehen. Es gibt ja z.B. unterschiedliche Normen.
> Da sollte man vielleicht einen allgemeinen Schalter vorsehen (das
> erschlägt sicher die meisten Fälle), aber warum nicht auch persönliche
> Präferenzen ermöglichen. Es würde ja z.B. schon reichen, wenn die
> Symbole immer in der Häufigkeit der eigenen Verwendung aufgelistet
> werden. Dann stehen die Lieblingsteile immer oben in der Liste.

Ja, oder man stellt standardisierte Symbolsätze bereit. Mein 
Hauptanliegen an der Stelle ist eben nur, dass man Bauteile nicht fest 
auf Symbole verlinkt, da man sonst 100 Transistoren mit 10 verschiedenen 
Symbolen in der Internetdatenbank liegen hat - je nachdem wer das 
Bauteil gerade erstellt hat.

didadu schrieb:
> Könnte ein Programm evtl. automatisch normalisieren.
> Oder halbautomatisch. Halbautomatisch ist aber immer mehr aufwand, weil
> man sich ein Benutzerinterface überlegen und programmieren muss.

Zur Not geht manuell anpassen ja auch, wenn man sich sowieso einen 
eigenen Symbolesatz wie oben erwähnt zusammenstellen kann. Ich denke 
mal, dass in den Standards auch die Symbolgrößen festgelegt sind, daran 
könnte man sich ja auch orientieren.

Autor: didadu (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier ein weiterer Parser als Beispiel und Anleitung.
Die State-Machine ist hier etwas einfacher und logischer, also besser.
Ich habe einfach einen Lieferanten ausgewählt, der Bestellbestätigungen 
als html-Mail verschickt, da das etwas einfacher zu parsen ist, und weil 
ich die Bauteil in den Libs haben will, aber nur mühsam gefunden habe.

Die zwei Bestellzeilen hätte ich natürlich einfach eintippen können. 
Aber dann hätte ja sonst niemand was davon gehabt.

Diese Art Script kann direkt von der Commandline aus aufgerufen werden 
und parst dann die Beispieldaten im Script und gibt sie wieder aus (als 
Test). Es kann aber vor allem als Modul in ein anderes Python-Script 
importiert werden, sodass man die einheitlich benannten Funktionen als 
erweiterbares Modulsystem nutzen kann.
Somit können wir unsere Parser miteinander teilen, um unsere 
Bestelllisten einfacher in unsere DBs zu importieren und die Zuordnungen 
und neuen Libs leichter gegenseitig zu komplettieren.

Das Schreiben eines Parsers ist im Grunde eine Sache des Lieferanten, da 
er die Datenstruktur erstellt und am Besten weiß, wie man die Felder 
voneinander trennt.
Wenn sie sowas schreiben und zur Verfügung stellen MÜSSTEN, würden die 
Hersteller sich vermutlich bald zusammentun, um einheitliche, 
wiederverwertbare Parser bereitzustellen -- wenn sie halt selbst die 
Kosten ihrer Babylonismus tragen müssten. Aber vielleicht schaffen wir 
ja mit so einem System einen Anreiz zur rationelleren Zusammenarbeit mit 
den Kunden.
Manche Hersteller haben wohl auch Web-APIs (RPCs) für solche Zwecke. 
Aber das gibt's (bisher!!!) wohl noch nicht für Endkunden. Wird halt 
Zeit, dass ... ;-)

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Versionsnummer bezieht sich übrigens nicht auf die Scriptversion, 
sondern auf die Version des Datenformats, das geparst wird. Ein Bugfix 
des Scripts führt also nicht zur Erhöhung dieser Nummer, sondern eine 
Änderung der Bestätigungsmails.

Autor: didadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In eine komfortable Library-Verwaltung gehört natürlich auch eine 
Funktion zum Erstellen von Platinenheizungen. ;-)

Siehe hier: Beitrag "Re: Platine als Flächenheizung" (Script 
und Beispiel).

Ich will damit sagen, dass man sowas im Prinzip sehr leicht einbauen 
kann. Für diesen Fall ist die wesentliche Arbeit schon erledigt. Man 
bräuchte nur noch einen kleinen cgi-Wrapper, müsste den Footprint mit 
einem Symbol verknüpfen und dann das erstellte Teil an einem geeigneten 
Ort in der Datenbank speichern. (Allerdings habe ich noch keine Infos 
über das Footprint-Format und wie das mit dem Symbol zusammengestrickt 
wird.)

Autor: Bernd Wiebus (berndwiebus) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen.

Nachdem Rene die undankbare Aufgabe erledigt hat, die Ankerpunkte von 
unten  links in die Nähe des Symmetriepunktes zu verschieben und Fehler 
zu beseitigen, bin ich  hier gerade dabei, die Symbole alle umzubenennen 
und etwas Doku zu machen. Die ganzen "Big" fliegen raus in eine eigene 
library, für die, die gerne Plakate malen. :-)

Beim Rest verschwindet das "Small", und alle, auch die "BIG" (die auch 
Ihr "Big" behalten), erhalten einen Suffix der Form Tiefstrich REV 
aktuelle Revision Tiefstrich DATE Tag als Zahl monat als abgekürzter 
Name Jahreszahl. Beispiel: "_REVE_DATE15JUN2010".
Dann gibt es wenigstens keinen Ärger, wenn unterschiedliche Symbole mit 
gleichem Namen durcheinanderfliegen.

Einschub an sven P.:

>Also ich find, es gibt nix Hinderlicheres beim Arbeiten, als solch
>ellenlange Bezeichnungen. Mich hat das in der Target-Bibliothek schon
>immer gestört, drum hab ichs bei meinen Bibliotheken anders gemacht und
>nur noch kurze, knackige Präfixe benutzt.
>Bisher gabs noch keine Namenskollisionen ;-)

Hast Du mal Beispiele? Wie liesse sich das in KiCAD umsetzten, ohne 
Kollisionsfälle zu schaffen?

Einschub Ende

Die EN60617 Library wird noch mal in vergleichbarem Umfange wie vorher 
veröffentlicht. Wenn die "BIG" rausfliegen, ist sie gleich viel 
handlicher, und ich gehöre zu denen, die gerne alles zusammen bei Hand 
haben. Für die Organisationsfreaks werde ich gleichzeitig aber auch 
Abspaltungen daraus herstellen:
Einmal nur die EN60617 Symbole, und den Rest als "Needfull" library.
Um die EN60617 Biblothek nicht so furchtbar Aufzublähen, würde ich am 
liebsten auch die "array" Versionen, als Klemmen, widerstandsarrays, 
Dip-schalter ec, in eine extra Bibliothek auslagern......mal sehen.

Die ICs und Trafos bleiben erstmal so (bis das die auch den Suffix 
bekommen). Sind ja noch nicht viele, und eine weitere Library mit ein 
paar Optokopplern.

Die Doku wird wohl so aussehen, das ich alle Symbole der jeweiligen 
Library in Schaltpläne packe, die in SVG audgebe, Kommentare dazu 
schreibe (wenn nötig), sollte bei den EN60617 nicht nötig sein, aber bei 
den "Needfull Things" bestimmt. Weil der Sinn und Zweck von z.B. Dummy 
Symbolen sich Anfängern eben nicht immer von selber erschliesst.
Danilo Ucelli hätte für seine Website mit KiCAD Bibliotheken gerne eine 
Beschreibung als Text....ich grüble, ob da ein "Readme" langt......

Über die Organisation der Footprints habe ich mir noch nicht so große 
Gedanken gemacht. Wärend ich die Symbolbibliothek für mich persönlich 
als fast komplett ansehe (weil IC sind schnell gemacht, Kasten, Pinne 
dran und benahmsen), sehe ich noch riesen Lücken in den Footprints.

Insbesondere bei SMD. Und ich habe ein paar Ideen bezüglich 
"universalfotprints" um auf Experimentierplatinen das einzusetzten, was 
gerade da ist, oder wenn man aus ausschlachtmaterial was Bastelt. z.B. 
Extrem langezogene Keilförmige Pads, die für 0602 über 0805 bis 1206 
gehen. vieleicht noch Thruhole Löcher für 10mm Rastermass dazu.....
Universalfootprints für z.b. gleichzeitig für 8 Pinnig DIL oder SOIC 
sind problematischer als ich dachte. Ich muss mir dazu noch mal was 
überlegen und vieleicht auch testen.

Desweiteren noch ein paar Montagelöcher ohne Restring.....für die, die 
dabei Bauchschmerzen haben.
Es fehlen noch weitere Wago-Klemmen und vor allem Mate-N-Lock und 
Mini-Mate-N-Lock Stecker.

Hallo Puffel.

> Gibt es eigentlich außer diesem Thread eine Art Homepage, wo Bernd's
> Projekt etwas detaillierter beschrieben ist bzw. wo die ganzen Infos,
> Quellen und Diskussionen verfügbar sind?

Es gibt hier im Mikrocontroller Net einen Artikel:
http://www.mikrocontroller.net/articles/KiCAD

Einiges von meinem Kram landet auch noch hier:
http://www.darc.de/distrikte/l/02/con_technik_beit...
Der Update erfolgt aber recht langsam......es ist nicht meine Seite.

Und natürlich in der KiCAD-User Group bei Yahoo. Dort findet nicht nur 
eine diskussion statt, es können, für angemeldete Nutzer, auch files 
abgelegt werden.

Persönlich bin ich in Punkto Perogrammieren, Networking und Datenbanken 
nicht wirklich kompetent. Darum habe ich mir eine eigene HP bis jetzt 
verkniffen.

Zusammen mit den librarys werde ich meine Notitzensammlung noch 
veröffentlichen.

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic

Autor: Rene B. (yob) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bernd,

ich poste gleich mal hier rein. Zum aktuellen Sand meinerseits.

> Im Moment bin ich gerade dabei mich etwas in Python einzulesen und
> > meinen Vorschlag zur Versionierung von einzelnen KiCad-Symbolen selbst
> > umzusetzen.
> >
> > Beitrag "Re: [KiCad] Bibliotheksaufbau - Konzeptideen gesucht"
> >

> > An neuen Symbolen sind ein paar  Operationsverstärker nach IEC60617 mit
> > unterschiedlichen Pinnummer in Arbeit, welche ich ganz gerne beisteuern
> > würde.

Bernd:

Beim Rest verschwindet das "Small", und alle (auch die "BIG" erhalten
einen Suffix der Form Tiefstrich REV aktuelle Revision Tiefstrich DATE
Tag als Zahl monat als abgekürzter Name Jahreszahl. Beispiel:
"_REVE_DATE15JUN2010".
Dann gibt es wenigstens keinen Ärger, wenn unterschiedliche Symbole mit
gleichem Namen durcheinanderfliegen.

Rene:
> Das ist gut. Es würde mir reichen wenn du dies nur innerhalb der
> Bibliothek machst.

Bernd:

Die EN60617 Library wird noch mal in vergleichbarem Umfange wie vorher
veröffentlicht. Wenn die "BIG" rausfliegen, ist sie gleich viel
handlicher, und ich gehöre zu denen, die gerne alles zusammen bei Hand
haben. Für die Organisationsfreaks werde ich gleichzeitig aber auch
Abspaltungen daraus herstellen:

Rene:
Mein Vorschlag. Erstelle nur die große Bibliothek das separieren von 
einzelnen Symbolen mache ich per Script (mein 1. Schritt mit Python) 
denn ich kenn den Aufwand dies von Hand durchzuführen ;-). Nach einer 
1/2 Stunden hast du keine Lust mehr darauf ;-).Ich schick dir die 
einzelnen Dateien wieder und du brauchst diese nur noch umbennen 
(suffix-erweiterung), fertig.

Später gibts das script hier sowieso.

PS: Python-Crackheads, lasst mich was lernen und postest nicht voreilg 
;-).

Bernd:
Danke für Deine Mühe, die Ankerpunkte zu verschieben. Allerdings ist es
nicht immer einfach, eine Symmetrie zu finden, bzw. zu treffen.
In einigen Fällen scheint es sinnvoller zu sein, Lediglich die symmetrie
bezüglich der Pinne zu beachten. Aber das hängt am Einzelfall und auch
an persönlichen Vorlieben.....
Was sich als unglücklich herausgestellt hat, ist, wegen der Symmetrie
vom 50mil Raster abzuweichen. Hier würde ich sagen, Raster geht vor
Symmetrie. Es ist mehr Klickarbeit, das Raster zum Anschliessen zu
ändern, als ein Symbol etwas zu verschieben.
Wie siehst Du das?

Rene:
Ich habe versucht maximal nur eine Rastestufe runter zugehen, so dass 
man entweder 50mil oder 25mil vorfindet. Ich gebe dir recht das dies 
nicht ganz so optimal ist aufgrund des stetigen Raster umschaltens. Ich 
schlage vor alles auf 50mil anzupassen und gut ist. Das ist am 
einfachsten und geht am schnellsten zu verdrahten. Um Symetrie mache ich 
mir keine Sorgen weil diese manchmal auch hinderlich sein kann bzw. ein 
Ankerpunkt unten Rechts idealer gewesen wäre. Den Ankerpunkt sollten 
einfach nach Erfahrung setzen und erst bei größerer Nachfrage ändern. 
Wir setzen den ja nicht sonst wohin.

Du musst den Anker aber nicht gleich bei allen ändern und die 50mil 
Anpassung drchführen. Ich würde mich da wieder dran beiteiligen!

Bernd:
Hast Du irgendwelche Ideen zur Dokumentation?

Die Doku wird wohl so aussehen, das ich alle Symbole der jeweiligen
Library in Schaltpläne packe, die in SVG audgebe, kommentare dazu
schreibe (wenn nötig), sollte bei den EN60617 nicht nötig sein, aber bei
den "Needfull Things" bestimmt. Weil der Sinn und Zweck von z.B. Dummy
Symbolen sich Anfängern eben nicht immer von selber erschliesst.

Rene:
Prinzipiell würde ich OpenOffice verwenden wollen. Wobei ich beruflich 
leider MS arbeiten muss und da entsprechend fixer bin aber en 
Video-Tutorial für OO ist unterwegs.

Kleine Bildchen der Symbole & Footprints ansich ist immer gut, auch für 
eine zukünftige Datenbank als Vorschau zum Beispiel. Dies muss ich aber 
noch anschauen wie man das Zeit sparend umsetzten kann, diese Bilder 
zugenerien.(Mach ich heut Abend mal!)

Das muss ich alles mal noch sichten bzw. genauer unter die Lupe nehmen. 
->

>Über die Organisation der Footprints habe ich mir noch nicht so große
>Gedanken gemacht. Wärend ich die Symbolbibliothek mür mich persönlich
>als fast komplett ansehe (weil IC sind schnell gemacht, Kasten, Pinne
>dran und benahmsen), sehe ich noch riesen Lücken in den Footprints.

>Insbesondere bei SMD. Und ich habe ein paar Ideen bezüglich
>"universalfotprints" um auf Experimentierplatinen das einzusetzten, was
>gerade da ist, oder wenn man aus ausschlachtmaterial was Bastelt. z.B.
>Extrem langezogene Keilförmige Pads, die für 0602 über 0805 bis 1206
>gehen. vieleicht noch Thruhole Löcher für 10mm Rastermass dazu.....
>Universalfootprints für z.b. gleichzeitig für 8 Pinnig DIL oder SOIC
>sind problematischer als ich dachte. Ich muss mir dazu noch mal was
>überlegen und vieleicht auch testen.

>Desweiteren noch ein paar Montagelöcher ohne Restring.....für die, die
>dabei Bauchschmerzen haben.
>Es fehlen noch weitere Wago-Klemmen und vor allem Mate-N-Lock und
>Mini-Mate-N-Lock Stecker.

>Kennst Du
>http://www.mikrocontroller.net/wikifiles/4/41/Buil...
>und wenn ja, was hälst Du davon?

Nun aber erstmal etwas schaffen.

VG, Rene

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

wie ist denn der SVN-Status zu den kicad-Files? Kann man schon was 
auschecken/angucken, und wenn ja, wo?

Ich bin hier auch etwas weitergekommen. Habe mit dem web2py-Framework 
experimentiert und die Datenkbankstruktur soweit mit allen 
Kreuzreferenzen lose festgeklopft. web2py ist zwar etwas 
schwergewichtiger, aber macht Datenbank-Migrationen und Erweiterungen zu 
einem Klacks, da die Struktur der Datenbank im Code selbst beschrieben 
wird. Scheint mir bisher relativ Fehler-unanfaellig zu sein (zumindest 
mit sqlite3). Fazit, die Wahl ist auf web2py gefallen, das System ist 
wirklich extrem durchdacht.

Ich arbeite gerade noch am Aufschalten einer ersten Testversion, das 
Problem liegt noch bei meinem Provider mit fehlender Unterstuetzung fuer 
Apache und Python, momentan laesst sich das ganze nur per CGI aufrufen 
und hat noch ein paar Boecke mit Permissions. Wenn jemand das ganze mit 
Apache/WSGI und VirtualHosts hosten mag und kann, bitte laut schreien.

Das Parsing von kicad->XML ist fuer Libraries schon relativ weit 
fortgeschritten, dank SimpleParse. Kann/sollte bald mal ins SVN...

Gruesse,

- Strubi

Autor: Mine Fields (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe noch eine kleine Anmerkung zu den Bauteilen:

Man solle bei einigen Standardbauteilen vielleicht auch die Möglichkeit 
geben, direkt zusätzliche Parameter anzugeben, die man sich dann auf dem 
Schaltplan anzeigen lassen kann. Manuell geht das ja (siehe Screenshot 
im Anhang), aber es wäre wünschenswert, wenn es dafür schon eine 
Voreinstellung gibt.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Gemeinde,

ich habe mal eine Sandbox aufgeschaltet als Beispiel fuer eine Datenbank 
- damit sich die Spam- und Crawlerbots da nicht gerade reinhaken:

http://dclib

dann kommt ein punkt, dann:

station5.ch/parts/

Was leider noch nicht online funktioniert, ist die Konversion von kicad 
nach XML-files, da mein Hoster die Installation von eigenen 
Python-Binaries nicht erlaubt. Im Prinzip geht das so, dass man sich 
einloggt, eine kicad-.lib hochlaedt, diese wird in einzelne Elemente 
geparst und die Datenbank mit den XML-Daten gefuellt.

Anschauen kann man bisher nur die "Symbols". Braucht einen SVG-faehigen 
Browser, getestet ist nur Firefox, auf anderen laden vermutlich die 
Symbol-Grafiken nicht. Und ohne Javascript keinen Spass. Die Grafiken 
werden aus den XML-Daten erzeugt, Bounding Box stimmt noch nicht, und es 
kann dauern, da die Aufrufe ueber CGI gehen.

Bitte keine langen Fehlerlisten oder Feature requests posten, das ganze 
ist eine langsam voranschreitende Baustelle (wir haben ja auch alle noch 
ein undankbares, wahres Leben).

Nehme gerne weitere Parser-Module an, und baue sie testweise ein. Alles 
was in pur-Python geht, laesst sich prima einbauen um die Datenbank zu 
fuellen.

Gruesse,

- Strubi

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.