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?
Angehängte Dateien:
-
ad16_route_1.png
86 KB -
ad16_versatz.png
3,1 KB
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.
:
Bearbeitet durch User
Die Wege von Altium sind oft unergründlich ;-)
Vermutung: Oder das Grid, auf das der Autorouter Bezug nimmt und nur zu fein eingestellt ist. Was sagt denn der Task-Manager?
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
wieder ein Beweis mehr dass Altium Schrott ist, ich habe ihn schon lange von meinem PC verbannt.
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)
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.