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

Hallo Adlerauge,

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

VG, Rene

Besten Dank Adlerauge.

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

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

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?

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.

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)

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 ;-)

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

Dies wäre der 1. Meilenstein ;).

VG, Rene

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.

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

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

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)

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

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

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.

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.

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

Hier noch ein Bild mit veränderter Description in Kicad.

---
VG, Rene

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

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.

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.

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

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

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

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.