Ich frage mich seit einigen Wochen, wie weit ODB++ schon das alte Gerber
Format ersetzen kann.
Mit Google habe ich dazu nicht wirklich viel KONKRETES gefunden.
Seit einigen Monaten gibt es ja den FOSS Viewer
https://github.com/aitjcize/QCamber und nach Aussage des Autors soll das
Format in China ja schon recht üblich sein, und es soll auch eine freie
Spezifikation geben.
Wird das Format wirklich schon von Leiterplattenherstellern akzeptiert?
Ohne Mehrkosten, auch hier in Deutschland?
Hallo Stefan Salewski.
Salewski, Stefan schrieb:> Ich frage mich seit einigen Wochen, wie weit ODB++ schon das alte Gerber> Format ersetzen kann.
OBD++ Daten sind für die Weiterverarbeitung im allgemeinen sehr sauber.
Mist gebaut werden kann aber damit auch.
Bei OBD++ besteht aber das Problem, das es proprietär ist, was ein
großes Hindernis bei der Verbreitung ist. Es gibt nur wenige Programme,
die OBD++ erzeugen können. Ausserdem bedeutet es das strategische
Problem, das Du Dich bei proprietären Datenformaten stärker als nötig
von den Programmanbietern abhängig machst.
Und wenn Du irgendwo eine Maschine hast, die nur mit Gerber arbeiten
kann, musst Du trotzdem extra dafür aus OBD++ Gerber erzeugen.
> Mit Google habe ich dazu nicht wirklich viel KONKRETES gefunden.
OBD++ ist eben sehr selten im Einsatz. Schlecht ist es wohl nicht. Aber
ob die Qualität der Daten expliziet auf das Format oder die erzeugende
Software zurückzuführen ist, kann ich nicht beurteilen. In letzterem
Falle hätte es keinen Vorteil gegenüber Gerber.
Ausserdem ist es halt nicht offen. Daher kann es halt nicht so gut
diskutiert werden....es weiss halt auch kaum einer näheres dazu. Und die
involvierten wollen nur Werbung machen.
> Seit einigen Monaten gibt es ja den FOSS Viewer> https://github.com/aitjcize/QCamber und nach Aussage des Autors soll das> Format in China ja schon recht üblich sein, und es soll auch eine freie> Spezifikation geben.>
Wie frei? Frei im Sinne von Freibier oder im Sinne von freier Rede? In
dem Punkte wäre ich misstrauisch.
Hast du mal einen Link auf die Spezifikation?
Selbst wenn der Viewer selber frei und quelloffen ist, kann er immer
noch auf geschlossenen Bibliotheken oder Binaries beruhen. d.H. es wäre
nur eine Scheinfreiheit. Und die Spezifikation des Datenformates
rückwärts aus den Sourcecodes zu deren Verarbeitung zu gewinnen, ist
auch nicht wirklich offen. Und ich als Programmierlaie kann nicht
Beurteilen, ob dieser Fall vorliegt.
> Wird das Format wirklich schon von Leiterplattenherstellern akzeptiert?> Ohne Mehrkosten, auch hier in Deutschland?
Ja. aber teilweise mit Zähneknirschen. Es ist zu selten, und selbst wenn
das Format besser sein sollte, aber Du bekommst nur alle Jubeljahre
damit zu tun, bist Du ungeübt und dadurch fehleranfälliger. Darum wird
Gerber bevorzugt. Wenn ein Leiterplattenhersteller einen ausreichend
großen Kundenkreis hat, der ODB++ verwendet, kann das aber anders
aussehen.
Nach meiner Ansicht kann OBD++ grundsätzlich nicht so viele Vorteile
gegenüber Gerber bringen, um die strategischen Nachteile, die sich durch
die Verwendung proprietärer Datenformate und Software ergeben,
auszugleichen.
Und Gerber wird ja auch weiterentwickelt.
Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.dl0dg.de
Bernd Wiebus schrieb:> Hallo Stefan Salewski.>>> Seit einigen Monaten gibt es ja den FOSS Viewer>> https://github.com/aitjcize/QCamber und nach Aussage des Autors soll das>> Format in China ja schon recht üblich sein, und es soll auch eine freie>> Spezifikation geben.>>>> Wie frei? Frei im Sinne von Freibier oder im Sinne von freier Rede? In> dem Punkte wäre ich misstrauisch.> Hast du mal einen Link auf die Spezifikation?
Hallo Bernd,
ja ich hatte von ODB++ vor vielen Jahren mal gehört -- damals hatte es
hier in Deutschland eigentlich kein Leiterplattenhersteller unterstützt,
und ich hatte auch den Eindruck, dass es ein proprietäres Format sei.
Hat mich dann nicht weiter interessiert.
Dann schieb mir der QCamber Entwickler auf der gEDA Mailingliste:
On Wed, 2013-11-27 at 01:19 +0800, Wei-Ning Huang wrote:
Hi Stefan,
>> Yes, it is written in C++ and with QGraphicsView. I did some hack to> workaround QGraphcisView's bugs and it's low efficiency...> You can look at this>
thread<http://www.odb-sa.com/community/topic/how-can-i-get-hold-of-the-odb-format-specification/>on> how to get ODB++ specifications, and for the IPC2851 format you can> get> the specification on their> website<http://www.ipc-2581.com/index.php/ipc-2581-standard-files>;.> I think both format are well supported in China fabs. ODB++ is an old> format so think most of the fab support it.>> Best,> Wei-Ning
Von anderer Seite kam dazu leider nichts mehr. Ich hatte tatsächlich den
Eindruck, dass ODB++ zu einem freien, offenen Format werden soll,
ähnlich wie etwa PDF (war von Abobe ja ursprünglich nicht als frei
gedacht.) Aber wichtig ist natürlich, dass es von
Leiterplattenherstellern auch akzeptiert wird. Ich perönlich mache mit
Leiterplatten momentan zwar nichts, und gEDA/PCB kann ja auch nur Gerber
Format erzeugen (KiCAD wohl auch nur), aber hin und wieder bastel ich
doch etwas an Software, etwa dem Rubberband-Router, hast Du vielleicht
auf meiner Seite gesehen... Von dem Gerber-Format habe ich keinerlei
Ahnung, und meine Begeisterung so ein altes, etwas überholtes Format zu
lernen ist nicht so groß.
Gruß
Stefan
Salewski, Stefan schrieb:> Ich frage mich seit einigen Wochen, wie weit ODB++ schon das alte Gerber> Format ersetzen kann.
Können ist nicht die Frage, es sollte schon grosse Vorteile bieten, wenn
es ein so etabliertes Format wie Gerber ablösen soll. Ein paar Vorteile
bietet es im semantischen Bereich, so ist bei ODB++ klar, was ein Pad
ist und was eine Leiterbahn, in Gerber ist das nicht ohne weiteres zu
unterscheiden.
Andere Probleme bleiben aber gleich: der CAMist beim LP-Hersteller muss
sich immer noch zusammensuchen, welche Lage was ist, denn die
Bezeichnungen sind recht beliebig, und im Gegensatz zu Gerber kann man
sie nicht mal beim Postprozess frei vergeben*. Die Lagenbezeichnungen
nach Vorgaben des LP-Herstellers zu vergeben erfordert erhebliche
Klimmzüge oder ist garnicht möglich*. Auch mehrere Lagen etwa zum
Lötstopplack zusammenzufassen geht i.d.R. auch nicht.
Das Format an sich ist ein Unix-Albtraum, für jede Kleinigkeit wird eine
eigene Datei in einem speziellen Verzeichnis angelegt, zerstört man
diese Struktur, z.B. beim Kopieren, geht jeder sinnvolle Zusammenhang
verloren. Wir hatten schon Leiterplatten, bei denen ODB++ aus mehreren
hundert Dateien bestand. Handhabbar ist das nur durch die
Zusammenfassung mit tar zu einem Archiv - das ist das was man unter
ODB++-Datei versteht.
* heisst, das kann bei jedem Postprozessor wieder anders sein, was nun
auch kein Vorteil ist.
Gruss Reinhard
Salewski, Stefan schrieb:> Ich frage mich seit einigen Wochen, wie weit ODB++ schon das alte Gerber> Format ersetzen kann.
Wir setzten unter Altium AD ODB++ ein, es gibt keine Probleme mit
unserem Hersteller, im Gegenteil er bevorzugt ODB++, Gerber kostet
zusätzlich.
rgds
Hallo Stefan Salewski und Icke.
Salewski, Stefan schrieb:> http://www.odb-sa.com/community/topic/how-can-i-get-hold-of-the-odb-format-specification/
Da musst du Dich anmelden. Und das geht nur als Firma oder Organisation,
die mit Leiterplattenfertigung zu tun hat. Nicht als Privatperson....
Ich hatte darüber vor zwei(?) Jahren sogar eine E-Mail Diskussion mit
dem Bearbeiter.
> http://www.ipc-2581.com/index.php/ipc-2581-standard-files
Die IPC-2581 hat mit dem Ansatz der IPC zu tun, ein XML basiertes
Verfahren für den Datenaustausch aufzubauen. Mit OBD++ hat das wenig zu
tun.
Icke schrieb:> Seit 2012 sind die Spezifikationen nicht mehr nur mit NDA erhältlich.> Entweder über die OBD-SA (nach Anmeldung) oder direkt hier:> http://de.scribd.com/doc/124269949/ODB-Format-Description-v7
Auch da muss man sich anmelden. Man braucht einen "scribd" Account.
Das Anlegen hat in meinem Falle aber aus irgendeinem Grunde nicht
funktioniert....es werden immer Sonderzeichen im Passwort bemängelt,
obwohl ich keine verwendet habe????
Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.dl0dg.de
Bernd Wiebus schrieb:> Salewski, Stefan schrieb:>>>> http://www.odb-sa.com/community/topic/how-can-i-get-hold-of-the-odb-format-specification/>> Da musst du Dich anmelden. Und das geht nur als Firma oder Organisation,> die mit Leiterplattenfertigung zu tun hat. Nicht als Privatperson....> Ich hatte darüber vor zwei(?) Jahren sogar eine E-Mail Diskussion mit> dem Bearbeiter.
Das klingt wirklich nicht gut, ebenso die Bemerkung von Reinhard Kern,
dass man mit dem Format sehr viele Dateien in einem Verzeichnisbaum hat.
Mit solchen Anmeldungen, auch als Firma oder Organisation, ist ja oft
etwas wie ein NDA verbunden, und dann hat man sich schnell alle
Möglichkeiten frei (Export)-Software zu schreiben verbaut. (Atmel hatte
das vor Jahren ja auch mal mit seiner AVR USB firmware gemacht, deshalb
hatte ich dann mit einiger Mühe an Hand des Datenblattes einen eigenen
Treiber geschieben. Ja, war kurz bevor LUFA bekannt wurde...)
Also werde ich ODB++ schnell wieder vergessen, danke für die
Informationen.
Gruß
Stefan
Ich versuchte vor einigen Jahren mal, das bei meinem damaligen AG im
EMS-Bereich soweit zu etablieren, dass man wenigstens was mit dem Format
anfangen kann, muss aber eingestehen, dass der Versuch damals
gescheitert ist. Weder EMS noch LP-Hersteller wollen von ihren
vorhandenen Strukturen gern abweichen. Es heisst immernoch: Gerber für
die LP und Bestückungsplan als durchsuchbares PDF, P&P-Daten in CSV.
Dazu kommt, dass auch die aktuell üblichen CAM-Programme ODB++ nicht
unbedingt mit viel Komfort auswerten können. So ist zwar beispielsweise
der Bestückungsplan in CAMCAD häufig gut zu lesen, weil im ODB-Format
die Bezeichner gleich sinnvoll angeordnet und dimensioniert werden, aber
bei den meisten Programmen fehlt schlicht die Möglichkeit, nach
bestimmten BE zu suchen, geschweige denn das berühmte durchsuchbare PDF
zu erzeugen. So bleibt dem MA im Prüffeld dann nur über, eine CAM-Lizenz
zu blockieren, die bares Geld kostet.
Insofern ist ODB++ zwar ein Schritt in die richtige Richtung, kann aber
auch aufgrund der Ausgestaltung der Tools nicht den Komfort liefern, den
man bspw. über sinnvoll definierte Output-Container mit Altium erreicht.
Ein durchdachtes und vor allem hinreichend standardisiertes Format der
Datenübergabe von der Entwicklung an LP-Hersteller und EMS lässt damit
weiter auf sich warten.
Es bleibt nur, mit dem Hersteller genau abzusprechen, welche Daten er
verarbeiten kann. Hier sehe ich das Problem weniger bei der
LP-Herstellung sondern vielmehr an der Übergabe von Daten an den EMS,
denn dort ist der Umfang deutlich größer und damit auch das Potential
für Missverständnisse und falsche Angaben.
