Eagle Excellon - Bohrkoordinaten stimmen nicht

@ Nico (Gast)

>verarbeiten. Mein Problem ist jedoch, dass die Bohrkoordinaten nicht mit
>den tatsächlichen übereinstimmen. Hier ein Beispiel:

Eagle hat die kleine Macke, dass es eine Art zufälligen Offset in die 
Gerber- und Excellondaten reinbringt. Das wird offiziell darum gemacht, 
um alle Koordinaten positiv zu machen, weil manchmal alte CAM-Software 
Probleme mit negativen Zahlen hat.

Wenn man die Option "Positive Koordinaten) deaktiviert, wird (meist) 
kein Offset erzeugt und die Koordinaten stimmen 1:1 zwischem CAD und 
Gerber.

http://www.eaglecentral.ca/forums/index.php/mv/msg/32057/110436/

https://forum.sparkfun.com/viewtopic.php?t=16524

@ Falk Brunner

DANKE!!!!!!!!!!!!!!!!!!!!!!

Was ein einzelner Haken ausmachen kann!

Ohne das Häkchen bei Pos.Koord. zu setzen passt das Ganze.

Output:

------------------------------------
%
M48
M72
T01C0.0394
%
T01
X394Y394
X1969Y1969
X3937Y3937
X39370Y39370
M30
-------------------------------------

Vielen Dank für die schnellen Antworten!!!!
Schönes Wochenende noch

@ Nico Theodorou (noco)

>Was ein einzelner Haken ausmachen kann!

Frag mal die Boxer, die können ein Lied davon singen 8-0

>>Was ein einzelner Haken ausmachen kann!
Falk Brunner schrieb:
> Frag mal die Boxer, die können ein Lied davon singen 8-0

Ist das schön!
:-)))

Wunderbar -Das hätte ich auch nicht anders sagen können.

MfG Paul

Exportiert Eagle bei Excellon nicht sowieso in Inch?

Es gibt auch ein Bug mit den "leading zeros" im Excellon-Format, 
standardmäßig füllt ein Excellon-Interpreter rechts mit Nullen auf sechs 
Ziffern auf.

X394Y394, X3937Y3937 und X39370Y39370 wären also eigentlich die gleichen 
Koordinaten.

Anstatt "M72" müsste im Header eigentlich "INCH,TZ" stehen.

Georg schrieb:
> Sowieso hat jedes CAD-System sein eigenes inneres Datenformat, die Frage
> metrisch, inch oder sonstwas stellt sich nur für die Anzeige für die
> Menschen vor dem Bildschirm mit ihrer viel geringeren Rechenleistung.

Eagle 4.16 rechnet intern metrisch- bei einem "angloamerikanischen 
Maßsystem" Raster kann es vorkommen, dass Eagle nicht "einrasten" kann.

@ Heiko L. (drcaveman)

>> Sowieso hat jedes CAD-System sein eigenes inneres Datenformat, die Frage
>> metrisch, inch oder sonstwas stellt sich nur für die Anzeige für die
>> Menschen vor dem Bildschirm mit ihrer viel geringeren Rechenleistung.

>Eagle 4.16 rechnet intern metrisch- bei einem "angloamerikanischen
>Maßsystem" Raster kann es vorkommen, dass Eagle nicht "einrasten" kann.

Nö, denn die interne Auflösung war bei Eagle 4.x bei 0,1 µm, bei Eagle 
6.x ist sie glaub ich noch höher. Und dass die Jungs von Egale die 
Umrechung ohne akkumulierende Rundungsfehler hinbekommen, kann man 
einfach mal glauben ;-)

@ michael_ (Gast)

>> Ich habe 4 Löcher bei (alles in mm) [1,1], [5,5], [10,10] und [100,100]

>Sag mir einen Grund, warum man diese schönen metrischen Maße in irgend
>etwas anderes umrechnen soll?

Wahrscheinlich weil er nicht weiß, wie man metrische Gerberdaten in 
Eagle erzeugt. Geht einfach.

[Installpath]/Eagle-x.y.z/bin/eagle.def um diesen Abschnitt ergänzen.

1

[GERBER_RS274X_MM]

2

3

@GERBERAUTO

4

Long          = "Gerber RS-274-X photoplotter, coordinate format 3.3 metric"

5

Units         = MM

6

Info          = "Plotfile Info:\n"\

7

                "\n"\

8

                " Coordinate Format : 3.3\n"\

9

                " Coordinate Units  : mm\n"\

10

                " Data Mode         : Absolute\n"\

11

                " Zero Suppression  : None\n"\

12

                " End Of Block      : *\n"\

13

                "\n"

14

Init          = "G75*\n"           \ allow positive and negative coordinates

15

                "%%MOMM*%%\n"      \ MOde of units is INch (MM for mm)

16

                "%%OFA0B0*%%\n"    \ horizonal and vertical OFfset is 0

17

                "%%FSLAX33Y33*%%\n"\ Format Statement is Absolute (I for incremental) 3.3

18

                "%%IPPOS*%%\n"     \ Image Polarity is POSitive (NEG for negative)

19

                "%%LPD*%%\n"       \ Layer Polarity Dark (C for clear on negative planes)

20

                "%%AMOC8*\n5,1,8,0,0,1.08239X$1,22.5*\n"\ Octagons are emulated with a circle (using 8 vertices)

21

                "%%\n"            ; and therefore the diameter must be enlarged with '1 / cos(pi / 8)'

22

Reset         = "M02*\n"

23

ResX          = 25400

24

ResY          = 25400

25

Move          = "X%0.7dY%0.7dD02*\n"    ; (x, y)

26

Draw          = "X%0.7dY%0.7dD01*\n"    ; (x, y)

27

Flash         = "X%0.7dY%0.7dD03*\n"    ; (x, y)

28

Circle        = "%%AD%sC,%7.5f*%%\n"        ; (code, diameter)

29

Rectangle     = "%%AD%sR,%7.5fX%7.5f*%%\n"  ; (code, dx, dy)

30

Oval          = "%%AD%sO,%7.5fX%7.5f*%%\n"  ; (code, dx, dy)

31

; According to the RS-274-X specs there is an aperture macro

32

; primitive that allows us to specify an octagon (i.e. a polygon with

33

; 8 vertices). As some Gerber viewers seem to have problems with that,

34

; we would have to use a round shape for that.

35

; If your Gerber processor cannot handle the polygon primitive you may

36

; uncomment the following line and comment out the line after it:

37

;Octagon       = "%%AD%sC,%7.5f*%%\n"   ; (code, diameter) (looks like there is no octagon, so we take a circle)

38

Octagon       = "%%AD%sOC8,%7.5f*%%\n" ; (code, diameter)

39

AreaBegin     = "G36*\n"

40

AreaEnd       = "G37*\n"

41

42

[EXCELLON_MM]

43

44

Type     = DrillStation

45

Long     = "Excellon drill station, 3.3 metric"

46

Init     = "%%\nM48\nM71\n"

47

Reset    = "M30\n"

48

ResX     = 25400

49

ResY     = 25400

50

;Rack     = ""

51

DrillSize  = "%sC%0.4f\n"        ; (Tool code, tool size)

52

AutoDrill  = "T%02d"             ; (Tool number)

53

FirstDrill = 1

54

BeginData  = "%%\n"

55

Units    = mm

56

Select   = "%s\n"                ; (Drill code)

57

Drill    = "X%1.0fY%1.0f\n"      ; (x, y)

58

Info     = "Drill File Info:\n"\

59

           "\n"\

60

           " Data Mode         : Absolute\n"\

61

           " Units             : 1/1000 mm\n"\

62

           "\n"

Dann kann man mit diesen CAM-Jobs im Anhang (in /cam kopieren) mit einem 
Click komplette metrische Gerber- und Excellondaten erzeugen.

Falk Brunner schrieb:

> Nö, denn die interne Auflösung war bei Eagle 4.x bei 0,1 µm, bei Eagle
> 6.x ist sie glaub ich noch höher. Und dass die Jungs von Egale die
> Umrechung ohne akkumulierende Rundungsfehler hinbekommen, kann man
> einfach mal glauben ;-)

Ich hatte bei 4.16 immer Wire-"Gnubbel" an Pads und Wire-Verbindungen 
(konnte wohl nicht richtig fangen), die seit Umstellung auf "metrisch" 
verschwunden waren.

Falk Brunner schrieb:

> Dann kann man mit diesen CAM-Jobs im Anhang (in /cam kopieren) mit einem
> Click komplette metrische Gerber- und Excellondaten erzeugen.

Schreibt er dann auch führende Nullen?

@ Heiko L. (drcaveman)

>> Dann kann man mit diesen CAM-Jobs im Anhang (in /cam kopieren) mit einem
>> Click komplette metrische Gerber- und Excellondaten erzeugen.

>Schreibt er dann auch führende Nullen?

Weiß ich nicht, probiers aus.

@ Heiko L. (drcaveman)

>Ich hatte bei 4.16 immer Wire-"Gnubbel" an Pads und Wire-Verbindungen
>(konnte wohl nicht richtig fangen), die seit Umstellung auf "metrisch"
>verschwunden waren.

Das kann man einfach lösen, indem man immer am Pad mit dem Routing 
anfängt.
Eagle springt dan so bald wie möglich aufs aktuelle Raster. Damit kann 
man JEDES X-beliebige Pad mit JEDEM Y-beliebeigen Raster absolut gerade 
anschließen.

Falk Brunner schrieb:

> Weiß ich nicht, probiers aus.

Drill    = "X%06.0fY%06.0f\n"

Das sieht für mich stimmiger aus, jetzt rein für die Excellon Ausgabe.

Das Problem bei der metrischen Excellon Ausgabe ist wohl auch noch die 
Unterscheidung zwischen 10µm und 1µm Auflösung. Das wird wohl scheinbar 
über die Angabe der Stellen gemacht, habe ich aber auch noch nicht so 
recht verstanden. Vielleicht wird auch deshalb die Ausgabe standardmäßig 
in Inch gemacht, da gibt es wohl nicht all zu viele Missverständnisse 
(allerdings auch nur noch 2,54µm Auflösung).

Falk Brunner schrieb:

> Das kann man einfach lösen, indem man immer am Pad mit dem Routing
> anfängt.
> Eagle springt dan so bald wie möglich aufs aktuelle Raster. Damit kann
> man JEDES X-beliebige Pad mit JEDEM Y-beliebeigen Raster absolut gerade
> anschließen.

Zeigt aber auf, dass es doch nicht nur rein optisch ist.

Georg schrieb:

> Wozu? Selbst wenn es noch Uralt-Maschinen mit diesem Format gibt, die
> bekommen die Daten ja nicht zu sehen, sondern die werden in eine
> CAM-Station eingelesen - und die kann alles was es gibt.

Und woher soll die dann wissen ob mit "X5Y5" "X00.0005Y00.0005" oder 
"X50.0000Y50.0000" gemeint ist?

@Heiko L. (drcaveman)

>> Eagle springt dan so bald wie möglich aufs aktuelle Raster. Damit kann
>> man JEDES X-beliebige Pad mit JEDEM Y-beliebeigen Raster absolut gerade
>> anschließen.

>Zeigt aber auf, dass es doch nicht nur rein optisch ist.

???

... schrieb:
> was ist daran nicht zu verstehen?:
>> " Coordinate Format : 3.3\n"\
>> " Coordinate Units  : mm\n"\
>> " Data Mode         : Absolute\n"\
>> " Zero Suppression  : None\n"\
>
> Ein Bauteil, Pad oder Bohrloch bei z.B. X=5mm, Y=5mm
> wird so ausgegeben:
> x005.000,y005.000

Du weißt schon, dass es um die Excellon Ausgabe geht und darum was ein 
einlesendes Programm daraus macht?
Ob die Gerber-Ausgabe dem Standard entspricht kann ich nicht beurteilen.

Falk Brunner schrieb:

>>Zeigt aber auf, dass es doch nicht nur rein optisch ist.
>
> ???

Du hast folgendes geschrieben:

"Nö, denn die interne Auflösung war bei Eagle 4.x bei 0,1 µm, bei Eagle 
6.x ist sie glaub ich noch höher. Und dass die Jungs von Egale die 
Umrechung ohne akkumulierende Rundungsfehler hinbekommen, kann man 
einfach mal glauben ;-)"

Wenn Gnubbel entstehen dann bekommen die das wohl doch nicht ohne 
Rundungsfehler hin.

Georg schrieb:

"Sowieso hat jedes CAD-System sein eigenes inneres Datenformat, die 
Frage
metrisch, inch oder sonstwas stellt sich nur für die Anzeige für die
Menschen vor dem Bildschirm mit ihrer viel geringeren Rechenleistung."

Dem ist also nicht ganz so.

@ Heiko L. (drcaveman)

>Wenn Gnubbel entstehen dann bekommen die das wohl doch nicht ohne
>Rundungsfehler hin.

Welche Gnubbel denn? Poste Ein aussagekräftiges Bild unter Beachtung der 
Bildformate. Sonst reden wir nur aneinander vorbei.

Falk Brunner schrieb:

> Welche Gnubbel denn? Poste Ein aussagekräftiges Bild unter Beachtung der
> Bildformate. Sonst reden wir nur aneinander vorbei.

Das kann man als Bild nicht zeigen. Bei mir hat Eagle immer kleine 
Wire-Häppchen erzeugt um auf das Raster zu kommen (aber gleich mehrere). 
Wenn man dann ein Segment löschen oder verschieben wollte hatte man eine 
Klick-Orgie vor sich.

@ Heiko L. (drcaveman)

>> Welche Gnubbel denn? Poste Ein aussagekräftiges Bild unter Beachtung der
>> Bildformate. Sonst reden wir nur aneinander vorbei.

>Das kann man als Bild nicht zeigen.

Warum nicht? Screenshots sind schon erfunden.

> Bei mir hat Eagle immer kleine
>Wire-Häppchen erzeugt um auf das Raster zu kommen (aber gleich mehrere).
>Wenn man dann ein Segment löschen oder verschieben wollte hatte man eine
>Klick-Orgie vor sich.

Screenshot!

So ein Problem hatte ich mal ganz am Anfang meiner Eagle-Zeit. Aber mit 
4.x war das Problem gelöst (wenn man weiß, wie man es angehen muss).

Falk Brunner schrieb:

> So ein Problem hatte ich mal ganz am Anfang meiner Eagle-Zeit. Aber mit
> 4.x war das Problem gelöst (wenn man weiß, wie man es angehen muss).

Genau- ich weiß jetzt wie ich es angehen muss und kann mich nicht mehr 
daran erinnern was ich früher "falsch" gemacht habe...

Aber du scheinst es ja zu wissen?

Georg schrieb:

> Weil man das beim Einlesen so angibt - genau wie bei der Bohrmaschine
> selbst auch.

Macht Eagle aber nicht.

> sonst kämen selten brauchbare Leiterplatten aus der Fertigung.

Wenn alle sich an die Standards halten würden schon.

@ Heiko L. (drcaveman)

>Genau- ich weiß jetzt wie ich es angehen muss und kann mich nicht mehr
>daran erinnern was ich früher "falsch" gemacht habe...

>Aber du scheinst es ja zu wissen?

Wenn ein Pad nicht exakt auf dem aktuellen Raster liegt, versuchen 
Anfänger dort mit vielen, kurzen Stücken irgendwie ranzukommen. In 
älteren Eagle-Versionen von 4.x war der Fangmodus noch deutlich 
schlechter und es kam zu diesen Knäul am Pad.

Falk Brunner schrieb:

> Wenn ein Pad nicht exakt auf dem aktuellen Raster liegt, versuchen
> Anfänger dort mit vielen, kurzen Stücken irgendwie ranzukommen. In
> älteren Eagle-Versionen von 4.x war der Fangmodus noch deutlich
> schlechter und es kam zu diesen Knäul am Pad.

Ich glaube ich habe es wieder- mein Problem war, dass ich oft 6,25mil 
benutzt hatte (frag nicht warum ;) 100/2=50 50/2=25 25/2=12,5 
12,5/2=6,25...) und da war die interne Auflösung halt nicht hoch genug 
für. Dennoch gab es keine Warnung (auch nicht bei mir), da die interne 
Auflösung ja mit 0,00393701mil (obwohl hier eigentlich schon klar ist, 
dass Eagle intern bestimmt nicht mit mil oder inch arbeitet...) 
angegeben wird.

Da hatte Eagle also immer so 1/2 LSB zu verwurschteln und hat dann wohl 
geknubbelt ;)

Als ich dann herausgefunden habe, dass Eagle intern metrisch arbeitet...

Zoll schrieb:

> Das ist genau 1/10000 mm oder 0.1 µm.

Hilft den 6,25mil (0,05mil > 0,00393701mil) aber auch nicht...

... schrieb:

> Ja, das wird im Header der Excellon-Datei deshalb angegeben.

Macht Eagle aber nicht.

Georg schrieb:

> Hast du überhaupt weitergelesen? Es sind Menschen, die das eingeben,
> keine Adler.

Es sind Menschen, die verstümmelte Formate berichtigen müssen, unnötige 
Fehlerquellen.

Georg schrieb:

> Es hindert dich doch niemand, z.B. "INCH,LZ" auszugeben, damit das klar
> ist, oder du gibst die Koordianten mit Dezimalpunkt aus, dann erhebt
> sich die Frage nach leading oder trailing zeroes erst garnicht. Falk hat
> ja beschrieben wie das geht.

Ja, wäre schön wenn Eagle das direkt richtig macht, findest du nicht?
Man muss übrigens "INCH,TZ" angeben.

> Nach den
> bisherigen Posts ist völlig klar wer hier verstümmelt ist.

Warum denn gleich beleidigen? Bekommst du Geld von Cadsoft?

Georg schrieb:

> Ganz sicher nicht, aber ebenso sicher ärgere ich mich über Leute, die in
> Wirklichkeit garkeine Lösung erfahren wollen und daher jeden Vorschlag
> und jede Erklärung runtermachen, nur um weiter rummeckern zu können.

Wenn du mal richtig gelesen hättest, dann hättest du gesehen, dass ich 
versucht habe "die Lösung" konstruktiv zu verbessern.

Weiterhin habe ich lediglich ausgedrückt, dass Eagle sich nicht an 
Excellon "Regeln" hält und das vielleicht mal ändern könnte.

Das kann dir doch auch egal sein. Als Eagle Benutzer würdest du doch von 
Verbesserungen profitieren, warum also Kritiker beleidigen?

> So kommt man weit in der Technik.

Mit Eagle-Fanatismus?

Georg schrieb:

> Was du nicht verstehen willst, ist dass es zig verschiedene mögliche
> Formate gibt, die sind unterschiedlich, aber nicht richtig oder falsch -

Excellon ist Excellon

http://en.wikipedia.org/wiki/Excellon_format

http://www.excellon.com/manuals/program.htm

Excellon ähnlich ist halt nur ähnlich und sollte dann auch nicht nur 
Excellon heißen.

> es besteht nicht der geringste Grund, warum Eagle seine
> Standardeinstellungen ausgerechnet nach deinen persönlichen
> Vorstellungen richten soll; die sind nicht wertvoller als die von
> irgendjemand anderem, auch wenn du da vermutlich ganz anderer Meinung
> bist.

Das sind nicht meine persönlichen Vorstellungen, sondern die des 
Erfinders der den "Standard" hervorgebracht hat.
Ich lese da bei Excellon nirgends "Or just do whatever you think is 
right".

> Und das angebliche Problem mit führenden Nullen ist keines, das war mal
> in der Mitte des vorigen Jahrhunderts, als es die ersten Bohrmaschinen
> für Leiterplatten überhaupt gab, niemand ausser dir käme auf die Idee
> das zu verwenden.

Mein Gott, man muss ja auch keine führenden Nullen benutzen, dann muss 
aber der Zusatz "TZ" in den Header oder man benutzt Gleitkommazahlen- 
ist das so schwer zu verstehen?

> Und für dich ist es auch nur ein an den Haaren
> herbeigezogener Grund gegen Eagle zu mosern, warum auch immer.

Ich würde das auch bei anderen Programmen kritisieren, ich führe keinen 
Krieg gegen Eagle, ich benutze Eagle sogar.
Wenn eine Software offengelegte Standards missachtet finde ich das 
halt doof.

Warum fühlst du dich eigentlich angegriffen wenn ich eine Software 
kritisiere?

> Die von dir behaupteten Excellon Regeln gibt es garnicht,

Ach so...

> ein Header
> muss überhaupt nicht enthalten sein. Excellon weist nur darauf hin, dass
> man die entsprechenden Kommandos auch an der Konsole eingeben kann, dass
> das aber weniger sicher ist.

...also gibt es doch ein Regelwerk.

Wenn der Header nicht da ist werden Voreinstellungen genommen, z.B. 
"INCH,LZ".

Da Eagle aber standardmäßig "INCH,TZ" ausgibt, gibt es verschiedene 
Möglichkeiten:

- "INCH,TZ" in den Header
- führende Nullen mit ausgeben
- Gleitkommazahlen ausgeben
- Die Ausgabe nicht Excellon sondern Excellon ähnlich nennen

Für mich ist das jetzt EOD.