Forum: Platinen [KiCAD 5.1.4] Gerber Export fehlerbehaftet


von Stefan S. (st_schulte)


Angehängte Dateien:

Lesenswert?

Moin!

Versuchen wir es mal in einem neuen Thread. Also, folgendes hat mein 
Platinen-Lieferant aus D bemängelt:

- die Plots aus den Gerber-Dateien "hängen unten unter dem Plot-Bereich"
(das kommt daher, weil KiCAD die Y-Achse immer negativ macht)

- es gibt immer "unvollständige Polynome", die manuell geschlossen bzw. 
Punkte ohne Vektoren entfernt werden müssen.
(Also Polygon bedeutet: Startpunkt + "Zwischenziele" + "..." + Endpunkt 
= geschlossenes Polygon)


Das mit der Y-Achse scheint eine Eigenheit von KiCad zu sein, vielleicht 
um die Canvas-Koordinaten ([0,0] ist links oben) nicht auf die CAM 
([0,0] ist links unten) umrechen zu müssen (Rundungs-Fehler-Gefahr?).
Ist ärgerlich für den Hersteller von Panels, wenn Altium und Co. das 
richtig machen, aber KiCad immer manuell in den positiven Bereich 
gezogen werden muß. Gut - bedeutet für meinen Lieferanten Mehrarbeit, 
die er mir aber (noch) nicht berechnet. ;-)

Das größere Problem sind aber die Fehler in den Polygonen. Leider sind 
diese im Gerber-Viewer von KiCad nicht zu sehen (siehe Screenshot GV).
Da ich auch keine CAM oder einen Photoplotter habe, hat mir mein 
Lieferant eine ältere (kostenlose) Version von GC-Preview
https://www.graphicode.com/GC-Prevue_Gerber_Viewer
zur Verfügung gestellt. Hiermit kann man die Fehler sehen/finden (siehe 
CAM Screenshot). Die weißen X sind die fehlerhaften Stellen, die mein 
Lieferant bei jeder Datei manuell bearbeiten muß. Im Moment sind es nur 
"Punkte", die er löschen kann, aber es bedeutet eben Aufwand, den er mir 
evtl. bei größeren Projekten in Rechnung stellen könnte. Natürlich 
könnte ich auf einen asiatischen Hersteller ausweichen, der KiCAD direkt 
supported oder eine CAM verwendet, die die fehlerhaften Stellen einfach 
löscht. Aber ich habe viele Vorteile bei meinem Lieferanten, die ich 
gerade für kleine private Projekte nicht missen möchte.

Besteht wohl die Möglichkeit, daß KiCad die Probleme in Zukunft löst, 
oder bin ich der Einzige, der solche "Fehlermeldungen" bekommt?

Gruß,
Stefan

PS: falls jemand dies nachvollziehen möchte, hier sind die Platine und 
Gerber-Files zum Download - 
https://drive.google.com/drive/folders/1ZTuIAVZtQyvBWTIsRE6m-5GzYfo14uxS

PPS: Wie löscht man einen doppelten Dateianhang??

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

Stefan S. schrieb:

> Versuchen wir es mal in einem neuen Thread.

Danke. Ich erlaube mir mal, die Kicad-Datei und eine der Gerberdateien 
aus deinem Google-Drive hier mit dranzuhängen, damit andere es einfacher 
haben, das nachzuvollziehen.

Antworten dann im nächsten Beitrag.

(Deinen Doppel-Anhang habe ich gelöscht.)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

So, hier erstmal die Geschichte mit den negativen Koordinaten in den 
Gerberdaten. Dazu setzt du sinnvollerweise einerseits den 
Koordinatenursprung im Kicad und andererseits die "auxiliary axis" auf 
die Ecke links unten in deinem Design. Ich habe dir mal die beiden Icons 
rot umrandet und die Symbole, die dann auftauchen.

Außerdem lässt du beim Plotten alles relativ zu ebendieser auxiliary 
axis ausgeben.

Außerdem anbei die neue Kicad-Datei sowie eine Gerber-Lage.

von Stefan S. (st_schulte)


Angehängte Dateien:

Lesenswert?

Moin Jörg!

Ja, das mit dem Ursprung hatte ich schon gemacht (wir Du mir geschrieben 
hattest), ohne Erfolg - aber der Haken bringt es!
Da ich die deutsche Version verwende hat es nicht gleich geschnackelt 
:-)
Das Thema ist also schon abgearbeiteit. It works!

PS: Danke fürs "Aufräumen". Und ein Bild sagt eben mehr als 1000 Worte 
...

von Karsten B. (kastenhq2010)


Lesenswert?

Bei den fünf Gerberfiles von Google Drive ist nicht die kaputte aus dem 
ersten Post dabei.

von Stefan S. (st_schulte)


Angehängte Dateien:

Lesenswert?

Öhm, doch ..._B_Cu.gbl
Die Ansicht ist mit P und L nur auf Outline gestellt ;-)

von Karsten B. (kastenhq2010)


Lesenswert?

Jetzt wo du es sagst, ich muss blind gewesen sein.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Ich schau mir das auch gerade an. Ist komplizierter, muss mich da 
erstmal durch die Gerber-Spec von Ucamco durchlesen.

von Karsten B. (kastenhq2010)


Lesenswert?

Die Polygone sind geschlossen, der Endpunkt steht aber doppelt in den 
Gerberfiles:

Startpunkt, Zeile 411-412
G36*
X138507505Y-103695204D02*

Endpunkt, Zeile 481-483
X138507505Y-103695204D01*
X138507505Y-103695204D01*
G37*

Warum Kicad das macht, weiß ich nicht, notwendig ist es meines Wissens 
nicht und wahrscheinlich verschluckt sich das Tool deines Lieferanten.

von Karsten B. (kastenhq2010)


Lesenswert?

Und überhaupt: die acht fehlerhaften Polygone mit dem Kreis in der Mitte 
- sind das einfache Rechtecke mit Radien in den Ecken? So eine Rundung 
kann man mit Gerber in 3 Zeilen beschreiben, Kicad setzt da 15 Punkte 
drauf und verbindet diese mit Geraden? Das ist eher ungeschickt gelöst.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hier mal ein Versuch einer Analyse.

Alle Gerber-Viewer, die ich habe, haben erstmal kein Problem, die Kontur 
geschlossen anzuzeigen. Das ist außer dem Kicad-eigenen noch "gerbv" 
(welches ich gern als "unabhängige Instanz" auf die CAM-Daten loslasse, 
um sie vor der Fertigung nochmal zu begutachten – egal, von welchem Tool 
die Daten nun gerade sind), andererseits BAE's CAM-Viewer, der auch 
mehrere verschiedene Darstellungen der Daten ermöglicht.

Gut, das ist natürlich immer noch keine definitive Aussage, ob die Daten 
nun tatsächlich in Ordnung sind, oder halt alle Tools einfach über den 
Fehler hinweg sehen.

Ich habe mir die von GC-Preview angemoserte linke obere Ecke mal 
vorgenommen, und daneben die Gerber-Spezifikation von Ucamco. Der 
Screenshot zeigt die fraglichen Elemente in gerbv's Darstellung, da 
sieht man die zugehörigen Koordinaten ganz gut. Sie beziehen sich auf 
die originale …B_Cu.gbl (mit den negativen Y-Werten).

Die Gerber-Spec ist erstmal eindeutig in dieser Aussage:
1
When a D02 is encountered the contour is considered finished.
2
(Note that a D02 always finishes a contour even the current
3
point does not change, e.g. a D02*.) A D02 is only allowed
4
if the preceding contour is closed.

Gut.

Die relevanten Daten:
1
G36*
2
X133318815Y-95218815D02*
3
G01*
4
X133239463Y-95315506D01*
5
6
X132685000Y-95185000D01*
7
X133360019Y-95185000D01*
8
X133318815Y-95218815D01*
9
X133318815Y-95218815D01*
10
G37*
11
X133318815Y-95218815D02*

Das einzige, was daran auffällt ist, dass der Punkt (133.318815, 
-95.218815) zweimal gezeichnet wird. Das sollte allerdings grundsätzlich 
kein Problem sein (wenn auch ein Schönheitsfehler), denn die Kontur wird 
erst mit einem D02 beendet, und das ist an dieser Stelle noch nicht 
gekommen. Das D02 kommt danach, am gleichen Punkt (was zulässig ist).

Der Beispielcode in der Spec sieht ansonsten in der Reihenfolge 
vergleichbar aus:
1
Syntax              | Comments
2
G36*                | Start a region
3
X200Y300000D02*     | Move the current point to (2, 3)
4
G01*                | Set linear interpolation
5
X700000D01*         | Line segment to (7, 3)
6
Y100000D01*         | Line segment to (7, 1)
7
X1100000Y500000D01* | Line segment to (11, 5)
8
X700000Y900000D01*  | Line segment to (7, 9)
9
Y700000D01*         | Line segment to (7, 7)
10
X200000D01*         | Line segment to (2, 7)
11
Y300000D01*         | Line segment to (2, 3)
12
G37*                | Create the region by filling the contour

Kannst ja mal versuchen, den doppelten Punkt zu löschen, und dann sehen, 
ob GC-Preview damit zufriedener ist.

Ich würde es zwar schon fast unter "Krümelkackerei" einsortieren, das 
anzumosern, andererseits ist es natürlich auch nicht sinnvoll, den Punkt 
zweimal da zu generieren. Insofern – falls es in der aktuellen 
Kicad-Version nach wie vor so ist – wäre es dann einen Bugreport wert.

: Bearbeitet durch Moderator
von Daniel B. (daniel_3d)


Lesenswert?

Stefan S. schrieb:
> oder bin ich der Einzige, der solche "Fehlermeldungen" bekommt?

Nein, bist du nicht.
Ich habe vor ein paar Monaten die selben Gerber-Dateien zu JLCPCB und 
Aisler hochgeladen. In der Vorschau waren bei JLCPCB Halbkreise falsch 
herum dargestellt, bei Aisler richtig herum.
Das betraf aber nur den Bestückungsdruck.
Wenn gewünscht kann ich noch ein paar Bilder raussuchen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Karsten B. schrieb:
> Die Polygone sind geschlossen, der Endpunkt steht aber doppelt in den
> Gerberfiles:

Gut, du warst etwas schneller. :-)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Karsten B. schrieb:
> Das ist eher ungeschickt gelöst.

Zulässig ist es allerdings trotzdem, und für das Resultat im Grunde 
genommen egal.

Dass man es im Gerber schöner ausdrücken könnte, heißt noch nicht, dass 
man solch eine Vereinfachung auch einfach in den Generator-Code 
eingefügt bekommt. Hängt ein bisschen davon ab, welche Informationen der 
an dieser Stelle selbst vorliegen hat.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Stefan S. schrieb:
> aber der Haken bringt es!

Beim Erzeugen der Bohrdateien muss man übrigens schauen, dass er dort 
auch gesetzt ist. (War in deinem Beispiel der Fall.)

Ansonsten haben die Bohrdaten dann einen Offset zu den Gerberdaten.

von Stefan S. (Gast)


Lesenswert?

Ui, das sieht doch richtig gut aus!

Was die Rundungen angeht - wenn die Auflösung hoch genug ist, stört das 
eigentlich nicht. Aber es könnte sein, das sich da noch etwas tut:
https://bugs.launchpad.net/kicad/+bug/1576979

Das mit den doppelten Punkten habe ich mal gemeldet. Damit der Fehler 
zur Behebung angenommen wird braucht es ja erst mal Unterstützer.
https://bugs.launchpad.net/kicad/+bug/1847714

Außerdem habe ich mir erlaubt die Ausführungen von Jörg zu kopieren, 
aber auch einen Link zu diesem Thread gesetzt (mit Hinweis auf deutsch).

Ich bin richtig gespannt, was daraus wird. Vielen Dank euch allen!

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Stefan S. schrieb:
> Das mit den doppelten Punkten habe ich mal gemeldet.

Wie ist das, wenn du sie manuell aus der Datei entfernst, verschwindet 
dann die Fehlermarkierung bei GCpreview?

von Bernd W. (berndwiebus) Benutzerseite


Lesenswert?

Hallo Jörg.

Jörg W. schrieb:

> Alle Gerber-Viewer, die ich habe, haben erstmal kein Problem, die Kontur
> geschlossen anzuzeigen. Das ist außer dem Kicad-eigenen noch "gerbv"
> (welches ich gern als "unabhängige Instanz" auf die CAM-Daten loslasse,
> um sie vor der Fertigung nochmal zu begutachten – egal, von welchem Tool
> die Daten nun gerade sind), andererseits BAE's CAM-Viewer, der auch
> mehrere verschiedene Darstellungen der Daten ermöglicht.
>
> Gut, das ist natürlich immer noch keine definitive Aussage, ob die Daten
> nun tatsächlich in Ordnung sind, oder halt alle Tools einfach über den
> Fehler hinweg sehen.

Ucamco als Schöpfer von Gerber bietet selber einen online referenz 
viewer. *) Ok, auch Ucamco ist nicht Gott, und kann Fehler machen.....

Dem TO würde ich aber durchaus empfehlen, falls der Referenzviewer von 
Ucamco keinen Fehler zeigt, den Leiterplattenhersteller darauf 
hinzuweisen.

Gerber ist ja durchaus dafür gemacht, in solchen Fällen robust zu 
reagieren. Zumindest negative Koordinaten sollten kein Problem sein.....


*) Link auf Ucamcos Referenz Viewer: https://gerber-viewer.ucamco.com/

mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.dl0dg.de

: Bearbeitet durch User
von Bernd W. (berndwiebus) Benutzerseite


Angehängte Dateien:

Lesenswert?

Nachtrag:

Bernd W. schrieb:

> Dem TO würde ich aber durchaus empfehlen, falls der Referenzviewer von
> Ucamco keinen Fehler zeigt, den Leiterplattenhersteller darauf
> hinzuweisen.

Ich habe Stefans Gerberdaten von obigem Google-drive Link mal in den 
Ucamco Viewer gestopft.

Das Ergebnis ist im Anhang. Kein Fehler sichtbar.

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.dl0dg.de

von Georg (Gast)


Lesenswert?

Bernd W. schrieb:
> Das Ergebnis ist im Anhang. Kein Fehler sichtbar.

Das ist für mich auch durchaus logisch. Gerber-Befehle sind Linien, und 
bei einem geschlossenen Umriss geht die letzte zu zeichnende Linie 
zurück zum Startpunkt - sonst wäre es ja kein geschlossener Linienzug. 
Die Version in der der Startpunkt 2mal vorkommt ist also die richtige.

Daran ändert auch die Tatsache nichts, dass manche Interpreter für eine 
Polygon-Umrandung den Umriss selbstständig schliessen, indem sie die 
fehlende Strecke ergänzen.

Dass chinesische Hersteller so sehr sparen (müssen), dass sie weder 
qualifiziertes Personal noch geeignete Software einsetzen, ist jetzt 
auch nicht so neu.

Georg

von Karsten B. (kastenhq2010)


Lesenswert?

Georg schrieb:
> Das ist für mich auch durchaus logisch. Gerber-Befehle sind Linien, und
> bei einem geschlossenen Umriss geht die letzte zu zeichnende Linie
> zurück zum Startpunkt - sonst wäre es ja kein geschlossener Linienzug.
> Die Version in der der Startpunkt 2mal vorkommt ist also die richtige.

Der Startpunkt kommt in den Gerberfiles, die Kicad erzeugt, aber dreimal 
vor. Einmal am Anfang und zweimal am Ende des Polygons. Letzteres mag 
die CAM Software des Leiterplattenherstellers anscheinend nicht.

Jörg W. schrieb:
> Karsten B. schrieb:
>> Das ist eher ungeschickt gelöst.
>
> Zulässig ist es allerdings trotzdem, und für das Resultat im Grunde
> genommen egal.

Wenn es nicht dazu führt, dass bei größeren Strukturen Abstände 
unterschritten werden, dann "ja" :) Kicad scheint dies aber zu beachten, 
indem es bei großen Kreisbögen mehr Punkte setzt.

Jörg W. schrieb:
> Das sollte allerdings grundsätzlich
> kein Problem sein (wenn auch ein Schönheitsfehler), denn die Kontur wird
> erst mit einem D02 beendet, und das ist an dieser Stelle noch nicht
> gekommen. Das D02 kommt danach, am gleichen Punkt (was zulässig ist).

Das G37 beendet bereits die Kontur, die nachfolgende Zeile mit D02 
startet die neue Kontur. Sonst aber alles richtig.

von Bernd B. (bbrand)


Lesenswert?

Georg schrieb:
> Dass chinesische Hersteller so sehr sparen (müssen), dass sie weder
> qualifiziertes Personal noch geeignete Software einsetzen, ist jetzt
> auch nicht so neu.

Laut erstem Beitrag war's aber ein deutscher Hersteller (oder zumindest 
Lieferant, das heißt ja noch lange nicht, dass sie auch in D produziert 
werden).

Gruß,
Bernd

von Stefan S. (st_schulte)


Angehängte Dateien:

Lesenswert?

Hallo zusammen!

Also fasse ich mal zusammen :-)

Ja, der Gerber-Plot ist nach dem Entfernen der doppelten Punkte 
fehlerfrei (siehe Anhang). Und ja, es ist kein NoGo o.ä. - schließlich 
gibt es ja CAMs und Hersteller, die mit den Daten zurecht kommen.

Aber ja, mein Lieferant poolt für deutsche Hersteller, und ja, die CAM 
ist durchaus nicht mehr "aktuell". Allerdings ergeben sich dadurch zwei 
Vorteile, die ich mag:

1. der Support ist in deutsch und
2. die Preise fast vergleichbar mit China, wenn man Liefer- und 
Produktions-Zeit addiert, so wie die Kosten, wenn "nur mal ne Platine 
braucht".

Und das immer noch (ich kenne den Lieferant seit > 10 Jahren!) zu 
ähnlichen Preisen. Da muß man eben bei den laufenden Kosten sparen, 
indem man nicht dauernd neue Software und Maschinen kauft, und möglichst 
viel automatisiert, um immer das gleiche Ergebnis zu liefern.

Auch ich arbeitete mit einer Uralt Eagle-Version, die ich mir mal 
gekauft habe. Aber die läuft eben nur in einer VM. Und ich mag KiCad 
seit Version 5, weil sie sich enorm entwickelt haben (und eben nativ 
unter Linux läuft).
Ich gehöre außerdem zu den Leuten, die laut meckern, wenn ihnen etwas 
nicht passt. Aber ich versuche eben auch konstruktiv zu sein. Sonst geht 
das nach hinten los!

Auch dieses Mal hat es funktioniert:
Der Bug ist gefixt und soll in Version 5.1.5 released werden!

von Bernd W. (berndwiebus) Benutzerseite


Lesenswert?

Hallo Georg und Stefan.


Georg schrieb:

>> Das Ergebnis ist im Anhang. Kein Fehler sichtbar.
>
> Das ist für mich auch durchaus logisch. Gerber-Befehle sind Linien, und
> bei einem geschlossenen Umriss geht die letzte zu zeichnende Linie
> zurück zum Startpunkt - sonst wäre es ja kein geschlossener Linienzug.
> Die Version in der der Startpunkt 2mal vorkommt ist also die richtige.
>
> Daran ändert auch die Tatsache nichts, dass manche Interpreter für eine
> Polygon-Umrandung den Umriss selbstständig schliessen, indem sie die
> fehlende Strecke ergänzen.

Das Gerber Format ist auf Robustheit getrimmt. Solche "Fehler" gehen 
dabei einfach unter. ;O)
Einer der großen Vorteile von Gerber.

Trozdem, weil der Gerberoutput so essenziell für eine 
Platinenlayoutsoftware ist, sollte er auch keine "Schönheitsfehler" 
aufweisen. Wenn die sich häufen, langt irgendwann die Robustheit auch 
nicht mehr.

Aber das Problem ist nach


Stefan S. schrieb:

> Auch dieses Mal hat es funktioniert:
> Der Bug ist gefixt und soll in Version 5.1.5 released werden!

ja schon gelöst.

> Ich gehöre außerdem zu den Leuten, die laut meckern, wenn ihnen etwas
> nicht passt. Aber ich versuche eben auch konstruktiv zu sein. Sonst geht
> das nach hinten los!

Gut so! Danke für Deinen Bug Report!


Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.dl0dg.de

: Bearbeitet durch User
von Georg (Gast)


Lesenswert?

Karsten B. schrieb:
> Der Startpunkt kommt in den Gerberfiles, die Kicad erzeugt, aber dreimal
> vor. Einmal am Anfang und zweimal am Ende des Polygons

Das hatte ich falsch verstanden, aber selbst wenn: 2mal dieselbe 
Koordinate am Ende ist ein Befehl, eine Linie mit der Länge 0 zu 
zeichnen. Eigentlich auch kein Grund gleich auszurasten. Ein tatsächlich 
noch physikalisch arbeitender Plotter (Stift/Photo) würde da einen 
runden Punkt zeichnen, was an der Stelle überhaupt nicht stören würde.

Georg

von Bernd W. (berndwiebus) Benutzerseite


Lesenswert?

Hallo Geotg.

Georg schrieb:

> Das hatte ich falsch verstanden, aber selbst wenn: 2mal dieselbe
> Koordinate am Ende ist ein Befehl, eine Linie mit der Länge 0 zu
> zeichnen. Eigentlich auch kein Grund gleich auszurasten.

Zumindest nicht in einem Polygon. ;O)

Bei einer Linie in einem Kupferlayer ist es aber schon ein Umterschied, 
ob Du mit einer Apertur eine Linie (Draw) der Länge Null ziehst, oder ob 
Du mit der gleichen Apertur einen Blink machst, auch wenn letztlich im 
Kupfer das gleiche Bild liegt.

Der Unterschied liegt in weiteren Programmen, die "automatisch" aus 
Gerber die Files für einen flying Probe Test generieren. Dann wird 
tatsächlich ein Draw der Länge Null als Kupferverbindung (in Form der 
Apertur) gewertet, und ein Blink mit dieser Apertur als Pad (in Form der 
Apertur).
Der Test läuft, indem man zwischen den Pads misst, ob eine Verbindung 
besteht oder nicht. Wenn Du dann statt der Null Längen Draws Blinks 
gemacht hast, wird dort unnötig oft getestet, und wenn Du statt der 
Blinks Nulllängen Draws verwendet hast, wird dort überhaupt nicht 
getestet, was letztlich schlimmer ist.

Bei großen,Polygonen wird im allgemeinen auch nur an den Pads getestet, 
und manuell reduzierst Du den Test oft auch noch auf ein kontaktiertes 
Pad im Polygon, weil Du bei dicken breiten Polygonen mit mehreren Pads 
ziemlich sicher sein kannst, dass dort keine Unterbrechung zwischen den 
Pads im Polygon existiert.

Das ist auch einer von mehreren Gründen, warum komplexe Footprints mit 
Pads, die aus mehreren Pads und/oder Leiterbahnen zusammengesetzt sind,
extra inspiziert werden müssen. Genauso wie Polygon Flächen, die mangels 
echter Polygonfunktion aus Draws zusammengesetzt sind.

Als weiteres Indiz kann dann auch noch die Lötstoppmaske herangezogen 
werden....

> Ein tatsächlich
> noch physikalisch arbeitender Plotter (Stift/Photo) würde da einen
> runden Punkt zeichnen, was an der Stelle überhaupt nicht stören würde.

Richtig. Diese Vorstellung, was eine "echter" Plotter machen würde ist 
sehr hilfreich, wenn man Gerberfiles inspiziert und beurteilen möchte, 
ob das Ergebnis sinnvoll und brauchbar ist.
Wegen der Feinheiten siehe oben und weiter unten.

Desweiteren muss ein Ätzzuschlag für die Breite der Leiterbahnen 
eingerechnet werden. Auch dabei sollten keine Kurzschlüsse entstehen.
Langt der Platz dafür aber nicht, muß dafür vorher an Flächen das Kupfer 
etwas zurückgezogen werden. Da ist es dann lässtig, wenn die Flächen 
keine Polygone sind, sondern Konstrukte aus Linien und Pads, die dabei 
zerfallen können, wenn sie sich nicht weit genug überlappen.

Zu guter Letzt werden sehr dünne Stellen, die sich "zufällig" bei 
Anschnitten von Strukturen gebildet haben oder Zwickel noch 
verbreitert/geschlossen oder abgestumpft, damit sich dort beim Ätzen 
nichts von der Maske löst und anderswo Ärger macht.

Unter diesen Gesichtspunkten sind die Gerberfiles aus dem fraglichen 
Beispiel oben aber unkritisch. ;O)

Und wer selber ätzt, sieht in diesen Punkten sehr direkt, was er macht 
und was schiefgeht. Ätzzuschlag berechnen ist bei den groben Strukturen 
meist nicht nötig, und flying Probe Tests sind bei Selbstgeätztem auch 
eher selten.
Wer Ätzen lässt, überträgt diese Aufgaben an den Platinenhersteller, und 
der hat dann den Ärger damit. Diesen Ärger kann man als Auftraggeber 
reduzieren, indem man selber vorher kurz seine Gerberfiles auf solche 
Schwachstellen inspiziert.

Die Zusatzarbeit beim CAM-Input in der Fabrik zahlen über eine 
Mischkalkulation letztlich alle, und wenn der Fertiger zurückfragen muss 
oder einen Fehler macht, ist das zumindest ein Zeitverzug.

Darum ist es ja auch sinnvoll, Gerberfiles einzureichen, und nicht die 
Boardfiles. Diese enthalten noch zu viele Indormationen, die es bei 
einer Inspektion schwer machen, zu Entscheiden und somit zu (teilweise 
sehr teuren) Missverständnissen führen.
Gerber ist in dieser hinsicht viel klarer, was die Gefahr von 
Missverständnissen minimiert.




Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.dl0dg.de

: Bearbeitet durch User
von Stefan S. (st_schulte)


Angehängte Dateien:

Lesenswert?

Moin!

Ich kann bestätigen, der der Bug in den Nightly Builds vom 12.10.19 
behoben wurde. Ein Test auf meinem Win7 x64 Notebook für Softwaretests 
zeigt keinerlei Fehler mehr in GC-Prevue (siehe Screenshot).
Wer es selber probieren möchte:
https://kicad-downloads.s3.cern.ch/windows/nightly/kicad-r14328.337244d42-x86_64.exe 
(64Bit Download) bzw.:
https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/nightly/
(Alle NightlyBuilds von KiCad für Windows)

Natürlich muß man an dieser Stelle drauf hinweisen, daß es sich hier 
nicht um eine Stabile Version handelt, sondern um eine Test-Version, die 
alle gefixten Bugs zum jeweiligen Build-Datum enthält.
Daher habe ich auch nur die Windows-Version gestestet. Auf meinem Linux 
läuft weiter 5.1.4 (stable). Aber ich werde die Gerber-Exporte jetzt auf 
diesem Notebook vornehmen. 8-)


Gruß,
Stefan

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Stefan S. schrieb:
> Ich kann bestätigen, der der Bug in den Nightly Builds vom 12.10.19
> behoben wurde.

Schön, danke fürs Dranbleiben!

Wir haben nebenbei alle (oder zumindest viele) mal was über Details des 
Gerberformats gelernt. ;-)

ps: Vielleicht weißt du ja jetzt, warum ich dich so vehement dran 
gehindert habe, die alten Threads mit der "verkehrt herum zählenden" 
Y-Achse dafür auszubuddeln. Der eigene Thread hat sich auf jeden Fall 
gelohnt, finde ich.

von Stefan S. (st_schulte)


Lesenswert?

Moin Jörg,

zugegeben, ich gehörte durch Eagle bisher zu den .brd-Abgebern. Aber wir 
hatten in der Uni einen eigenen Leiterplatten-Service, der hat für uns 
Studenten auch gegen geringes Entgeld ungebohrte Platinen mit gemacht.
Da konnte man Gerber Dateien abgeben (auf Diskette :-) - doch die waren 
pur nach Vorgabe erstellt.

Meine Initialen Kenntnisse von KiCad 5 stammen von Tom Gem (dj9zzz) auf 
YT (z.B. dieses https://www.youtube.com/watch?v=nXitViZB4j8), der Rest 
dann eben von meinem Leiterplatten-Lieferanten, sofern es ihn betraf ;-)

Und die Geschichte mit den negativen Y-Koordinaten hätte man (Du) auch 
mit einem Post in einem der älteren Threads abhandeln können :o)

Aber ein Beitrag hier lohnt sich immer!

von Stefan S. (st_schulte)


Lesenswert?

Nachtrag:

So, meine Daten sind mittlerweile fehlerfrei beim Lieferanten angenommen 
worden. Allerdings habe ich versehentlich bzw. ohne nachzudenken die 
Platine  nach dem Plot in der Nightly-Version gespeichert. Als ich dann 
bei der Bestellung unter Linux kurz die Größe ausmessen wollte, kam die 
Fehlermeldung, daß ich eine zu alte Version von KiCad benutze.
Also schnell mal in die erste Zeile
1
(kicad_pcb (version 20171130) (host pcbnew "(5.1.4)-1")
geschrieben, weil ich dachte, es ist ja nur eine Sub-Version entfernt,
doch Pustekuchen! Es hat sich die Struktur des .kicad_pcb geändert.
Zum Glück ist die Datei nach dem Entfernen der Defaults in Setup wieder 
nutzbar (bei mir!)
1
    (max_error 0.005)
2
(defaults
3
      (edge_clearance 0.01)
4
      (edge_cuts_line_width 0.15)
5
      (courtyard_line_width 0.05)
6
      (copper_line_width 0.2)
7
      (copper_text_dims (size 1.5 1.5) (thickness 0.3))
8
      (silk_line_width 0.15)
9
      (silk_text_dims (size 1 1) (thickness 0.15))
10
      (other_layers_line_width 0.1)
11
      (other_layers_text_dims (size 1 1) (thickness 0.15))
12
)
Also Vorsicht bei der Nutzung von Versionen > 5.1.4 !

Gruß,
Stefan

: Bearbeitet durch User
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
Noch kein Account? Hier anmelden.