mikrocontroller.net

Forum: Platinen [Altium] Routing extrem langsam, Verlust von Leiterbahnstücken


Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: ..,- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
..,- 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.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: ..,- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: ..,- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Wege von Altium sind oft unergründlich ;-)

Autor: Inkognito (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vermutung:
Oder das Grid, auf das der Autorouter Bezug nimmt und nur zu fein 
eingestellt ist. Was sagt denn der Task-Manager?

Autor: dasrotemopped (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Inkognito (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Inkognito (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Inkognito schrieb:
> -DSR-Daten

DRC sollte es heißen.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Taz G. (taz1971)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Serdar K. (serdkar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Harry (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
wieder ein Beweis mehr dass Altium Schrott ist, ich habe ihn schon lange 
von meinem PC verbannt.

Autor: ..,- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.