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
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.)
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.
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 ...
Bei den fünf Gerberfiles von Google Drive ist nicht die kaputte aus dem ersten Post dabei.
Öhm, doch ..._B_Cu.gbl Die Ansicht ist mit P und L nur auf Outline gestellt ;-)
Ich schau mir das auch gerade an. Ist komplizierter, muss mich da erstmal durch die Gerber-Spec von Ucamco durchlesen.
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.
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.
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
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.
Karsten B. schrieb: > Die Polygone sind geschlossen, der Endpunkt steht aber doppelt in den > Gerberfiles: Gut, du warst etwas schneller. :-)
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.
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.
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!
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?
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
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
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
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.
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
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!
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
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
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
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
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.
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!
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.