Announcement: there is an English version of this forum on 
Bei der Kontrolle von Gerberdaten mit GERBV sind mir unterschiedliche Anzeigen ein- und derselben Stellen aufgefallen: - Thermalpads werden in der einen Zoomgröße als Brücke über benachbarte Leiterbahn dargestellt, in der nächst größeren Ansicht wieder wie gewollt getrennt davon (rote rund/ ovale Markierungen) - dabei gehen Lötaugen, die von der anderen Platinenseite kontaktiert werden, auch mal ganz ausgeblendet (blaue Rechtecke) Was davon wird denn nun gefertigt, habt ihr dazu Erfahrungen? Gruß Volker
Angehängte Dateien:
-
Gerbv_2.2.0._a.gif
46 KB
Danke für die Info! Gleich ausprobiert, geht super über die Import-Funktion. Jetzt habe ich zwar die Brücken in jeder Zoomstufe, aber das ist wenigstens eine Angabe, mit der ich arbeiten kann ;-). .. und die Pins verschwinden ebensowenig. Danke, Volker
Volker H. schrieb: > Gruß Volker Gerbv 2.2? Das müsste ja uralt sein, das erste an das ich mich errinnern kann ist 2.4, jetzt habe ich 2.6. Oder meinst Du das GerbView von KiCad? Das gEDA gerbv funktioniert eigentlich sehr gut. Ich habe es zwar nur unter Linux genutzt, es sollte aber auch unter Windows funktionieren. Na ja, interessiert dich wohl eh nicht mehr.
Angehängte Dateien:
-
Gerbv_2.6.1.gif
7,2 KB
Hallo, habe Gerb 2.6.1 installiert, leider brachte dies keine Verbesserung der Anzeige. Gruß Volker
Volker H. schrieb: > habe Gerb 2.6.1 installiert, leider brachte dies keine Verbesserung der > Anzeige. Interessant. Es gibt ja diverse "Rendering Modes" die man im Menu auswählen kann, da könnte man mal etwas experimentieren. Ob Du Linux oder ein anderes OS verwendest hast Du uns ja nicht verraten, ich denke mal gerbv wird vorwiegend unter Linux eingesetzt und getestest, da mag es in der Tat unter anderen Betriebssystemen Fehler geben. Aber offentsichtlich magst Du das problematische Gerber-File ja auch nicht herausgeben, da wird die Fehlersuche eh schwierig. Und ich muss zugeben, ich kenne zwar einige der gEDA Entwickler, nicht aber das gerbv Team. Die Kontaktaufnahme ist derzeit wohl auch etwas holperig, soweit ich mich an eine Bemerking auf der gEDA Mailingliste erinnere. Ist schon etwas schade, gerbv ist schon ein nettes Programm, zumindest gefällt es mir optisch von all den gEDA Tools am besten, und das Rendering war auch erstaunlich flott, wenn man bedenkt das Cairo verwendet wird. (Ohne GL unterstützung wie ich stark vermute.) Na ja, wenn Du einen Rechner mit Windows zur Verfügung hast gibt es ja Alternativen. Das KiCad GerbView könnte man natürlich auch mal ausprobieren, aber es ist wohl noch nicht ganz so gut. Übrigens, wenn Du schon das Gerber nicht herausgeben magst, hättest Du wenigstens sagen können, womit Du es erzeugst hast, vielleicht macht das einen Unterschied.
Hallo Stefan, ich muß einen Irrtum korrigieren. ALs ich die neue Gerbv-Version installierte (unter WinXP), habe ich nicht zuvor die alte 2.2.er Version deinstalliert. Trotz unterschiedlicher Install-Verzeichnisse und dem Aufruf der neuen Version trat der Darstellungsfehler auf. Dann habe ich die beide Versionen deinstalliert, anschließend die neue nochmals installiert, und nun zeigt die Version 2.6.1 keine unterschiedlichen Varianten mehr an. Auf einem anderen Rechner (WIN8) mit Gerbv 2.6.0. wurde das Layout ebenfalls konsistent angezeigt. Also ist bei Nutzung der stabilen Version 2.6.0 kein Darstellungsfehler mehr durch mich erkennbar, ebenso bei der neuen Version 2.6.1. Deswegen werde ich das einfach zu bedienende und optisch ansprechende Tool auch gern weiter nutzen. In der beigefügten Gerber-Datei ist so eine problematische Stelle am unteren Rand zu erkennen, jetzt kann ich (wegen deinstallierter Altversion) aber nicht mehr verschiedene Darstellungen anzeigen. Damit ist mein Problem gelöst, solche Pads (optional generiert) kann ich dann einfach selektieren und per Hand löschen (übrigens in Target 3001, aktuelle Version). Danke und Gruß, Volker
Volker H. schrieb: > solche Pads (optional generiert) kann ich > dann einfach selektieren und per Hand löschen Dir ist aber schon klar, wie fehleranfällig so eine nachträgliche Bearbeitung ist (spätestens bei der nächsten Version)? Grundsatz: Kontrolle durch Gerber Viewer IMMER, Änderung NIE. Gruss Reinhard
Reinhard Kern schrieb: > Grundsatz: Kontrolle durch Gerber Viewer IMMER, Änderung NIE. Da kann ich nur zustimmen, hatte auch geschrieben: > .. selektieren und per Hand löschen (übrigens in Target 3001 ..
Angehängte Dateien:
-
gerbview_gc.png
9,6 KB
Stefan Salewski schrieb: > Das KiCad GerbView könnte man natürlich auch mal > ausprobieren, aber es ist wohl noch nicht ganz so gut. Kannst auch "vergessen". Habe letztens gerade wieder ein Fall gehabt wo mit der KiCad Viewer fehlerhafte Polygone angezeigt hat, während GC-Prevue bisher immer alles richtig angezeigt hat (und auch später vom Platinenfertiger genauso wiederkam wie in GC-Prevue angezeigt). Siehe Bild
Timmo H. schrieb: > Habe letztens gerade wieder ein Fall gehabt wo mit der KiCad Viewer > fehlerhafte Polygone angezeigt hat, Hast du denn wenigstens einen Bugreport geschrieben? Ohne einen solchen wird sich daran gewiss nichts ändern, denn es ist keineswegs sicher, dass die Entwickler überhaupt von deinem Problem damit etwas ahnen.
Hallo Jörg. Jörg Wunsch schrieb: > Hast du denn wenigstens einen Bugreport geschrieben? > > Ohne einen solchen wird sich daran gewiss nichts ändern, denn es ist > keineswegs sicher, dass die Entwickler überhaupt von deinem Problem > damit etwas ahnen. Das jemand einen Bugreport schreibt, ist aussergewöhnlich selten. Ich verteile immer meine Emailadresse, weil ich gerne mal Rückkopplung hätte, zu dem was ich gemacht habe. Die Reaktionen sind seeeehr mager.....ich krieg ja noch nicht einmals richtig Spam. Umgekehrt bekomme ich in 80% aller Fälle eine Antwort, wenn ich einen Bugreport mache, oder eine Frage habe.....es lohnt sich also. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.dl0dg.de
Timmo H. schrieb: > Kannst auch "vergessen". Ich habe Dich nicht ganz verstanden. Du schriebst doch oben, dass gerbv 2.6 bzw. 2.6.1 unter Windows bei korrekter Installation korrekt anzeigt. Dann schriebst Du im selben Posting >In der beigefügten Gerber-Datei ist so eine problematische Stelle am >unteren Rand zu erkennen, wobei ich nicht sicher war, ob damit jetzt ein Darstellungsfehler gemeint war. Und nun > Kannst auch "vergessen". Das "auch" könnte bedeuten, dass das KiCad gerbview ebenso fehlerhaft anzeigt wie das gEDA gerbv 2.6 unter Windows. Oder ist gEDA gerbv 2.6 unter Windows XP doch in Ordnung bei korrekter Installation?
Hallo Stefan,
Du hast leider 2 Kommentare bzw. deren Autoren vermengt. Von mir stammt
die Aussage, daß Gerbv 2.6.1 unter WinXP in meinem Beispiel keine
Darstellungsfehler mehr zeigt, ich somit zufriedengestellt bin.
In der abgehängten Datei ist ein Bottom-Layer enthalten, in dem ein
Massebohrungspad jetzt permanent über den gewünschten Bereich ragt - das
aber mit den aktuellen Gerbv-Versionen auch genauso in allen
Zoombereichen angezeigt wird.
Der Satz
> Kannst auch "vergessen".
stammte von Timmo H.
Gruß Volker
Bernd Wiebus schrieb: > Das jemand einen Bugreport schreibt, ist aussergewöhnlich selten. Bei einem ordentlichen Projektmanagment gehört ein Bugtracker einfach mit dazu. Was in den emails reinläuft, ist übermorgen schon in der Inbox unten rausgerutscht und wird vergessen. Man sitzt ja nicht täglich da dran, sondern macht auch noch was anderes. Generell ist es jedoch völlig albern, in irgendeinem Forum ein "kannste vergessen" mit einem fehlerhaften Fallbeispiel zu posten, genau diesen Fehlerfall aber denjenigen, die das Projekt betreiben, nicht kund zu tun. Wenn man es ihnen per Bugreport gemeldet hat und sie sich dann nicht drum kümmern, dann würde ich das "kannste vergessen" akzeptieren.
Volker H. schrieb: > Du hast leider 2 Kommentare bzw. deren Autoren vermengt. Tut mir leid, da war ich gestern abend zu flüchtig. Dann ist also mit gerbv 2.6.x alles ok und ich kann mir die Kontaktaufnahme mit den Entwicklern sparen. Freut mich sehr :-)
Was unterstellt ihr mir denn? Nein ich habe den Bug nicht gemeldet. Hat aber den Grund, dass er schon gemeldet wurde: http://sourceforge.net/p/gerbv/bugs/169/ Mir ist klar das Opensource Projekte von sowas leben und melde selbst einiges an Bugs bei anderen Opensource Projekten. Der Bug ist übrigens auch in Gerbv 2.6.1 noch drin. Ich kann ihn so nicht gebrauchen. GC Prevue hat bei mir sowas noch nie gemacht und darum verlasse ich mich auch erstmal auf dieses Programm.
:
Bearbeitet durch User
Timmo H. schrieb: > Was unterstellt ihr mir denn? Also ich unterstelle garnichts, aber warst Du nicht der, der das KiCad gerbview getestet hatte und dazu schrieb "kannst vergessen"? Und Du hast zu dem gEDA gerbv einen Fehler gemeldet? Na gut, wenn er gemeldet ist ist die Sache ja erledigt, sofern du nichts verwechselt hast.
also das im Bugreport geposteten Gerber-File zeigt genau mein Problem. Von daher glaube ich nicht dass ich da was verwechselt habe.
:
Bearbeitet durch User
Timmo H. schrieb: > also das im Bugreport geposteten Gerber-File zeigt genau mein Problem. > Von daher glaube ich nicht dass ich da was verwechselt habe. Der von Dir zitierte Bugreport ist aber für das gEDA gerbv, und weiter oben schriebst du von dem KiCad gerbview mit der Aussage "kannste vergessen". Nu gut, vergessen wir es.
Timmo H. schrieb: > Hat aber den Grund, dass er schon gemeldet wurde: > http://sourceforge.net/p/gerbv/bugs/169/ Dort steht aber auch klar und deutlich, dass zumindest derjenige, der sich das angesehen hat, den Bug in der RS-274-X-Datei selbst sieht. Es ist also mehr oder minder Zufall, ob ein anderer Viewer diese Datei nun so anzeigt, wie du dir das wünschst. Es könnte mit der Datei genauso gut passieren, dass du den Platinenhersteller wechselst und der nächste dir damit eine Platine produziert, wie sie von gerbv angezeigt wird … Sicher, du wirst dann dem Hersteller die Schuld geben, denn dein gcpreview hat's ja richtig angezeigt. Das ist aber nicht maßgeblich für die Korrektheit einer Datei, sondern die Spec für RS-274-X selbst. Da du aber dir offenbar nicht einmal sicher bist, über welches der beiden (leider gleich benannten) gerbvs wir sprechen, brauchen wir da wohl nicht weiter zu diskutieren.
Angehängte Dateien:
-
gerbview.png
4,6 KB
Ja hatte gedacht dass Gerbv bestandteil von KiCad ist. Ist aber wieder was eigenes. Aber bei KiCad Gerbview habe ich auch Darstellungsfehler (siehe Bild). Hauptsächlich bei Pour Copper. Habe jetzt GC-Prevue und CAM350 in der Firma beim gleichen Gerber getestet, und da war alles ok. Darum verlasse ich mich auch weiterhin darauf. Und wenn ich bei Gerbv das Gerber analysiere sieht es auch keine Fehler. Kein Plan. Auch dieser online Gerberviewer machts richtig: http://www.gerber-viewer.com/default.aspx Keine Ahnung wer nun schuld ist. Meine Gerbers oder Gerv+Gerbview (möglicher haben die beiden ja auch die gleiche Code-Basis?!)
:
Bearbeitet durch User
Timmo H. schrieb: > Keine Ahnung wer nun schuld ist. Dann schau dir doch das RS-274-X an. Ist doch reiner Text. Ich habe bei Gerbv bislang noch nicht erlebt, dass ein Bug, der wirklich einer ist, einfach nur abgebügelt worden wäre. Sinnvoll für einen Bugreport ist natürlich immer ein möglichst kleines File.
:
Bearbeitet durch Moderator
Weil ich mir jetzt auch das 3000 Zeilen Gerber-File ansehe und ewig danach suche ob mein Gerber-File schuld ist. Sorry aber da investiere ich meine Zeit lieber anders, als mich mit sowas rumzuschlagen. Ich habe dir mal ein Minimalbeispiel gemacht (dort ist der Keepout nicht ganz rund in Gerbv 2.6.1). Wenn du Langeweile hast hast du dir das ja gerne mal ansehen.
:
Bearbeitet durch User
Timmo H. schrieb: > Weil ich mir jetzt auch das 3000 Zeilen Gerber-File ansehe Hast es doch auf 48 Zeilen runterbrechen können. ;-) Reich doch das Teil mal als Bugreport ein. Ich habe versucht, das anhand der RS-274-X-Spec zu verstehen, aber ich glaube, andere können das besser als ich. Auf jeden Fall ist die Datei irgendwie schräg. Da wird zuerst der Kreis ganz ordentlich beschrieben, bestehend aus zwei Bogensegmenten, aber ohne Füllmodus (also nur der Strich mit der aktuellen Blende). Danach wird das alles nochmal im Füllmodus beschrieben, aber diesmal sind die Kreisbögen anders aufgebaut.
Jörg Wunsch schrieb: > Auf jeden Fall ist die Datei irgendwie schräg. Da wird zuerst der > Kreis ganz ordentlich beschrieben, bestehend aus zwei Bogensegmenten, > aber ohne Füllmodus (also nur der Strich mit der aktuellen Blende). > Danach wird das alles nochmal im Füllmodus beschrieben, aber diesmal > sind die Kreisbögen anders aufgebaut. Wenn genügend es falsch machen, wird sich an den Fehler angepasst. Bekanntes Vorgehen? Vom Duden...
Michael H. schrieb: > Wenn genügend es falsch machen, wird sich an den Fehler angepasst. Ich will nicht mit Sicherheit behaupten, dass sie wirklich falsch ist. Sie sieht zumindest sehr ungewöhnlich aus. Da es aber eine relativ gute Spec gibt, die auch noch gepflegt wird, sollte es wohl das Ziel aller Programme sein, sich daran zu halten. Kann aber gut sein, dass hier einfach etwas fehlinterpretiert wird, daher ja auch mein Vorschlag mit dem Bugreport. Die 48 Zeilen, auf die das jetzt zusammengeschnitten worden ist, sollten für jemanden, der das häufiger in den Fingern hat, relativ schnell zu überschauen sein.
Angehängte Dateien:
-
Artefakte_Gerbv.png
77 KB -
Artefakte-GerbView-KiCad-I.png
120 KB -
Artefakte-Gerbview-KiCad-II.png
110 KB
Hallo Timmo H. Timmo H. schrieb: > Weil ich mir jetzt auch das 3000 Zeilen Gerber-File ansehe und ewig > danach suche ob mein Gerber-File schuld ist. > Sorry aber da investiere ich meine Zeit lieber anders, als mich mit > sowas rumzuschlagen. Das ist ja auch für Dich ok. Aber manche Programme machen eben auch einen zimlich üblen Gerber output. Manchmal habe ich den Eindruck, dass das Absicht ist..... > Ich habe dir mal ein Minimalbeispiel gemacht (dort ist der Keepout nicht > ganz rund in Gerbv 2.6.1). Wenn du Langeweile hast hast du dir das ja > gerne mal ansehen. Ich habe es mir mit Gerbv Version 2.4.0 des gEDA Projektes und GerbView Version: (2013-03-30 BZR 4007)-stable aus KiCad angesehen. Und zwar hier auf meinem PC und auch auf meinem Netbook. BS ist in beiden Fällen Debian Squeeze. Also old stable. Auf meinem PC habe ich um das Loch herum in beiden Programmen Artefakte. Bei KiCad GerbView verschwinden diese, wenn ich nahe genug herangehe. siehe Anhang Artefakte-GerbView-KiCad-I.png und Artefakte-GerbView-KiCad-II.png Bei gEDA Gerbv verschwinden die um das Loch, aber es bleibt dieser fiese horizontale Strich. Siehe Anhang Artefakte_Gerbv.png Sowas habe ich bei Gerbv noch nie gesehen.... Den Strich gibt es bei KiCad GerbView überhaupt nicht. Auf meinem Netbook ist alles ok. Das ist ein Indiz, dass die Hardware auch einen Anteil hat. Mein PC ist ein Siemens-Fujitsu Esprimo P5600, dessen Grafik nicht komplett von Linux unterstützt wird. Eingestellt ist eine Auflösung 1024x768/60hz. Was anderes geht nicht.... Mein eigenes Analyseprogramm liefert mir das was im Anhang unter test_-_Top_Copper_Analyse.txt steht. Die Anzeige selber ist aber total zerhauen, weil das Programm bis jetzt weder Polygone noch Kreise kennt, und auch nicht mit Koordinaten umgehen kann, wo entweder der X oder der Y Parameter fehlt. Ich hatte bisher noch keine Testfiles, x oder Y Parameter fehlten. Darum noch einmal herzlichen Dank für die Testdaten! Theoretisch ist zwar in der Ucamco Spezification erwähnt, das die X oder Y Parameter weggelassen werden können, aber konkret gesehen habe ich sowas bisher noch nie. Wäre ein Anlass, das mal nachzupflegen. ;O) Bei der Gelegenheit jetzt habe ich aber noch einen anderen Fehler in meinem Skript entdeckt... Darf man fragen, mit welchem Programm die Gerberdaten erzeugt wurden? Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.dl0dg.de
:
Bearbeitet durch User
Bernd Wiebus schrieb: > Bei gEDA Gerbv verschwinden die um das Loch, aber es bleibt dieser fiese > horizontale Strich. Dann solltest du mal das Rendering von "Fast" auf "Normal" umstellen. ;) "Fast" hat eigentlich nur für ältliche Maschinen Sinn, bei denen der Cairo-Renderer exorbitant langsam wird sonst. Man sollte wohl mal einen Vorschlag einreichen, dass "Normal" zum Standard erklärt wird. > Mein eigenes Analyseprogramm liefert mir das was im Anhang unter > test_-_Top_Copper_Analyse.txt steht. > Die Anzeige selber ist aber total zerhauen, weil das Programm bis jetzt > weder Polygone noch Kreise kennt, Da das Problem im Zusammenhang mit Kreisen auftritt, ist das dann hier natürlich wenig hilfreich. Aber du kannst den Script ja mal entsprechend ausbauen. Es wäre interessant, wie er diese Daten "lesbar" übersetzt.
Jörg Wunsch schrieb: > Man sollte wohl mal > einen Vorschlag einreichen, dass "Normal" zum Standard erklärt wird. Ist/war schon in der Diskussion: http://www.mail-archive.com/gerbv-devel@lists.sourceforge.net/msg00348.html
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.