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... :-)
:
Verschoben durch User
>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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.