Bei einer Leiterplatte habe ich das Problem, dass Altium Designer (15.1,
16.0, 16.1, jeweils auf mehrern Rechnern) wirklich brechend langsam ist.
Beim händischen Routen dauert es zwischen ca. zwei Sekunden und einer
halben Minute, bis das jeweils nächste Leiterbahnstück gezeichnet wird.
Und erstaunlicherweise kommen gelegentlich auch schon fest verlegte
Leiterbahnstücke wieder abhanden oder werden um einen Mückenpimmel
verschoben. Ich kann sicher ausschließen, dass mir selbst diese Fehler
unterlaufen, denn es passiert mittlerweile ziemlich häufig, insbesondere
auch bei Leiterbahnen auf anderen Lagen.
Ich habe auch schon an allen möglichen Einstellungen herumgespielt;
insbesondere habe ich auch Design Rules im Verdacht, das träge Verhalten
zu verursachen. Ich habe auch schon eine neue Leiterplatte angelegt und
nach und nach den gesamten Inhalt der alten Leiterplatte übertragen.
Solange auf der neu zusammengesetzten Leiterplatte noch keine
Leiterbahnen liegen, ist auch alles schön schnell. Sobald ich jedoch
Leiterbahnen oder Vias übertragen habe, wird es langsam.
Eine sehr ähnliche Leiterplatte (Größe, Anzahl Bauteile und Pads,
Lagenaufbau) lässt sich übrigens wunderbar schnell routen.
Kennt einer von Euch das Problem und hat womöglich eine Lösung dafür?
Was passiert denn wenn Du in den PCB Editor Einstellungen den online DRC
deaktivierst?
> Kennt einer von Euch das Problem und hat womöglich eine Lösung dafür?
Bei mir ist das jedenfalls nicht so (auch nicht bei komplexeren Boards)
Hast Du in Deinem Versionskontrollsystem noch ältere Versionen von dem
Projekt?
Wie sieht es bei denen aus, tritt da auch das Problem auf?
Dann würde ich schauen wann das Problem angefangen hat (git bisect) und
versuchen nachzuvollziehen was Du gemacht oder umgestellt hast was das
ausgelöst hat.
..,- schrieb:> Was passiert denn wenn Du in den PCB Editor Einstellungen den online DRC> deaktivierst?
Das macht interessanterweise keinen wesentlichen Unterschied. Einen
großen Unterschied gibt es, wenn ich entweder alle Leiterbahnen und Vias
wegwerfe oder alle Regeln. Ich habe natürlich schon alle möglichen
Zwischenwege ausprobiert, z.B. auch nacheinander alle Bauteile entfernt.
Aber auch das ändert nichts. :-/
> Bei mir ist das jedenfalls nicht so (auch nicht bei komplexeren Boards)
Das Board ist gar nicht allzu komplex, d.h. zwölf Lagen, von denen die
meisten jedoch als Planes für Versorgungsspannungen dienen.
Gerd E. schrieb:> Hast Du in Deinem Versionskontrollsystem noch ältere Versionen von dem> Projekt?
Ja, ich habe ziemlich viele Zwischenstände im Subversion abgelegt.
Leider konnte ich nicht mit einem leeren Projekt starten, sondern die
Baugruppe ist eine sehr umfangreiche Überarbeitung eines
Kundenprojektes. Auf Kundenseite ist jedoch die Historie
abhandengekommen, da er sie von einem Dritten hat extern entwickeln
lassen. Sie wurde schätzungsweise mit AD 13.x erstellt.
> Wie sieht es bei denen aus, tritt da auch das Problem auf?
Das Problem tritt bei dieser Baugruppe aber schon die ganze Zeit auf,
verschlimmert sich aber langsam mit zunehmender Komplexität.
> Dann würde ich schauen wann das Problem angefangen hat (git bisect) und> versuchen nachzuvollziehen was Du gemacht oder umgestellt hast was das> ausgelöst hat.
Mit "git bisect" käme ich hier nicht allzu weit, da ich Subversion
verwende. ;-)
Speicher doch mal probehalber eine Kopie der Platine im "PCB 5.0 Binary"
oder auch "PCB ASCII" Format ab (älteres Format, paar rules gehen
verloren). Die dann mal öffnen und testen.
Hurra, ich konnte durch das Speichern im "PCB ASCII"-Format und
anschließendes Korrigieren der etwas deformierten Regeln das
Geschwindigkeitsproblem beheben! Natürlich habe ich das Layout
anschließend wieder im aktuellen Binärformat abgespeichert.
Wenn ich hingegen den alten Regelsatz als RUL-Datei gespeichert und in
das o.a. konvertierte Layout geladen habe, wurde das ganze wieder
brechend langsam, obwohl darin keine wirklich auffällige Regel enthalten
war. Ich hatte derartige Experimente auch schon vorher gemacht, was aber
nicht so erfolgreich war.
ich vermisse die Angabe, auf welchem Rechner (CPU, RAM, GFX) Altium zu
langsam ist. Oder vielleicht ein überzeugter Linux User, der mit Wine
und VM rummacht ? Ansonsten habe ich Altium immer auch bei großen Boards
performant erlebt.
Gruß,
dasrotemopped.
Andreas S. schrieb:> Wenn ich hingegen den alten Regelsatz als RUL-Datei gespeichert und in> das o.a. konvertierte Layout geladen habe, wurde das ganze wieder> brechend langsam, obwohl darin keine wirklich auffällige Regel enthalten> war. Ich hatte derartige Experimente auch schon vorher gemacht, was aber> nicht so erfolgreich war.
Kann das vielleicht sein, dass Altium binär routet und auf
Ascii-DSR-Daten zugreift (oder umgekehrt) und das Umrechnen
die Software ausbremst? Wenn Routen und DSR binär zusammen
arbeiten (oder umgekehrt in Ascii) müsste es doch schneller
gehen, oder?
Auch Festplattenzugriffe durch Datei-Auslagerungen können
ein System ausbremsen, aber bei den heutigen Gigabyte SDram-
Speichern ist das eigentlich nicht vorstellbar.
Ist natürlich nur ein Schuss ins Blaue.
dasrotemopped schrieb:> ich vermisse die Angabe, auf welchem Rechner (CPU, RAM, GFX) Altium zu> langsam ist.
Wie ich schon schrieb, trat das Problem bei genau dieser Leiterplatte
auf mehreren Rechnern auf. Deren einzige Gemeinsamkeiten sind Windows 7
und Intel-Prozessoren:
- Dell Precision T3500, Xeon W3530, 24 GB RAM, Nvidia Quadro 4000
- Lynx Senyo 600MN, Core i5-2400, 16 GB RAM, Nvidia Quadro NVS300
- Selbstbau, Core i7-2600K, 16 GB RAM, Nvidia Geforce GT430
- Notebook Lenovo W500, Core2 Duo T9x00, 4 GB RAM, ATI FireGL V5700
> Oder vielleicht ein überzeugter Linux User, der mit Wine> und VM rummacht ? Ansonsten habe ich Altium immer auch bei großen Boards> performant erlebt.
Ich bin zwar auch ein überzeugter Linux-Nutzer, setze aber das für die
wichtigsten Applikationen relevante Betriebssystem ein, d.h. alle drei
obigen Rechner laufen primär mit Windows 7. Linux läuft dann als VM bzw.
auf mehreren Servern virtualisiert und "bare metal".
Da alle anderen Altium-Projekte wesentlich flüssiger zu bearbeiten
waren, konnte es nur an irgendwelche Einstellungen oder Inkosistenzen
der Projektdateien liegen. Im 2D-Modus merkt man bei AD eigentlich
keinen Geschwindigkeitsunterschied auf Grund der Grafikkarte. Im
3D-Modus ist der Unterschied hingegen ziemlich deutlich, d.h. die GT430
und das Notebook sind wesentlich langsamer beim Rotieren der Ansicht.
Inkognito schrieb:> Kann das vielleicht sein, dass Altium binär routet und auf> Ascii-DSR-Daten zugreift (oder umgekehrt) und das Umrechnen> die Software ausbremst? Wenn Routen und DSR binär zusammen> arbeiten (oder umgekehrt in Ascii) müsste es doch schneller> gehen, oder?
Naja, in ASCII wird AD schon nicht rechnen... Probleme gibt es jedoch
manchmal bei metrischen Angaben, weil AD intern zöllisch rechnet. Der
Layer Stack Manager zeigt meist z.B. Schichtdicken von 0,1699mm oder
0,4199mm an.
Und auch bei Aussparungen in Polygonen gibt es sehr selten DRC-Fehler
mit Angaben wie "0.2mm < 0.2mm". Ich finde es auch ärgerlich, dass AD
keine separaten Regeln für die Generierung und Überprüfung von Elementen
anbietet, z.B. in der Art "Erzeuge Aussparungen mit einem Abstand von
0,3mm, aber akzeptiere auch manuell erzeugte Abstände von 0,2mm".
> Auch Festplattenzugriffe durch Datei-Auslagerungen können> ein System ausbremsen, aber bei den heutigen Gigabyte SDram-> Speichern ist das eigentlich nicht vorstellbar.> Ist natürlich nur ein Schuss ins Blaue.
Bei dem betreffenden Projekt lag die Speichernutzung durch AD bei nur
ca. 500 MB. Und wie schon geschrieben, trat das Problem über einen
längeren Zeitraum auf mehreren Rechnern auf.
Inkognito schrieb:
> Kann das vielleicht sein, dass Altium binär routet und auf> Ascii-DRC-Daten zugreift
Ich arbeite schon lange mit Altium aber binäres Routen und Ascii-DRC
Daten höre ich zum ersten mal.
Intern arbeitet Altium mit 1/10000 mil oder umgerechnet mit 2.54nm alle
Ein- und Ausgaben werden natürlich sofort ins interne Datenformat
umgerechnet - mit anderen Worten gerechnet wird immer im internen
Datenformat (nicht inch und auch nicht mm). Weil es von mil abgeleitet
ist (1mil/10000) gibt es bei der Umrechnung nach mm die besagten Fehler.
Übrigens werden die Anzeigewerte gerundet, mm auf die 4. und mil auf die
3. Nachkommastelle. Das gilt nicht für die Eingabe z.B. 0.99999mm wird
als 1mm Angezeigt ist aber Intern nicht 1mm (getestet 0.99999mm=393697,
1mm=393701). Daher kann es sein das 1mm<1mm ist.
(Selber testen ? Setze Holesize Rule auf 1mm und platziere Pad mit
0.99999mm Loch (Angezeigt wird dann 1mm) das erzeugt Fehler 1mm<1mm)
Zu den Geschwindigkeitsproblem kann ich mir schon irgendwo eine Rule
vorstellen, die das System ausbremst. Vielleicht fehlt auch eine All-All
Rule. Eine Macke in den Rules ist jedenfalls sehr schwer zufinden. Um
das Problem zufinden würde ich den Rule-Satz Häppchenweise importieren
und schauen wann der Fehler auftritt - oder einfach freuen das es jetzt
läuft.
Servus Andreas,
was für Current Mode hast du beim routen eingestellt..
Wenn du Push Obstacles eingestellt hast ,kann es sein das es länger
dauert wie zb beim ignore Obstacles..
Wie sieht es mit Polygon aus ?
Hast du auf immer aktualisieren eingestellt wenn ja hat das auch eine
heftige Auswirkung auf dein Zeit aus
Naja auch wenns so seine Macken hat, bislang hats hier für jedes Layout
gut funktioniert (bis 16 Layer und 5000 Pins). Unlösbare Probleme gabs
noch nie.
(auch das Problem hier wurde ja gelöst)
ad16_route_1.png
(86 KB)
ad16_versatz.png
(3,1 KB)
