Hallo zusammen,
vielleicht finden sich hier ein paar Mitstreiter, die mit mir zusammen
einen Vault-Server für E-CAD-Programme entwickeln wollen.
Was ist ein Vault-Server?
Altium User kennen das vielleicht: Ein Server,(ein Programm also was auf
einem Server läuft) in dem Bauteile und Schaltplansymbole u.s.w.
gehostet werden können.
Warum das Ganze? Das geht doch jetzt eh schon?
Ja, aber die Libraries können so an ZENTRALER STELLE verwaltet werden.
Alle Bauelemente stehen unter Versionskontrolle.
Es gibt ein LiveCycleManagement, sprich man kann jedes Bauteil
freigeben,z.B. für Schaltplan, für Prototypen und für die Produktion.
Warum nicht fertig kaufen?
Weil es unverschämt teuer ist. z.B. eine Grundversion nur für Bauteile
für 900Euro plus 150 Euro pro Jahr und User....
Warum "OPEN":
Wenn es möglich wäre, das Platformunabhängig hinzubekommen, könnten
alle, also KICAD- Eagle- Altium- User davon profitieren....
Wie geht so was im Detail:
Na ja, eine Datenbank liegt dem Server zugrunde. Die Bauteile werden je
einzeln in einer Lib im Vault gespeichert.
Nur wie man die elegant aus der Lib ins Programm bekommt, weiss ich noch
nicht so genau... :-)
>vielleicht finden sich hier ein paar Mitstreiter, die mit mir zusammen>einen Vault-Server für E-CAD-Programme entwickeln wollen.
Träum weiter.
Und was hat das mit Projekte und Code zu tun?
Eigentlich eine Nette Idee aber mir kommen da einige Fragen:
Wie macht man die Integration in kommerziellen Programmen (Eagle /
Altium)
Woher kommen die "ersten" Bauteile?
In Welchen Format willst du die Bauteile speichern?
Je nachdem was du so vor hast / Welche Programmiersprache du einsetzen
willst wäre ich dabei...
Gruß
Christopher
Nunja, für Eagle wärs denkbar über die XML-Daten.
Das lässt sich gut versionieren und ein (einfacher) parser, der das
Bauteil nur rendern kann, ist auch nicht sooo sonderlich komplex.
Solange das Tool ein definiertes (Text-)Format für die Bibliotheken hat,
ist das sicher alles machbar.
Muss dann halt festgelegt sein, wie die zuordnung
Library-Bauteil<->Katalogbauteil gelöst wird. Grad bei Eagle ist das
immer wieder spaßig (passive zB). Ich grüble da schon länger an was
ähnlichem. Wobei das mehr auf BOM-Management und Lagerhaltung abgezielt
hat (inkl Überprüfen von Component-Value Tupeln gegen die Datenbank).
Ich weiss zwar grad nciht, wieviel Zeit ich dafür frei hab, aber
Interesse wäre da. Das ganze ginge, denke ich, ohnehin in Richtung ein
Server, ein Client, diverse Adapter-Anwendungen, die es mit dem eCAD
koppeln.
In eagle könnte man recht viel Funktionalität als ULP integrieren. Wie
das bei Altium und Co aussieht - keine Ahnung. Plugins und Scripting
kann das ja wohl.
Was ich mir nciht ganz sicher bin, ist ob/wie man die Konvertierung
zwischen Tools löst. Ich denke eher, dass man da pro Programm separate
Bauteile haben wird, diese können ja wiederum auf eine gemeinsame Liste
"echter" Bauelemente verlinkt sein.
Bei Implementation in C++/Qt wäre ich interessiert mitzuwirken.
Ich dachte eher an ein Universalbauteil, das dann je nach Zielprogramm
umgewandelt wird. Außerdem fände ich es schlau zwischen Footprint und
Schaltplan-Symbol zu unterscheiden (Wie bei KiCad)
Grüße
Christopher schrieb:> Ich dachte eher an ein Universalbauteil, das dann je nach> Zielprogramm> umgewandelt wird.
Klingt a weng komplizierter und wäre imho eher ein Feature "für später"
> Außerdem fände ich es schlau zwischen Footprint und> Schaltplan-Symbol zu unterscheiden (Wie bei KiCad)
Tut das zB eagle nicht auch?
Ferner,
will man das (ich nenne es mal) Storage-Backend als Datenbank oder nutz
man ggf intern eine etablierte Versionsverwaltung wie zB git, um die
Daten zu versionieren. Approvals gingen dan gegen die commit id des
Repo. Damit kann man ggf sogar den Großteil des Servers erschlagen, da
git bereits Funktionen für Remote Repos mitbringt. Nutzt man für den
Rest der Datenhaltung Textfiles oder ähnliches, wäre so ein System
denkbar, das das alles nciht nur Open sondern auf Basis bekannter und
zuverlässiger Technologien ermöglicht.
zB Object storage via GIT, signoff vie gpg-key etc.
Vorteil man muss "nur noch" einen CLient entwickeln, der das alles
bündelt und die gültige working library aus den objekten im git gemäß
vorgaben aufbaut. Di git-versionierung erlaubt ein beliebiges vor-und
zurück in der historie, auch zig branches jucken git nicht ernsthaft.
Unkomplex ist das auch nciht, aber man muss faktisch keinen dedizierten
server mehr entwickeln
Nachteil: man hat einen haufen dependencies (muss man dann halt unter
unix dem paketmanager mitteilen bzw man liefert sie unter windows im
programmverzeichnis mit)
-->Andreas Lang:
Ob man gleich zu Anfang Bauteile zwischen den Tools austauschen kann,
wäre schon sehr sportlich.
Ich denke, man müßte vielleicht die Bauteile in Ihren Libraries
speichern...
-->Der Altium Component Vault erwartet jedenfalls für jedes Bauteil eine
eingene Lib, die dann "automatisch" in eine Versionsverwaltung wandert.
Das wäre ja theoretisch für jedes ECAD-Tool möglich. Sprich: In der
Datenbank wird für jedes Teil eine eigene Lib gespeichert, dabei wäre es
wurscht, ob es sich um ein Eagle- Altium -Kicad -oder sonst was Bauteil
handelt.
Als Anwender merkt man halt nix davon. Das plazieren über den Vault in
den Schaltplan bzw. Layout müßte dann warscheinlich über ein Script
erfolgen. Das ginge zumindest bei Altium und Eagle und Pads. Bei den
anderen Programmen weiss ich das nicht.
--> Cristopher:
Das mit dem Universalbauteil ergäbe sich quasi von selbst.
Es wäre ja in der Datenbank ein leichtes, für ein Bauteil verschiedene
Footprints und Schaltplansymbole für verschiedene ECAD-Tools zu
hinterlegen.
Die ersten Bauteile sind kein Problem, die gibt es ja schon, jeder hat
ja seine Libs, mit seinen Bauteilen, die werden dann halt nach und nach
in den Vault gebracht.
Hier mal ein Link zur Übersicht:
http://techdocs.altium.com/display/DMAN/Vault-Driven+Electronics+Design
