Hallo zusammen,
Ich frage mich schon lange, wie ein CAD aufgebaut ist, wie man sowas
programmiert. Nun dachte ich, ich mach mich mal schlau und probiere ein
bisschen rum.
Mal angenommen, ich möchte etwas ähnliches wie Eagle programmieren :-)
Also einmal den Schaltplaneditor, und einmal den Layouteditor. Und als
Sahnehäubchen noch eine 3D Ansicht für die fertige Platine :-)
Zur Sicherheit (man weiss hier im Forum ja nie...): Ich will nicht ein
besseres Eagle, Target oder KiCAD programmieren (würde ich schon gerne,
aber ich weiss dass es wenig realistisch ist). Ich will mich nur mal mit
der Materie auseinandersetzen, und zwar vorzugsweise nicht planlos,
sondern schon mit einem (hochgesteckten) Ziel vor Augen. Ein Scheitern
ist völlig egal, es geht um den Lerneffekt.
Ich würde dazu gerne Qt/C++ verwenden. C++ kann ich einigermassen, mit
Qt habe ich noch nicht sehr viel Erfahrung (was ich aber ändern möchte).
Nun stellt sich mir die Frage, ob es wohl ein gescheites Framework gibt,
das mir in Sachen CAD viel Arbeit abnehmen würde. Im Internet konnte ich
zu dem Thema leider nicht gerade viel Informationen finden (vor allem
auf Qt bezogen).
Meine Fragen wären nun erstmal:
Mit was würde man beginnen, wenn man so ein Layoutprogramm programmieren
möchte? Gibt es Frameworks, die sich hierfür anbieten würden? Welche
Aufgaben übernehmen die existierenden (Qt-)Komponenten, um was muss man
sich selber kümmern (Zoomen, Elemente mit der Maus auswählen,...)?
Ist Qt überhaupt eine geschickte Wahl für so ein Vorhaben?
Dass z.B. das Zoomen eines grossen Layouts flüssig und ohne Ruckler
möglich sein soll, versteht sich von selbst.
Ich würde mich auf Tipps freuen!
mfg
Hi,
vill. mal im Bereich der Game-Engines umschauen gerade wenn die 2D/3D
können brauchst hast könntest du weniger Probleme mit dem 3D Modus
bekommen.
gz
Ich vermute die meisten Projekte schreiben sich ihre "Frameworks" dafür
selbst, d.h. bauen ein System das die immer die gleichen Teilaufgaben
abstrahiert. Wie viel man dann z. B. QT übernehmen lässt ist (auch)
Geschmackssache. Am Beispiel eines Uniprojektes mit QT war bei uns im
Studium z.b. zu beobachten das einige Teams ziemlich viel mit passend
erzeugten Widgets erledigt haben, während andere Teams viel selbst
implementiert haben, d.h. nur wenige Widgets und auf diesen dann
fleissig rumgemalt.
Ist vermutlich auch Geschmackssache und hängt von den eigenen Zielen und
Fähigkeiten ab, gerade bei einem "Lernprojekt".
Bei Qt kannst du dir mal QGraphicsScene anschauen.
ingo schrieb:> Kannst ja mal hier in die Quellen (der Community Edition) schmökern,> http://de.wikipedia.org/wiki/QCad
Ich habe mich auch schon ein bisschen umgeschaut bei existierenden
OpenSource CADs. Das Problem ist allerdings, dass man eine Ewigkeit
braucht, bis man nur mal ein bisschen eine Vorstellung davon bekommt,
wie das Ganze aufgebaut ist :-) Das, was ich bisher so gesehen habe,
scheinen wohl alles Eigenentwicklungen zu sein, die extra für das
jeweilige Programm geschrieben wurden. Mit sowas möchte ich eigentlich
lieber nicht arbeiten.
FPGA-Takt schrieb im Beitrag #3029547:
> vill. mal im Bereich der Game-Engines umschauen gerade wenn die 2D/3D> können brauchst hast könntest du weniger Probleme mit dem 3D Modus> bekommen.
Naja, ich denke es würde sowieso Sinn machen, wenn man die 3D-Ansicht
unabhängig von den 2D-Ansichten (Schaltplan & Layout) bauen würde. In
der 3D Ansicht möchte man ja auch ganz andere Sachen sehen, als in der
2D-Ansicht. Für die 3D-Ansicht wäre eine Art Game-Engine vielleicht
schon nicht schlecht, für die 2D-Ansichten aber vermutlich ziemlich
übertrieben.
adsf schrieb:> Ist vermutlich auch Geschmackssache und hängt von den eigenen Zielen und> Fähigkeiten ab, gerade bei einem "Lernprojekt".
Ja, das stimmt wohl... Mein Problem ist momentan einfach, dass ich nicht
aufs falsche Pferd setzen möchte wenn ich mit sowas beginne :-) Nicht,
dass ich was verwende das bei 20 Grafikobjekten noch wunderbar
funktioniert, bei über 1000 Objekten aber total versagt.
> Bei Qt kannst du dir mal QGraphicsScene anschauen.
Hmm über das "Ding" habe ich mich schon früher mal ein bisschen
informiert. Gefällt mir eigentlich ganz gut, wäre sowas auch für ein
grosses Layout geeignet wo es extrem viele (kleine) Grafikobjekte gibt?
So eine Leiterplatte besteht ja aus zig Linien, Flächen, Kreise, ...
Also sowas in der Art: Ein QGraphicsView aufs Formular knallen, und dort
ein QGraphicsScene mit zig Grafikobjekten anzeigen lassen. Wäre das
schonmal ein guter Ansatz?
Das Zeichnen der Leiterbahnen usw. ist dann ja alles auf diese Weise
möglich:
1
rect=scene->addRect(...);
Grössere Probleme sehe ich aber z.B. bei einem Gitter (das "unendlich"
gross sein soll), Raster beim Verschieben von Objekten, und Zoom. Ich
glaube ich fang einfach mal an mit der QGraphicScene rumzuspielen :-)
mfg
ich bau genau sowas (schematic/layout-editor) für meine diss...
grundsätzlich wirklich kein problem mit der graphics-view/scene.
das unendliche gitter lässt sich am einfachsten über die
draw-background-methode. kann dir später da was schicken.
objekte mach ich über die qgraphicsitemgroup. werde ich warscheinlich
noch auf ein normales item ändern, da die itemgroup irgendwie komisch
ist (wird aber auch so in der doku beschrieben).
item-definition (was ist auf den einzelnen layern+pin/pad definitionen,
texte,...) habe ich in xml gepackt. selbiges mit den einzelnen projekt
daten, simulations-profilen,... geht über die dom-lib, die die qt
mitbringt recht schön.
soweit alles nicht weiter schwierig und aufwendig... bei den netzen ist
das anders. da ist mir noch nicht wirklich etwas gutes/praktikables
eingefallen (punkte, des netzes, wie verbunden, welches bauteil/pin/pad
auf welchem netz und vor allem netz am schematic und layout verwalten).
muss mir das demnächst anschaun, wie eagle und kicad das macht.
das nette an der graphics-scene ist übrigends, das drucken und
pdf-generieren quasi gratis mit geht.
73
Ich gehörte zu einem Team das alles selber gemalt hat, deswegen habe ich
da nicht so die Ahnung ;)
Du kannst eventuell auch die GraphicsScene mit "selbstgezeichneten"
Dingen mischen?
Ansonsten, mach dir frühzeitig Gedanken wie du Darstellung und
abstraktes Modell verbindest:
-ein Widerstand sieht auf dem Schaltplan anders aus als auf dem Layout
-ebenso eine Leiterbahn, da kann das noch viel komplizierter sein (auf
dem Schaltplan ist eine Linie, auf dem Layoutplan eine Leiterbahn, eine
Durchkontaktierung, noch eine Leiterbahn, ...)
-du solltest weitere Bauteile/Bauteildesigns einfach hinzufügen können
ohne überall im Quelltext was anpassen zu müssen
...
leider zu langsam.... also extra post:
wegen der geschwindigkeit würde ich mir nicht so viele gedanken
machen... ab 50k punkte in einem polygon wirds richtig langsam... bis
10k punkte solltest du nicht wirklich ruckeln merken.
für die performance müsstest du schon verdammt fitt in algorithmen
design sein, das du das selber besser kannst (mit anti-aliasing,...)
die opengl-beschleunigte scene (qt5) sollte auf jeden fall besser sein.
Habe das aber aus zeitgründen noch nicht probiert.
73
Vielen Dank für die Antworten.
Jetzt habe ich wenigstens mal einen Anhaltspunkt, womit ich beginnen
kann. Vorher stand ich einfach total im Leeren, weil ich nicht
abschätzen konnte wie leistungsstark die von QT bereitgestellten
Komponenten sind. Aber das scheint nun ja mit
QGraphicsView/QGraphicsScene soweit möglich zu sein. Wie gesagt, ich
setze ungern von Anfang an aufs falsche Pferd ;-)
Die Verwaltung der ganzen Netze ist sicher ein Knackpunkt, da habt ihr
Recht. Viele Gedanken dazu habe ich mir noch nicht gemacht. Die einzige
Idee ist bisher, dass man die Verbindungen vielleicht in einer SQLite
Datenbank ablegen könnte ;-) Aber erstmal möchte ich mich ein bisschen
mit der Grafik beschäftigen, denn ich sehe dort für mich die grösste
Hürde.
Also ich werde mich dann wohl mal mit QGraphicsScene beschäftigen. Mal
schauen ob das was wird ;-)
mfg
P.S.
Ideen für ein Schema/Layoutprogramm hätte ich soooo viele :-) Ich fand
bisher einfach noch kein Programm das mir richtig gefällt. Eagle finde
ich nicht schlecht, aber die Bauteilebibliothek ist grässlich.
Die Motivation ist also da, aber ob die Zeit, das Können und der
Durchhaltewillen auch da sind, das ist eine andere Frage ;-)
Aber versuchen kostet ja nix (ausser etwas Zeit)...
sqlite habe ich ursprünglich auch verwendet... war aber eine sackgasse!
die bauteil-definitionen in xml gestalten sich wesentlich einfacher (vor
allem durch die dom-lib!)
übrigends gibts auch ein svg-item. das kann leider aber keine effekte
und ist so auch nicht der bringer! webkit als item integrieren geht, ist
aber auch nicht soo toll.
besser man definiert sich tags für polygon, text, linie und diverse
layer und parst dann seine "vektor-grafik" einfach so.
unbedingt würde ich mir auch für jedes bauteil einen reference-point
definieren (und wenns implizit 0,0 ist), damit du vernünftig auf ein
raster positionieren kannst.
rotieren,... von elementen macht dir dann die lib, du musst du wissen um
welchen punkt es sich drehen muss und wo du dann alles haben willst.
73
Hans Wilhelm schrieb:> mm in punkte für die scene umrechnen geht übrigends mit *72/25.2
Bist du sicher das die 72 von Qt fix gesetzt sind und nicht etwa
Einstellungssache? Das wäre nämlich erheblich sinnvoller ;)
Vielen Dank für die Tipps!
Ich habe mal eine Klasse von QGraphicsView abgeleitet, welche nachher
als "CADView" verwendet werden soll.
Das Hintergrundgitter funktioniert super, und auch Zoom und Pan habe ich
von hier eingebaut:
http://www.qtcentre.org/wiki/index.php?title=QGraphicsView:_Smooth_Panning_and_Zooming
Auch das funktioniert soweit schon sehr gut. Nur merkt man bisher noch,
dass die QGraphicsScene nur eine endliche Grösse hat, denn wenn man
rauszoomt sind die Grafiken immer in der Mitte der QGraphicsView,
verschieben geht dann nicht mehr. Das nervt bei einem CAD ziemlich, ein
"unendlich grosser" Zeichenbereich ist da viel angenehmer. Aber ich bin
mir sicher, auch das ist ein lösbares Problem :-)
Bisher bin ich schonmal sehr positiv überrascht, hätte nicht gedacht
dass man innert wenigen Stunden bereits so ein Ergebnis bekommt.
Ein Knackpunkt dürfte aber vermutlich dann noch das Markieren von
Zeichenobjekten sein. Viele Sachen (z.B. Fadenkreuze der Nullpunkte)
werden ja mit "unendlich dünner" Linie gezeichnet, ein Mausklick der
leicht neben so einer Linie getätigt wird, müsste dann auch dieser Linie
zugeordnet werden können. Ich vermute mal, man muss da von Hand
ausrechnen, welches Element nun am nächsten beim Mausklick liegt?
Hans Wilhelm schrieb:> mm in punkte für die scene umrechnen geht übrigends mit *72/25.2
25.2? Nicht 25.4 (25.4mm = 1 Zoll)?
Hiho und guten morgen :-)
Habe nit alles gelesen , also schonmal sry muss jetzt los zu arbeit -_-
Also QGraphicsView klingt gut als einstieg , darin implementierst du nen
QGLWidget, damit du nen openGL2 Painter hast :-)
Und schon läuft das Ding. Ok bischen openGL solltest schon können, aber
dann kannste alles von 2D bis 3D machen können in deinem widget.
Bei Fragen einfach Fragen :-)
Guten Moin und .....
Mfg Player.
Axel Jäger schrieb:> Das mal anschauen: http://doc.qt.digia.com/qt/demos-chip.html
Ahh das sieht nicht schlecht aus, danke!
Jean Player schrieb:> Also QGraphicsView klingt gut als einstieg , darin implementierst du nen> QGLWidget, damit du nen openGL2 Painter hast :-)
Meinst du etwa das hier, das ich in der oben genannten Demo fand?
adsf schrieb:> Hans Wilhelm schrieb:>> mm in punkte für die scene umrechnen geht übrigends mit *72/25.2>> Bist du sicher das die 72 von Qt fix gesetzt sind und nicht etwa> Einstellungssache? Das wäre nämlich erheblich sinnvoller ;)
Wie man's nimmt. Ein "Punkt" ist nun mal 1/72 Zoll.
http://de.wikipedia.org/wiki/Schriftgrad#Das_DTP-Punkt-System
Qt sollte den auch so verwenden, sofern das System mit dem echten
DPI-Wert des Monitors arbeitet. Und wenn nicht, dann ist das System
falsch eingestellt. Wozu sollte man das ausschließlich für Qt-Programme
dann nochmal umbiegen können?
Sebastian S. schrieb:> Open CASCADE ist so ein Framework. Mächtig, aber nicht einfach, hab ich> den Eindruck.> http://www.opencascade.org/
Ja ich glaube das ist wohl etwas zu umfangreich für mich. Ausserdem habe
ich grad gemerkt dass es mir ziemlich Spass macht, sowas selbst zu bauen
:-)
Bisher habe ich schonmal folgendes hingekriegt (mit viel Hilfe des
Internets :-)
- Bauteile können verschoben werden
- Bauteile werden immer am Raster ausgerichtet
- Hintergrund wahlweise mit Punkten, Gitter oder deaktiviert
- Zoomen mit Mausrad
Nur ein Problem habe ich beim Zoomen noch. Ich verwende diesen Code zum
Zoomen:
http://www.qtcentre.org/wiki/index.php?title=QGraphicsView:_Smooth_Panning_and_Zooming
Solange die QGraphicScene grösser als den sichetbaren Bereich der
QGraphicsView ist, funktioniert es perfekt. Sobald man aber zu weit
rauszoomt, so dass mindestens eine Kante der QGraphicScene innerhalb der
QGraphicsView ist, wird die QGraphicScene automatisch in der
QGraphicScene zentriert (und der entsprechende Scrollbalken
verschwindet, da der gesamte Inhalt sichtbar ist).
Das mag beim Zoomen von Bildern so gewünscht sein, doch in einem CAD
möchte man beim Zoomen nicht "gestört" werden, auch wenn man ins Nirvana
rauszoomt.
Weiss vielleicht grad jemand, wie ich das automatische Zentrieren
unterbinden kann?
adsf schrieb:> Suche ich dir morgen raus, ich glaube da hab ich einen Codeschnippsel> rumfliegen.
Super, vielen Dank! :-)
...zu dieser späten Stunde eine Antwort wie aus der Pistole geschossen,
nicht schlecht xD
Hm, tut mir leid, war doch nicht ganz das was du wolltest, aber
eventuell kann man es trotzdem mit diesen Funktionen einstellen, schau
mal in die Doku dazu.
setHorizontalScrollBarPolicy()
setVerticalScrollBarPolicy()
setTransformationAnchor()
setAlignment();
m_gscene->setSceneRect()
setViewportMargins()
setViewportUpdateMode()
Hmm ich glaube das ist gar nicht möglich, die QGraphicsView zentriert
die QGraphicScene immer automatisch, sobald die Scrollbalken weg sind.
In der Doku steht bei centerOn() auch, dass das Zentrum nur dann gesetzt
werden kann, wenn die Szene grösser ist als die View, anderenfalls wird
die Szene einfach zentriert. Ein Hinweis darauf, dass sich das
deaktivieren lässt, konnte ich nicht finden.
Ich probiers mal so, dass die Szene halt automatisch vergrössert wird,
sobald man zu weit rauszoomt, und evtl. wieder verkleinert wird beim
reinzoomen. Ich denke mal so sollte es funktionieren...
Danke trotzdem für deine Mühe, adsf.
mfg
Also ich habe jetzt einfach das SceneRect sehr gross gemacht. Eagle
macht es wohl auch nicht viel anders, da ist die verfügbare
Schaltplanfläche auch beschränkt habe ich bemerkt.
In Sachen Grafik bin ich nun doch zuversichtlich dass ich das
einigermassen hinkriege. Die QGraphicsView hat ja auch schon nette
Funktionen mit eingebaut, wie z.B. QGraphicsView::Items() um alle
Elemente an einer bestimmten Koordinate zu ermitteln.
Ein Design Rule Check dürfte dann jedoch etwas komplizierter werden ;-)
Momentan mache ich mir eher Gedanken über die Bauteilebibliothek und vor
allem deren Speicherung. Für die Bibliothek würde ich gerne eine
Datenbank verwenden, dann kann man die Bibliothek nämlich auf einem
MySQL Server haben, wo dann verschiedene Clients darauf zugreifen
können.
Target scheint es auch so zu machen, die Schaltplansymbole und
Footprints werden wohl in Blobs gespeichert. In was für einem Format die
Daten aber abgelegt werden, habe ich nicht rausgefunden... "file" meint
das hier:
1
VAX COFF executable - version 8710
"dmg2iso" weigert sich aber die Datei umwandeln:
1
ERROR: dmg image is corrupted
Ein Schaltplansymbol könnte man ja eigentlich mit simplen Textbefehlen
beschreiben, z.B. so ähnlich wie es in KiCAD gemacht wird:
1
DEF LM4674 U 0 40 Y Y 1 F N
2
F0 "U" 0 -750 60 H V C C
3
F1 "LM4674" 0 750 60 H V C C
4
DRAW
5
S -350 650 350 -650 0 1 0 N
6
X BACK 17 650 -500 300 L 50 50 1 1 w
7
X BACK 17 650 -500 300 L 50 50 1 2 w
8
X OUTLA 7 650 -200 300 L 50 50 1 1 O
9
X OUTLB 8 650 -100 300 L 50 50 1 1 O
10
X PGND 11 650 400 300 L 50 50 1 1 w
11
X PVDD 6 650 500 300 L 50 50 1 1 W
12
X OUTLB 7 700 -450 300 L 50 50 1 2 O
13
ENDDRAW
14
ENDDEF
Um Platz zu sparen könnte man es dann vor dem Ablegen in der Datenbank
noch komprimieren, ich denke aber mal das ist nicht wirklich notwendig.
Wenn man es unkomprimiert speichert, bräuchte man dann eigentlich ja
kein BLOB-Feld, ein Text-Feld würde es doch dann auch tun wenn ich mich
nicht täusche (bin nicht soo der Datenbank Spezialist...).
Falls dazu jemand noch Tipps hat, immer her damit :-)
mfg
Thomas schrieb:> Ich würde Symbole, Footprints und Bauelemente getrennt als XML anlegen.
Eigentlich bin ich zwar ein Fan von Klartext-Dateien für alles Mögliche,
für die Bauteilbibliothek möchte ich jedoch aus zwei Gründen eine
Datenbank verwenden:
- Die Bibliothek kann per DB-Server im ganzen Netzwerk verwendet werden
- Man kann sehr gut Datensätze untereinander verlinken (Jeder Datensatz
hat eine eindeutige ID, die per Foreign Keys in anderen Datensätzen
verlinkt werden kann), somit ist es möglich eine sehr gut strukturierte
Bauteilebibliothek zu erstellen.
Den ersten Punkt könnte man zwar auch mit einer Dateifreigabe der
XML-Dateien erledigen, das finde ich aber nicht sehr schön. Und damit
man nicht zwingend einen MySQL Server braucht, lässt sich die Bibliothek
auch in einer SQLite Datenbank speichern.
Ausserdem muss man ja nicht auf XML verzichten wenn man eine DB benutzt
- Die XML-Dateien lassen sich ja auch in Blob-Feldern speichern.
Die Bauteileverwaltung von Eagle macht mich echt wahnsinnig, und vom
Erstellen eigener Bauteile wollen wir gar nicht erst reden...Mit Target
konnte ich mich noch nie anfreunden (Bedienung ist für mich der Horror),
und KiCAD ist viel zu kompliziert ;-)
Jetzt habe ich mir mal Gedanken darüber gemacht, wie man es denn (mMn)
"besser" machen könnte. Eine saubere Bauteileverwaltung zu bauen ist
wirklich nicht leicht, irgend einen Kompromiss muss man immer eingehen.
Meine Idee sieht etwa so aus:
Es gibt Symbole (Schaltplan-Symbol), Footprints (fürs Board),
3D-Modelle (für 3D-Ansicht), Gehäuse und Bauteile.
Ein Gehäuse besteht aus einem Footprint und einem 3D-Modell. Ein Bauteil
besteht aus einem Symbol und einem Gehäuse, und vor allem aus der
Verknüpfung von Footprint und Symbol, also die Zuordnung der Pads zu den
Pins.
Einige Beispiele:
Das Erstellen neuer Bauteile würde nun zum Kinderspiel werden, da man
häufig nur noch die bereits existierenden Symbole, Footprints usw. zu
neuen Kombinationen zusammenfügen muss (inkl. Zuordnungen Pins <-->
Pads). "Re-Use" heisst das Zauberwort (das den Eagle-Entwicklern wohl
ein Fremdwort ist - zumindest bis v5, v6 hab ich nicht). Auch eigens
erstellte Bauteile (die man im Internet verteilen kann), sollen auf die
Standardsymbole, Footprints usw. zugreifen können.
Das Updaten des Symbols der Diode würde sich sofort auf alle
existierenden Dioden auswirken. Die in einem Projekt verwendeten
Bauteile werden jedoch im Projekt selber abgespeichert damit nichts
kaputt gehen kann beim Verändern der Bibliothek. Per "Bauteile
aktualisieren"-Button könnte man die dann aber auch wieder frisch aus
der Bibliothek holen, so wird es in Eagle auch gemacht.
Soviel zu meinen Ideen...Ob ich auch die Zeit und den Durchhaltewillen
habe, das alles umzusetzen, das wird sich zeigen ;-)
Falls ja, dann wird es auf jeden Fall OpenSource werden, soviel steht
schonmal fest^^
Thomas schrieb:> Für die Symbole würde sich SVG anbieten:
SVG ist zwar nicht schlecht, jedoch müsste es erweitert werden damit es
auch mit Layers und Pins umgehen kann. Ein Symbol im Schema ist ja nicht
nur ein Bild, sondern es braucht z.B. noch Anschlusspunkte für die
Verbindungen. Das SVG-Format könnte aber als Basis dienen, die man dann
noch um ein paar Funktionalitäten erweitert.
mfg
Hallo,
vom einzelnen Strich bis zur Leiterplatte lässt sich dass alles sehr
schön 1:1 objektorientiert abbilden: ein footprint besteht z.B. aus
Pads, Figures, Text usw. also hat die Klasse component die Eigenschaft
Pads (Array oder Liste) etc., Pad hat wiederum die Eigenschaften Form,
Abmessung1..4, Bohrdurchmesser, Layerzuordnung usw. Dazu natürlich die
Methoden addPad, GetPadList, ReadPadfromLib, die aufbauen auf
ReadParameter oder ReadPosition...
So geht der Aufbau der Library-Definition und der Klassen Hand in Hand,
wenn ich z.B. einen Bauteil-Preis einführen will, definiere ich die
Eigenschaft price und die Methoden zum Lesen und Schreiben in der
Library und fertig. Gibt es in der Library einen Eintrag price und ich
habe ihn noch nicht vorgesehen, so wird er einfach überlesen.
Die Klassenhierarchie ist damit zugleich die Library-Definition.
Gruss Reinhard
Reinhard Kern schrieb:> Hallo,
Hallo Reinhard!
> vom einzelnen Strich bis zur Leiterplatte lässt sich dass alles sehr> schön 1:1 objektorientiert abbilden: ein footprint besteht z.B. aus> Pads, Figures, Text usw. also hat die Klasse component die Eigenschaft> Pads (Array oder Liste) etc., Pad hat wiederum die Eigenschaften Form,> Abmessung1..4, Bohrdurchmesser, Layerzuordnung usw. Dazu natürlich die> Methoden addPad, GetPadList, ReadPadfromLib, die aufbauen auf> ReadParameter oder ReadPosition...
Nun, ziemlich genau so ist es geplant :-)
Aber die Pads auch noch alle einzeln in der Datenbank speichern wäre
übertrieben, ich möchte lieber die Footprints und Symbole mit Text
beschreiben (z.B. XML) und das dann so mit dem entsprechenden Footprint
bzw. Symbol zusammen in der Datenbank ablegen. Ich muss mir mal das
KiCAD Format für Symbole und Footprints genauer anschauen, wenn das
etwas gescheites ist, könnte ich das eigentlich auch praktisch 1:1 so
übernehmen, dann kann meine Software auch direkt mit KiCAD
Symbolen/Footprints umgehen. Anderenfalls könnte man natürlich aber auch
einen Konverter bauen...
mfg
Urban B. schrieb:> Aber die Pads auch noch alle einzeln in der Datenbank speichern wäre> übertrieben
Ja isses, aber Protel macht das trotzdem so, andere nicht: bei Cadstar
wird die Position des Components gespeichert, die Pads eines Components
sind im Footprint definiert relativ zum Component-Nullpunkt, und ihre
Position auf der Leiterplatte ergibt sich aus der Summe von
Pad-Koordinaten und Component-Koordinaten und -Orientierung.
Cadstar geht noch weiter: die Pads selbst sind nicht im Footprint
definiert, sondern extra unter Assignments - ein Circle 60/31
(selbstdefiniert) ist also ein rundes Pad mit 60mil (1,5mm) Durchmesser
und 31mil (0,8mm) Bohrung. Das Pad ist nur einmal definiert, kann von
allen DIL-Footprints benutzt werden und im Layout also von allen
entsprechenden ICs. Ebenso sind Texte nur einmal definiert mit Font,
Höhe, Strichstärke usw.
Urban B. schrieb:> ich möchte lieber die Footprints und Symbole mit Text> beschreiben
Höchst vernünftig, das sollten ALLE CAD-Anbieter so machen und das
Format dokumentieren, das würde viele Probleme des Datenaustauschs lösen
oder man könnte sie selbst angehen.
Gruss Reinhard
Danke für die Infos!
Reinhard Kern schrieb:> Ja isses, aber Protel macht das trotzdem so, andere nicht: bei Cadstar> wird die Position des Components gespeichert, die Pads eines Components> sind im Footprint definiert relativ zum Component-Nullpunkt, und ihre> Position auf der Leiterplatte ergibt sich aus der Summe von> Pad-Koordinaten und Component-Koordinaten und -Orientierung.
Genau so stelle ich mir ein vernünftiges Design vor und habe deshalb
vor, es auch so zu bauen :-)
Mir ist halt einfach sehr wichtig, dass die Bauteile wirklich
strukturiert aufgebaut sind, damit man extrem einfach bereits bestehende
Teile für neue Bauelemente wiederverwenden kann. Und zwar nicht per
Kopie, sondern als Verknüpfung, so dass sich die Aktualisierung eines
kleinen Details sich direkt auch auf alle anderen Bauteile auswirkt, die
davon abstammen.
Reinhard Kern schrieb:> Cadstar geht noch weiter: die Pads selbst sind nicht im Footprint> definiert, sondern extra unter Assignments - ein Circle 60/31> (selbstdefiniert) ist also ein rundes Pad mit 60mil (1,5mm) Durchmesser> und 31mil (0,8mm) Bohrung. Das Pad ist nur einmal definiert, kann von> allen DIL-Footprints benutzt werden und im Layout also von allen> entsprechenden ICs. Ebenso sind Texte nur einmal definiert mit Font,> Höhe, Strichstärke usw.
OK soweit wollte ich erstmal noch nicht gehen, wenn die Software sonst
fertig ist kann man das ja auch noch einbauen :-D
Reinhard Kern schrieb:> Höchst vernünftig, das sollten ALLE CAD-Anbieter so machen und das> Format dokumentieren, das würde viele Probleme des Datenaustauschs lösen> oder man könnte sie selbst angehen.
Jup, deshalb verwende ich wenn möglich immer OpenSource Software. Nur
ist das im Bereich CAD nicht so wirklich einfach (ausser man ist mit
KiCAD zufrieden)... Aber das lässt sich ja ändern :-)
mfg
XML ist wirklich recht schön zu gebrauchen für das. SQL hatte ich
urspünglich implementiertn, aber das ist wesentlich unflexibler.
Bauteile sind übrigends bei weitem nicht das problem.
Sowas ähnliches wie SVG hat man sich recht schnell implementiert
(Polygon, Line, Text ist eigentlich ausreichend).
aktiviert man die anti-aliasing-flags usw von der scene, schaut das auch
ziemlich gut aus!
@Urban B:
Bei der Bauteildatenbank würde ich mich gerne bei dir anhängen. Ich habe
schon R, L, C, Hohlbuchse, 1206, 0207, ... gezeichnet.
Ist aber halbwegs Arbeit...
Wichtig finde ich übrigends, dass so ziemlich jedes Element eine
unique-id bekommt.
nicht nur die footprints und componenten am schematic, auch die pins
sollten sowas haben, da du dann recht einfach die zugehörigkeiten zu
netzen,... herausfindest.
73
Hans Wilhelm schrieb:> XML ist wirklich recht schön zu gebrauchen für das. SQL hatte ich> urspünglich implementiertn, aber das ist wesentlich unflexibler.
Deshalb würde ich die XML Dateien in einem Blob-Feld in der Datenbank
ablegen, so hat man den Vorteil eines einfachen Dateiformats im
Klartext, aber auch die Möglichkeit jedem Element eine eindeutige ID
zuzuweisen, und eine Bauteilebibliothek die auf einem Server installiert
werden kann und dann mehreren Clients zur Verfügung steht.
Hans Wilhelm schrieb:> Bei der Bauteildatenbank würde ich mich gerne bei dir anhängen. Ich habe> schon R, L, C, Hohlbuchse, 1206, 0207, ... gezeichnet.
Ah cool, könntest du mal so ein Beispiel hier anhängen oder mir als PN
schicken?
Hans Wilhelm schrieb:> Wichtig finde ich übrigends, dass so ziemlich jedes Element eine> unique-id bekommt.>> nicht nur die footprints und componenten am schematic, auch die pins> sollten sowas haben, da du dann recht einfach die zugehörigkeiten zu> netzen,... herausfindest.
Hmm also ein Pin muss ja nicht über das ganze Schema eine eindeutige ID
haben, es genügt ja wenn der Pin innerhalb des Bauteiles eindeutig ist,
und das Bauteil wiederum im Schema eindeutig ist.
Ich bin momentan noch ein Klassendiagramm am entwerfen, wenn ich mal den
ersten Entwurf fertig habe, kann ich den hier noch reinstellen.
Mir sind übrigens noch diverse Fragen eingefallen, vielleicht kann die
jemand von euch beantworten:
- In einer Firma (> ~10 Entwickler), wie werden dort Bauteilbibliotheken
verwaltet? Mit einem Datenbankserver?
- Wie werden die Projekte verwaltet? Sind es normale Dateien, die per
Dateifreigabe vom Server den Clients zur Verfügung gestellt werden? Oder
etwas Datenbankbasiertes?
- Können mehrere Personen am gleichen Projekt arbeiten? z.B. Ein
Entwickler im Schema auf Seite 1, ein anderer im Schema auf Seite 2 und
ein dritter am Layout? Spätestens bei extrem grossen Projekten muss das
ja irgendwie so machbar sein. Bekommt dann jeder Benutzer nur innerhalb
eines gewissen Bereiches (Schemaseite, Layout) Schreibrechte, und auf
den Rest des Projektes nur Leserechte?
Ich möchte die Basis der Software gerne so bauen, dass später auch mal
ein Mehrbenutzersystem möglich ist (wenn es mit überschaubarem Aufwand
machbar ist).
Gruss Urban
Teilantworten:
Unser CAM-System arbeitet nach dem Prinzip check in/out: ein Mitarbeiter
wählt das Projekt und die Funktion check out, dann stehen ihm die Daten
exklusiv zur Verfügung (oder werden gleich auf die lokale Workstation
kopiert). Ist er fertig, wählt er check in, vorher kann niemand anders
etwas ändern.
Bauteile: der Zugriff ist weniger ein Problem, Konflikte durch
gleichzeitige Änderungen sind sehr selten. Viel problematischer ist es
in der Praxis, die Bauteile bei mehreren Bearbeitern einheitlich zu
gestalten, aber das lässt sich kaum durch Software lösen.
Meine persönliche Meinung: Stromlaufpläne lassen sich partitionieren in
verschiedene Aufgaben, da ist es sogar vorteilhaft Spezialisten für
Netzteile, Messschaltung, Speicher usw. dranzusetzen. Eine Leiterplatte
ist aber in vielen Fällen nur holistisch zu betrachten, beim PCB-Layout
würde ich daher höchstens seriell (schichtweise) mehrfach bearbeiten. Es
gibt Firmen mit technischen Abteilungen in Europa, USA und Indien, da
wird zu Dienstschluss das Projekt westwärts weitergegeben und kann so
24h am Tag bearbeitet werden.
Gruss Reinhard
also bei mentor geht ändern gleichzeitig oder mit
lock/check-in/check-out,... eigentlich in allen variationen.
bauteile werden über eine datenbank verwaltet. das liegt aber eher an
preisen,stückzahlen, datenblätter,... die auch hinterlegt sind.
bei uns sind aber einige 0er mehr bei der entwicklerzahl/cad
nutzeranzahl dabei...
meine bauteile bekommen pro pin 2 uids. 1x für das schematic-symbol und
1x für den footprint. mir ist bisher keine andere möglichkeit
eingefallen wie ich netze verwalten kann.
es gibt quasi netze auf der obersten hirachieebene, auf die wird aus den
schematic/layout-seiten durch teilnetze verwiesen und in diesen
teilnetzen steht dann drinnen welcher pin vom bauteil auf der seite dazu
gehört.
also gibts im project-file <component></componet> pro componente für die
parameter <net></net> pro netz, <schematic></schematic>,
<layout></layout> und zum visualisiern von simulationsergebnissen
<simulation></simulation>
jede schematic/layout/simulation-page hat dann zu den darauf
befindlichen componenten einen verweis zum toplevel-element +
koordinaten + eben pin-subnet mapping
nicht ganz einfach, aber mir ist bisher wie gesagt nichts einfacheres
eingefallen.
73
So wie versprochen ein beispiel. Sorry, ist etwas länger der post.
Unten die Definition eines Widerstandes.
Im PDF wäre als Beispiel der Schaltplan und der Begin des Layouts von
einem Schaltregler.
Ich bin gerade am Neuimplementieren der Netze.
Daher gibts im Layout keine Verbindungen.
Wieso die PDFs gerastert sind entzieht sich gerade meiner Kenntnis.
Sollte eigentlich schon eine Vektorgrafik sein was die Scene da
ausspuckt.
73
footprint.xml
Hans Wilhelm schrieb:> <Polygon width="0.5">> <Point x="2.5" y="-2.5"/>
Denk rechtzeitig dran, dass du auch Kreisbögen realisieren musst (bei
allen Linienzügen - ein beliebiger Abschnitt kann gerade oder ein Bogen
sein). Auf kompliziertere Kurven kann man bei Layouts verzichten.
Gruss Reinhard
Für die docu-layer gibts z.B schon sowas:
<Circle x="0.0" y="0.0" r="4.45" width="0.25"/>
zwischen 2 punkten in den netzen wirds bei mir nur gerade verbindungen
geben (schematic und layout), da ich zumindest das H-Feld über den
traces simulieren will.
wie gesagt ist das alles nicht weiter aufwendig.
dagegen macht mir die verwaltung der netze noch immer massiv
kopfschmerzen, da irgendwie alles auf graphen hinausläuft die irgendwie
zusammenhängen und irgendwie auch nicht (layout/schematic)...
vor allem wenn das dann über mehrere schaltplanseiten geht...
73
Hallo,
willst du irgendwas Intelligentes bei den Netzen machen oder reicht
nicht etwas einfaches in Richtung?
-> Nur ein Name für ein Signal
-> Das Signal an verschieden Punkten im Schematic ( Verbindungen / Pins
)
-> Über die Lib (Package+Symbol) werden dann im Board alle Pads mit dem
gleichen Signalnamen verknüpft.
naja, irgendwie musst die leitungen dazwischen doch verwalten. sprich
die einzelnen liniensegmente im layout und schaltplan.
das zielführendste, das mir bisher eingefallen ist, wäre alle pads/pins
und eckpunkte als vertex in einem graphen zu betrachten.
damit wäre dann auch airwires relativ einfach realisierbar.
73
Hans Wilhelm schrieb:> dagegen macht mir die verwaltung der netze noch immer massiv> kopfschmerzen
Nicht wirklich. Eigentlich ist ein Netz in Schaltplan nichts als eine
Liste von Pins, im PCB kommen noch Vias dazu und ev. virtuelle
Anschlüsse dazu wie die in einer Cu-Fläche. Netzlisten, die von den
Programmen erzeugt werden, sind daher auch extrem einfach gestrickt,
immer nur Bauteil Pin Bauteil Pin usw. Nach dem Routen ist einem Netz
eine Liste von Leiterbahnstücken zugeordnet.
Ein (temporäres) Problem ergibt sich nur bei der Funktion Reconnect,
also dem Umsortieren von ungerouteten Connections mit dem Ziel minimaler
Gesamtlänge. Das sollte man sowieso extra betrachten und optimieren,
weil es für die Bedienbarkeit eine entscheidende Funktion ist, besonders
als dynamic reconnect während des Bewegens von Bauteilen. Das Ergebnis
kann auch weniger Knoten haben, aber nicht mehr. Ansonsten ändern sich
Netze ja nur durch Eingriff des Users (hoffentlich!).
Gruss Reinhard
Das ist genau was ich meine!
Netzlisten an sich sind simpel. Das habe ich bisher für die Simulation
auch so verwendet.
Nur liegen hinter einem netz eben Wire-Stücke aus dem Schematic bzw
Cu-Polygone aus dem Layout. Und das muss irgendwie verknüpft sein.
In meiner vorhergendenden Implementierung habe ich grundsätzlich nur
pins zu netze hinzufügen lassen und die netze automatisch zeichnen
lassen.
Das ist aber fürs layouten nicht brauchbar.
Da hast du jetzt pins/pads als vertices (an verschiedenen positionen) in
2 graphen die zusammenhängen. das was dazwischen liegt ist dann anders.
73
Okay danke schonmal für die Hinweise wie die das mit dem gleichzeitigen
Arbeiten am selben Projekt gehandhabt wird, und für das XML-Beispiel!
Zum Thema Netze:
Dass die Netze unabhängig von der genauen Verdrahtung (Schaltplan,
Layout) gespeichert wird, ist sicher sinnvoll würde ich meinen. Die
Verbindungslinien könnte man dann doch in einer separaten Tabelle (bzw.
XML) speichern, jeweils als einzelne Linienstücke oder Kreisbogenstücke.
Jedes dieser Linienstücke hat folgende Eigenschaften:
1
- Eindeutige ID des Netzes zu dem das Linienstück gehört
2
- Schaltplanseite
3
- Startpunkt x,y
4
- Endpunkt x,y
5
- Geometrie zw. Start-/Endpunkt (Gerade, Kreisbogen mit Radius r und Zentrum z)
Mehrere Linienstücke hintereinander werden nun durch ihre
Start-/Endpunkte miteinander verbunden. Also wenn an einem Pin eines
Symbols eine Gerade Linie von der Koordinate des Pins bis zur Koordinate
"p1" verläuft, und ein anderes Linienstück des selben Netzes von "p1"
bis zum Pin eines anderen Bauteiles, dann ergibt das eine
zusammenhängende Verbindung zwischen zwei Symbolen. Wird jetzt z.B. der
Punkt "p1" verschoben, schaut man in der Datenbank nach, welche
Linienstücke alle an diesem Punkt enden bzw. beginnen, und verschiebt
diese mit. Kommen an einer Koordinate mehr als zwei Liniensegmente
zusammen, soll automatisch ein Verbindungspunkt entstehen (damit der
Benutzer sieht, dass es eine Verbindung gibt dort).
Die Verbindungen werden somit also eindeutig durch die Koordinaten der
Start-/Endpunkte der Liniensegmente bestimmt. Liegen mehrere Endpunkte
von Liniensegmenten an der selben Koordinate, gelten sie automatisch als
verbunden.
Beginnt der Benutzer nun mitten in eine geraden Linie eine zweite Linie
zu zeichnen, so muss die Software halt merken dass dort schon eine Linie
durchläuft, damit diese Linie nun in zwei einzelne Segmente aufgeteilt
werden kann und dadurch einen Anschlusspunkt für die neue Linie
entsteht.
Fürs Layout müsste das eigentlich ja auch ungefähr so machbar sein. Vias
werden einfach als spezielle Liniensegmente angesehen und somit auch in
der Datenbank der Liniensegmente abgelegt. Dort gilt das gleiche: Alle
Linien desselben Netzes, die an der Koordinate des Vias enden/beginnen,
gelten als verbunden mit dem Via.
Für die Luftlinien schaut man einfach in der Datenbank der
(Layout-)Liniensegmente nach, welcher Punkt am nächsten ist. Man filtert
nach der ID des gewählten Netzes und bekommt dann die
Start-/Endkoordinaten aller Liniensegmente des selben Netzes. Darin
sucht man sich dann die am nächsten liegende Koordinate. OK dadurch
werden zwar nur jeweils die Endpunkte berücksichtigt und nicht das, was
dazwischen liegt. Da muss man dann halt noch zusätzliche Berechnungen
durchführen wenn man es genau haben möchte. Zusätzlich müssen natürlich
auch noch die Pads aller Bauteile in die Suche miteinbezogen werden (die
können ja durch das Schema auch ein Netz haben, auch wenn sie keine
Leiterbahn angeschlossen haben).
Habe ich etwas übersehen, oder könnte das vielleicht so funktionieren?
mfg
Dieses verhalten habe ich gerade implementiert und ersetze es gerade.
ich werde zukünftig nur die "ecken" der netze speichern und tabellen mit
verbindungen dazwischen.
Das suchen von gleichen koordinaten ist nicht ganz so trivial, da du
doubles vergleichst. außerdem musst du entweder die scene fragen ob da
etwas anderes ist, oder eben dir extra im hintergrund die tabellen
halten.
weiters verschiebst du mit einer ecke 2 punkte (2 linien starts) + die 2
linien. wenn du nur ecken speicherst verschiebst du nur 1nen punkt (und
musst nur den einen punkt aufs raster ausrichten)
besser finde ich punkte Ids zu geben und zu sagen Id1 und Id2 sind
verbunden. daher habe ich oben auch gemeint ich würde jeden pin/pad eine
unique-id geben, da ich dann einfach sagen kann, dass die id des pins
dem netz zugehörig ist, und wenn ich im footprint/symbol was ändere,
versichen sich die linien, verbunden sind sie aber immer noch.
grundsätzlich spricht ja nix dagegen die linien als bezier kurven
darzustellen. jetzt habe ich einfach qgraphicslineitems, statt denen
kann man ja auch qraphicspathitems nehmen.
aber zuerst halt einfach.
auf jeden fall probiere ich das jetzt so aus und hoffe, dass da einiges
einfacher wird.... vor allem sollte ich so auch wieder thermische netze
zeichnen können für kühlkörper usw.
73
Hallo,
anbei ein klitzekleiner Ausschnitt aus der Cadstar ASCII Definition, zur
Ein/Ausgabe von net. Da kann man über Details andrer Meinung sein, aber
jedenfalls ist es ein funktionierendes und bewährtes System. Das
Original ist eine kreuz und quer verlinkte Hilfedatei. Heute würde man
eine solche Beschreibung auch mit Xirgendwas erstellen.
Gruss Reinhard
die machen das eh genau so wie ich oben beschrieben hab... sie merken
sich punkte und nicht strecken... bzw merken sie sich polygone, was eben
die strecken zwischen den punkten implizit definiert.
was sie aber nicht tun ist nur die strecken a-b b-c c-d zu merken und
dann zu schaun ob welche punkte auf gleicher koordinate liegen.
wenn a und d auf einem pin liegen ists gut und man findet heraus wie
alles verknüpft ist, wenn aber der footprint sich ändert hat man ein
problem.
daher haben die ja ja verweise auf die pins der componenten (damit quasi
einen vertex wie ich ihn oben beschrieben habe, nur das ich die info
beim bauteil und nicht beim netz sehe.. also wurscht).
dann definieren sie die zuerst definierten punkte am netz mit polygonen.
das wäre also eqivalent, wenn ich sage ich habe stückpunkte (die punkte
die mit (PT ...) definiert sind, und dann eine liste die sagt "verbinde
punt a mit punkt b"
wenn man sich jetzt überlegt wie man die daten verwaltet sodass layout
und schematic zusammenpassen, wirds nicht einfacher... ich will
übrigends nicht den weg über explizite netzlisten gehen. => kein
CAD-System für große schaltungen, sondern simulator, der teile das
layouts mitberücksichtigen kann.
73
Hans Wilhelm schrieb:> was sie aber nicht tun ist nur die strecken a-b b-c c-d zu merken und> dann zu schaun ob welche punkte auf gleicher koordinate liegen.
Wäre mir zu riskant. Cadstar speichert primär die PIN-Liste, und die
beschreibt das Netz topologisch und damit auch elektrisch, und die kann
beim Routen auch nicht verändert werden (nicht im topologischen Sinn).
Die Netzlisten, also hier die PIN-Listen, sind die Essenz des Layouts
überhaupt.
Gruss Reinhard
sag ich ja...
was mir jetzt noch kopfweh macht, ist das verwalten von pin (schematic),
pad (layout) und der restlichen punkte damit man (wie du es so schön
nennst) das netz topologisch beschreiben kann.
weil du hast punkte die zusammenhängen (also pin1 vom symbol und pad10
vom footprint), und dann irgendwelche andere punkte die die verbindung
zwischen komponenten verwalten.
Es würde noch gehen, wenn man behauptet es zählt eh nur das schematic.
Dann verwaltet man halt eine liste von den Pins am Netz (Pin-Pad-Mapping
ist eh in der componentendefinition) und dann jeweils für schematic und
layout noch eine liste fürs topologische zeugs.
problem an der sache sehe ich wenn sich alles über mehrere seiten zieht.
Implementierungsdetail halt :)
73
Hans schrieb:> Es würde noch gehen, wenn man behauptet es zählt eh nur das schematic.
Beispiel CadStar: zusätzlich zu den Pads an Bauteilen gibt es Junction
Points, z.B. an der Stelle, wo Leiterbahnen T-förmig verbunden sind. Im
Gegensatz zu den Pads können die beim Routen entstehen und verschwinden.
Damit vermeided man, Teilstücke übereinander zu legen, so hat das
Cadstar früher mal gemacht, das war aber viel schlechter zu handhaben.
Ebenso braucht man die, wenn Leiterbahnen einfach so im Nirwana enden.
Unbedingt notwendig ist es, Leiterbahnen nur teilweise zu routen und
erst später fertigzustellen, aber auch im Endzustand werden offene Enden
manchmal benötigt, z.B. zu Abschirm- oder Guard-Zwecken.
Gruss Reinhard
Ich brauch das etwas abstrakter. bei mir heißt das vertex, weil das
"netz" ja einen graphen darstellt. und meine netze nicht nur elektrisch
sondern auch thermisch sein könne.
daher nicht netz sonder domain mit typ electrical :)
wie gehts denn eigentlich den thread-starter?
73
Hans schrieb:> wie gehts denn eigentlich den thread-starter?
Momentan bin ich hier einfach am mitlesen was ihr für Ideen habt und was
für Erfahrungen ihr gemacht habt :-) Ich habe halt noch andere Projekte,
die eine höhere Priorität haben, daher gehts nur langsam voran mit
diesem Projekt hier. Es soll ja in erster Linie auch mehr ein
Lernprojekt sein, mit dem ich mich mit Qt und der CAD-Programmierung
vertraut machen kann.
Ich habe diesen Thread hier halt gestartet um mal einen Einstieg zu
finden, und diesen habe ich dank euch auch gefunden. Jetzt weiss ich in
welche Richtung es gehen soll.
Hans schrieb:> und meine netze nicht nur elektrisch sondern auch thermisch sein könne.
Da hast du aber einiges vor :-) Können das die "grossen" CADs auch?
mfg
Nein, das können sie nicht wirklich. Das liegt aber an der Natur der
Sache. Ich bau' das für meine Dissertation :)
Dafür stelle ich aber keine Anforderungen an 8Layer+ Verwalten, diverse
flooding Möglichkeiten, div. ERCs, export in M-CAD systeme, ...
Mentor hat schon ziemlich ausgeklügelte Systeme ;)
E-CAD ist aber eben E-CAD... man kann zwar CAD-Daten an
FEM/...-Simulatoren übergeben und dann irgendwelche Signale anlegen,
aber ich will was anderes.
Es soll sowas wie Spice werden, nur das auch das "echte" thermische
Verhalten mitsimuliert wird. Damit du sagen kannst "Mein kühlkörper wird
so warm, und der lüfter muss 80% Luftdurchsatz bringen". Idealerweise
rennt gleichzeitig auch eine CPU-Emulation für die regelung...
Vieles davon geht auch schon... jetzt muss alles halt schön langsam
herzeigbar und verifiziert werden, damit man was vernünftig publizieren
kann :)
73
Hans Wilhelm schrieb:> Mein kühlkörper wird> so warm
Willst du ernsthaft die Luftströmungen durch einen Rippenkühlkörper
simulieren, oder nimmst du die Herstellerangaben dazu?
Gruss Reinhard
Aktuell nur Rth(m) und Cth => "das "echte" thermische
Verhalten"
Man kann 2 Kurven hinterlegen: Einmal den thermischen Widerstand in
abhängigkeit von der Luftmasse, und anderseits die Luftmasse in
Abhängigkeit von der Spannung die der Lüfter sieht.
Das ist schon recht interessant.
Grundsätzlich sehe ich aber auch kein problem darin fluid dynamics
mitzusimulieren... es dauert halt "etwas" länger :)
Jedes Bauteil weiß, welche Temperatur es hat. Im nächsten Schritt kommt
jetzt das Layout dazu, und dann kann ich nach der Simulation ein schönes
buntes Bild erzeugen wo man dann sieht welche PCB-Traces wie warm würden
(nach IPC-2221) und welches Bauteil bereits magic smoke von sich gibt :P
Sollte auf jeden fall besser mit der Realität zusammenstimmen als eine
einfach spice simulation...
grobe Multilayer PCBs muss man sowieso mit FEM modellieren, sonst wird
man wohl mit den thermischen Kopplungen nicht hinkommen.
73
Urban B. schrieb:> Aber mit einer> gescheiten Bauteilebibliothek xD
Aber es hindert dich doch niemand, für Eagle die ultimative Library zu
erstellen.
Gruss Reinhard
Hans Wilhelm schrieb:> und anderseits die Luftmasse in> Abhängigkeit von der Spannung die der Lüfter sieht.
KK mit Lüfter sind wohl, entgegen der ersten Vermutung, auch der
einfachere Fall, umso einfacher je höher der Lüfter dreht. Viel
komplexer sind aber KK ohne Lüfter, mit "natürlicher" Konvektion, und
die sind meiner Meinung nach die erdrückende Mehrzahl. Und noch viel
mehr gibt es heizende Bauelemente ohne Kühlkörper, wobei gemeinerweise
häufig die Verlustleistung von der Taktfrequenz und bei Prozessoren ganz
massiv von der Software abhängt - viel Spass dabei. Eine Software, der
ich ein PCB-Layout und die Software übergebe und die mir dann sagt wie
heiss der Prozessorchip wird, hätte zweifellos gute Chancen.
Gruss Reinhard
Daran hab ich noch garnicht gedacht :) danke für den Input :)
Derzeit spiel ich mich micht Step-Down controller. Diese Simulationen
schaun eigentlich ganz Ok aus.
Jetzt betreue ich in den nächstem Monaten eine FH Diplomarbeit von der
ich mir erhoffe einen surface-scanner zu bekommen.
So Gott will kann ich dann das H-Feld über dem PCB und Temperaturen der
Komponenten und Traces mit der Realität vergleichen.
Power-Prediction bzw. Simulation/Debugging über einen SoC-Emulator wären
in der tat cool... ein paar jahre hätt ich ja noch eingeplant ;P
Ich eigentlich nur einen möglichst simplen uC als SNT controller
verwenden und zeigen wie "einfach" man schön ohne hardware entwickeln
kann...
den gedanken im breakpoint quasi die welt runterhum anhalten zu können
finde ich irgendwie cool :)
73
Reinhard Kern schrieb:> Urban B. schrieb:>> Aber mit einer>> gescheiten Bauteilebibliothek xD>> Aber es hindert dich doch niemand, für Eagle die ultimative Library zu> erstellen.
Per ULP? Daran habe ich noch gar nicht gedacht...
Aber wie gesagt, es geht mir in erster Linie mal darum, mich mit dem
Thema Qt und CAD auseinanderzusetzen. Der Weg ist das Ziel :-)
mfg
Thread beobachten
Seitenaufteilung abschalten