Bestehende Dateien inkonsistent seit 6.5

Am 28.10.2013 13:12, schrieb Stefan M.:

Hallo,

 

 

 

Wir haben viele Leiterplatten die schon seit Eagle 4.6 funktionieren und an

sich fehlerfrei "waren" (auch in Produktion).

 

Seit Eagle 6.5. haben wir in ca. 20% unserer Platinen "inkonsistenten" die

bei 6.4 noch nicht bemängelt werden.

 

 

 

Nun ist automatisch die Forward-/Back-Annotaion ausgehebelt - mit 6.5  ist

unser Datenbestand hinüber.

 

 

 

Fehlermeldungen sind z.B.: "Bauteil X hat inkonsistente Packages in

Schaltplan und Board"

 

 

 

Wieso werden die Fehler erste jetzt Angezeigt? Sind die angeblichen Fehler

Unnütz, weil das Board soweit funktioniert?

Das Problem ist, das bis 6.4 die Konsistenz der Packages nur in Bezug

auf die Padnamen und die Netzanbindung geprüft wurde.

Leider haben Anwender immer wieder die Konsistenz unterbrochen, also

SCH geschlossen, um im Board mit REPLACE ein anderes Package zu

verwenden. Gibt man jetzt die Stückliste aus dem Schaltplan aus,

so erhält man nicht die Bauteile (Packages) gelistet, die tatsächlich

im BRD verbaut werden müssen.

In der V6 wurde die Prüfung vertieft, so das auch Inkonsistenzen

(Unterschiede) der Packages vom SCH zu BRD erkannt werden.

 

Muss ich jetzt in dutzenden Schaltbildern dutzende Fehlermeldungen

beseitigen?

Nein, es geht nur darum, die Packageinformation (Definition) aus dem

Board in den Schaltplan zu übernehmen.

***

Um das Original zu lesen, und auch zuverlässig angehängte Dateien

bereitstellen zu können, benutzen Sie news.cadsoft.de und einen

funktionierenden News-Reader wie Thunderbird!

***

Mit freundlichen Grüßen / Best regards

Alfred Zaffran

--

______________________________________________________________

Alfred Zaffran              Support

CadSoft Computer GmbH       Hotline:   08635-698930

Pleidolfweg 15              FAX:       08635-698940

84568 Pleiskirchen          eMail: <alf@cadsoft.de>

                             Web:   <www.cadsoft.de>

Registergericht: Amtsgericht Traunstein HRB 5573

Geschäftsführer: Thomas Liratsch

______________________________________________________________

EAGLE V6.4 availabe now!

Stefan M. schrieb:

Hallo,

 

Wir haben viele Leiterplatten die schon seit Eagle 4.6 funktionieren und an

sich fehlerfrei "waren" (auch in Produktion).

 

Seit Eagle 6.5. haben wir in ca. 20% unserer Platinen "inkonsistenten" die

bei 6.4 noch nicht bemängelt werden.

 

Nun ist automatisch die Forward-/Back-Annotaion ausgehebelt - mit 6.5  ist

unser Datenbestand hinüber.

 

Fehlermeldungen sind z.B.: "Bauteil X hat inkonsistente Packages in

Schaltplan und Board"

 

Wieso werden die Fehler erste jetzt Angezeigt? Sind die angeblichen Fehler

Unnütz, weil das Board soweit funktioniert?

 

Muss ich jetzt in dutzenden Schaltbildern dutzende Fehlermeldungen

beseitigen?

 

Alternativ kann ich natürlich auch auf zukünftige Versionen verzichten und

meine Eagle-Welt bei 6.4 einfrieren.

 

Hallo,

bei mir zeigt sich ähnliches.

Es sind wie Du schon erwähnt hast nur bei ca. 20% der Projekte. Man darf

halt, nachdem man die Dateien mit 6.5.0 geöffnet hat, nicht auf

Speichern drücken.

Ich mache das zur Zeit so, dass ich die Problemfiles mit der 6.4.0 öffne

und dort dann die Fehler beseitige. Normalerweise läuft das darauf

hinaus, dass die betroffenen Bauteile in den Bibliotheken korrekt anlegt

und dann mittels replace im Schaltplan auswechselt. Danach kann man dann

mit der 6.5.0 weitermachen.

Gruß Andreas

Hallo,

danke Herr Fecht für die Lösungsidee - das kann doch jetzt aber nicht das

Ende sein, das ich die nächsten Wochen

den Datenbestand der Firma rette - und hoffe das in der nächsten Version

keine neuen "REGELN" erfunden werden, die mir

wieder einen Teil vernichten.

In unserem Eagle Firmen-Ordner liegen:  620 Board Dateien. Davon sind wohl

ca. 20% seit 6.5 defekt.

Irgendwelche Änderungen an der BRD - Datei vorzunehmen widerstrebt mir:

- Genau diese Daten sind beim Leiterplatten-Hersteller eingepflegt.

- Genau diese Daten habe ich als Leiterplatte in den Geräten beim Kunden.

Wenn ich jetzt  an den bestehenden Daten "rumflummle" um neue EAGLE-Regeln

zu erfüllen, sind diese Daten aber nicht die, die bei den

Leiterplattenherstellen eingepflegt sind. Wenn ich aber nichts mache, kann

ich für zukünftige neue Versionen nicht auf den alten Projekten aufbauen.

Herr Zaffran, es kann gut sein, das die Fehler durch das austauschen von

Packages im board geschehen sind - wenn es aber damals keine Fehler

verursacht hat - gehörte es zu der damals  erlaubten Praxis.

Ich würde ja einsehen wenn neue "DRC" Fehler oder irgendwelche Warnungen auf

damaliges Fehlverhalten hinweisen. Das nun seit V6.5  jahrelang

funktionierende Dateien inkonsistent = KAPUTT sind und damit nicht mehr

weitergearbeitet werden kann, halte ich für unzumutbar! Scheinbar werden

jetzt Kriterien geprüft, die es in Vorgänger-Versionen nicht gab. Wie hätte

man das den Vorab wissen sollen? Vor welchen neuen Regeln muss ich in

Zukunft bangen?

Ist ja schön, wenn zukünftige Versionen noch genauer geprüft werden, aber

für den bisherigen Datenbestand sollte es wohl eine Art "Eagle V6.4

kompatibilitätsmodus" geben.

Dass sich nun drei unserer Techniker oder Ingeneure damit Tagelang

beschäftigen kann wohl nicht die Lösung sein. Seit 4.6 machen wir ja jeden

Update-""Spaß"" (und die Verbundenen kosten beim Versionswechel von V4 auf

V5 und V5 auf V6 unserer 3er-Lizenz) mit - nun Spiele ich mit dem Gedanken

das ganze bei 6.4 einzufrieren oder abzusplitten.

Herr Zaffran, wie sollen wir jetzt damit umgehen? Herr Oelschlägel hatte

ihnen ja schon ein Projekt zur Reparatur überlassen - vielen Dank dafür.

Den Restlichen Projekte nun auf CD per Post?

Gruß Stefan

"Andreas Fecht" <forum@aftec.de> schrieb im Newsbeitrag

news:l4nq6o$ip1$1@cheetah.cadsoft.de...

Stefan M. schrieb:

Hallo,

 

Wir haben viele Leiterplatten die schon seit Eagle 4.6 funktionieren und

an

sich fehlerfrei "waren" (auch in Produktion).

 

Seit Eagle 6.5. haben wir in ca. 20% unserer Platinen "inkonsistenten"

die

bei 6.4 noch nicht bemängelt werden.

 

Nun ist automatisch die Forward-/Back-Annotaion ausgehebelt - mit 6.5

ist

unser Datenbestand hinüber.

 

Fehlermeldungen sind z.B.: "Bauteil X hat inkonsistente Packages in

Schaltplan und Board"

 

Wieso werden die Fehler erste jetzt Angezeigt? Sind die angeblichen

Fehler

Unnütz, weil das Board soweit funktioniert?

 

Muss ich jetzt in dutzenden Schaltbildern dutzende Fehlermeldungen

beseitigen?

 

Alternativ kann ich natürlich auch auf zukünftige Versionen verzichten

und

meine Eagle-Welt bei 6.4 einfrieren.

 

 

Hallo,

 

bei mir zeigt sich ähnliches.

Es sind wie Du schon erwähnt hast nur bei ca. 20% der Projekte. Man darf

halt, nachdem man die Dateien mit 6.5.0 geöffnet hat, nicht auf Speichern

drücken.

Ich mache das zur Zeit so, dass ich die Problemfiles mit der 6.4.0 öffne

und dort dann die Fehler beseitige. Normalerweise läuft das darauf hinaus,

dass die betroffenen Bauteile in den Bibliotheken korrekt anlegt und dann

mittels replace im Schaltplan auswechselt. Danach kann man dann mit der

6.5.0 weitermachen.

 

Gruß Andreas

 

 

 

 

 

 

 

 

 

Hallo Stefan,

Sorry, ich denke, dass dies ein, leider oft vorkommender, Anwenderfehler ist,

welcher sich im Laufe der langen Zeit weitergewalgt hat.

Bevor ich in einer neuen Software-Version irgend einen Handstrich

mache, überprüfe ich die Design Rules und speichere die Dateien

mit "speichern unter" in einem neuen Ordner.

Damit lege ich ich die Grundlagen für die nächsten Versionen.

Es entsteht damit eine Art "Lebensgeschichte".

Auch die dazugehörigen Software-Versionen sollten archiviert werden.

Datenpflege kann man leider, bzw. sollte man nicht auf den PCB-Hersteller,

oder gar Software-Hersteller welzen.

Es gibt ja auch den Button "Billigen".

Wenn es also keine großen Probleme, zB. elektrisch macht,

sollte "billigen" eine Hilfe und Abschwächung des Problems sein.

Ich würde es als Fortschritt betrachten, wenn mehr Prüfungsmöglichkeiten

zu meiner Unterstützung vorhanden sind.

Einen echten Rückschritt finde ich es, wenn man "Einfriert", so wie du es mit 6.4.0

angedacht hast.

Solche oft fein versteckte Anwendungsfehler muss ich auch immer wieder beratend

bei Kunden aufzeigen, wie sie zB. bei Betriebsystem, oder Anwenderprogramme auftauchen.

Grüße

Gerald

Hallo Gerald,

uns war es wichtig, zu wissen welche Datan beim Leiterplattenhersteller

vorhanden sind.

Pflegen tun wir die selbst. Aber der Hersteller hat ja die teuren "Filme"

für Neubestellungen.

Und da möchten wir sicher die selben Daten haben - daher möchte ich bereits

bestehende Platinen nicht ändern -

später kopieren wie die dann für neuere Revisionen der Platine.

Es gibt ja auch den Button "Billigen".

Der BilligenButton funktioniert bei Konsistenzfehlern leider nicht (nich

anwählbar) - sonst hätte ich gar kein Problem damit.

Gerade bei neuen Regeln wäre dieser "Billigen" von Vorteil.

Gruß Stefan

"Gerald Schwarz" <gerald.schwarz@sg-electronics.at> schrieb im Newsbeitrag

news:1362733497.211383048713611.JavaMail.jive@flmspu-csapp-02.premierfarnell.com...

Hallo Stefan,

 

Sorry, ich denke, dass dies ein, leider oft vorkommender, Anwenderfehler

ist,

welcher sich im Laufe der langen Zeit weitergewalgt hat.

 

Bevor ich in einer neuen Software-Version irgend einen Handstrich

mache, überprüfe ich die Design Rules und speichere die Dateien

mit "speichern unter" in einem neuen Ordner.

Damit lege ich ich die Grundlagen für die nächsten Versionen.

Es entsteht damit eine Art "Lebensgeschichte".

Auch die dazugehörigen Software-Versionen sollten archiviert werden.

 

Datenpflege kann man leider, bzw. sollte man nicht auf den

PCB-Hersteller,

oder gar Software-Hersteller welzen.

Es gibt ja auch den Button "Billigen".

Wenn es also keine großen Probleme, zB. elektrisch macht,

sollte "billigen" eine Hilfe und Abschwächung des Problems sein.

 

Ich würde es als Fortschritt betrachten, wenn mehr Prüfungsmöglichkeiten

zu meiner Unterstützung vorhanden sind.

Einen echten Rückschritt finde ich es, wenn man "Einfriert", so wie du

es mit 6.4.0

angedacht hast.

 

Solche oft fein versteckte Anwendungsfehler muss ich auch immer wieder

beratend

bei Kunden aufzeigen, wie sie zB. bei Betriebsystem, oder

Anwenderprogramme auftauchen.

 

Grüße

Gerald

 

--

Um alle Bilder und Anhänge in diesem Beitrag zu sehen, besuchen Sie:

http://www.element14.com/community/message/93048#93048

"A. Zaffran" <alf@cadsoft.de> schrieb im Newsbeitrag

news:l4nnlt$uma$1@cheetah.cadsoft.de...

Das Problem ist, das bis 6.4 die Konsistenz der Packages nur in Bezug

auf die Padnamen und die Netzanbindung geprüft wurde.

Leider haben Anwender immer wieder die Konsistenz unterbrochen, also

SCH geschlossen, um im Board mit REPLACE ein anderes Package zu

verwenden. Gibt man jetzt die Stückliste aus dem Schaltplan aus,

so erhält man nicht die Bauteile (Packages) gelistet, die tatsächlich

im BRD verbaut werden müssen.

In der V6 wurde die Prüfung vertieft, so das auch Inkonsistenzen

(Unterschiede) der Packages vom SCH zu BRD erkannt werden.

Ja, seit V6 gibt es diese Meldungen vermehrt. Ich habe mehrere alte Designs

"geerbt", die ich umbauen musste, da Bauteile abgekündigt wurden. Da ich

nicht mal die Original Libs bekommen hatte war die ganze Angelegenheit sehr

mühsam. Da hat manchmal nur ein Hack im BRD geholfen. Teilweise waren das

Designs, die noch mit V3.x erstellt worden sind.

Das war auch der Grund, dass ich bis jetzt bei V5.12 geblieben bin, da ich

dort von Fehlermeldungen weitgehend verschont worden bin. Mir graut ehrlich

gesagt davor auf V6.5 umzusteigen. Das werde ich aber in nächster Zukunft

tun müssen, da ich jetzt einzelne Designs mit V6.x bekomme. Ich möchte nicht

mit einer V5 und V6 parallel arbeiten.

Was ich mir von Cadsoft dringend wünsche ist die Möglichkeit die Fehler zu

billigen (auf eigenes Risiko natürlich)! Meine Änderungen haben bis jetzt

immer einwandfrei funktionierende PCBs herausgebracht.

Und weiter wünsche ich mir, dass Cadsoft einmal beschreibt was da alles auf

Konsistenz geprüft wird.

Freundliche Grüsse,

Thomas Riedger

THR-ENGINEERING

Am 29.10.2013 19:23, schrieb Thomas Riedger:

"A. Zaffran" <alf@cadsoft.de> schrieb im Newsbeitrag

news:l4nnlt$uma$1@cheetah.cadsoft.de...

 

Das Problem ist, das bis 6.4 die Konsistenz der Packages nur in Bezug

auf die Padnamen und die Netzanbindung geprüft wurde.

Leider haben Anwender immer wieder die Konsistenz unterbrochen, also

SCH geschlossen, um im Board mit REPLACE ein anderes Package zu

verwenden. Gibt man jetzt die Stückliste aus dem Schaltplan aus,

so erhält man nicht die Bauteile (Packages) gelistet, die tatsächlich

im BRD verbaut werden müssen.

In der V6 wurde die Prüfung vertieft, so das auch Inkonsistenzen

(Unterschiede) der Packages vom SCH zu BRD erkannt werden.

 

Ja, seit V6 gibt es diese Meldungen vermehrt. Ich habe mehrere alte Designs

"geerbt", die ich umbauen musste, da Bauteile abgekündigt wurden. Da ich

nicht mal die Original Libs bekommen hatte war die ganze Angelegenheit sehr

Das ist kein Problem, in V5

RUN exp-project-lbr.ulp

damit kann man die im SCH benutzen Bauteile (Bibliotheken) wieder

herstellen.

mühsam. Da hat manchmal nur ein Hack im BRD geholfen. Teilweise waren das

Designs, die noch mit V3.x erstellt worden sind.

 

Das war auch der Grund, dass ich bis jetzt bei V5.12 geblieben bin, da ich

dort von Fehlermeldungen weitgehend verschont worden bin. Mir graut ehrlich

gesagt davor auf V6.5 umzusteigen. Das werde ich aber in nächster Zukunft

tun müssen, da ich jetzt einzelne Designs mit V6.x bekomme. Ich möchte nicht

mit einer V5 und V6 parallel arbeiten.

 

Was ich mir von Cadsoft dringend wünsche ist die Möglichkeit die Fehler zu

billigen (auf eigenes Risiko natürlich)! Meine Änderungen haben bis jetzt

immer einwandfrei funktionierende PCBs herausgebracht.

Hier geht es nicht im das billigen von Design-Regel-Verletzungen,

sondern um die Konsistenz zwischen SCH und BRD. Also um die

Gleichwertigkeit der beiden Dateien.

Das BRD soll ja auch die elektrischen und im begrenzten Masse die

mechanischen Eigenschaften das Schaltplan (Packages) wiedergeben, und

dazu gehört auch, das beide die gleichen Packages benutzen, da man

sonst bei EXPORT Partlist im Schaltplan andere Packageangaben erhält,

als bei EXPORT Partlist im Board.

Man stelle sich vor, man gibt die Stückliste aus dem SCH aus, und

der Bestücker wundert sich dann, wie er das DIL14 Gehäuse an der

Position bestücken soll, an der im BRD ein SO14 platziert ist.

Oder im SCH ist eine andere Variante des SO14 benutzt als im Board,

es gibt ja bei SO14 nur 3 (schmal, mittel breit). :-\

 

Und weiter wünsche ich mir, dass Cadsoft einmal beschreibt was da alles auf

Konsistenz geprüft wird.

1. Die Bauteilnamen, stimmen die benutzen Bauteilenamen überein,

    wird die zweite Stufe geprüft.

2. Die gleichen Packages, ab V6.

3. Die Values, nur wenn der Value des Bauteil im SCH und BRD auf das

    Zeichen exakt übereinstimmt, geht es zur 4. Stufe.

4. Die Netzliste. Also die Netz/Signalnamen die an dem PIN/PAD

    angeschlossen ist.

Bei der ersten unwahren Bedingung, wird abgebrochen, da es sonst

zu Folgefehlern kommt. Man muß also zuerst diesen Fehler beseitigen,

damit die Konsistenzprüfung den nächsten Schritt machen kann.

In älteren Eagle-Versionen konnte man deshalb die Konsistenz

austricksen, indem man den SCH geschlossen, und mit REPLACE im

BRD das Package getauscht hat (was leider auch vor kam), da ja

nur der Name, der Value und die Netzliste auf Übereinstimmung

geprüft wurden.

***

Um das Original zu lesen, und auch zuverlässig angehängte Dateien

bereitstellen zu können, benutzen Sie news.cadsoft.de und einen

funktionierenden News-Reader wie Thunderbird!

***

Mit freundlichen Grüßen / Best regards

Alfred Zaffran

--

______________________________________________________________

Alfred Zaffran              Support

CadSoft Computer GmbH       Hotline:   08635-698930

Pleidolfweg 15              FAX:       08635-698940

84568 Pleiskirchen          eMail: <alf@cadsoft.de>

                             Web:   <www.cadsoft.de>

Registergericht: Amtsgericht Traunstein HRB 5573

Geschäftsführer: Thomas Liratsch

______________________________________________________________

EAGLE V6.4 availabe now!

A. Zaffran schrieb:

 

In älteren Eagle-Versionen konnte man deshalb die Konsistenz

austricksen, indem man den SCH geschlossen, und mit REPLACE im

BRD das Package getauscht hat (was leider auch vor kam), da ja

nur der Name, der Value und die Netzliste auf Übereinstimmung

geprüft wurden.

 

Also ich bin mir sehr sicher, dass ich das seit der 4er nicht mehr

gemacht habe. Trotzdem hatte ich diese Probleme mit der Inkonsistenz.

Was ich jedoch gemacht habe: ich habe irgendwann mal meine Bibliotheken

entrümpelt. Wenn es das geänderte Bauteil jetzt in der alten Form in den

Bibliotheken nicht mehr gibt, wurde beim Update dann ein @-Zeichen

eingefügt. Seit der 6.5er führt das jedoch oft zu genau den benannten

Inkonsistenz-Problemen.

Ich finde das jedoch gar nicht so schlecht, das Überarbeiten der alten

Projekte hat einiges an vorhandenen bisher nicht bemerkten Fehlern

rausgeworfen. Mittlerweile habe ich fast alles überarbeitet.

Ähnliches ist beim Übergang von V3 nach V4 passiert. Viele haben sich

damals aufgeregt, dass replace nicht mehr geht. Es hat jedoch dazu

geführt, dass man endlich mal seine Bibliotheken aufräumt.

Gruß Andreas

Am 04.11.2013 10:53, schrieb Andreas Fecht:

A. Zaffran schrieb:

 

In älteren Eagle-Versionen konnte man deshalb die Konsistenz

austricksen, indem man den SCH geschlossen, und mit REPLACE im

BRD das Package getauscht hat (was leider auch vor kam), da ja

nur der Name, der Value und die Netzliste auf Übereinstimmung

geprüft wurden.

 

 

Also ich bin mir sehr sicher, dass ich das seit der 4er nicht mehr

gemacht habe. Trotzdem hatte ich diese Probleme mit der Inkonsistenz.

 

Was ich jedoch gemacht habe: ich habe irgendwann mal meine Bibliotheken

entrümpelt. Wenn es das geänderte Bauteil jetzt in der alten Form in den

Bibliotheken nicht mehr gibt, wurde beim Update dann ein @-Zeichen

eingefügt. Seit der 6.5er führt das jedoch oft zu genau den benannten

Inkonsistenz-Problemen.

Haben Sie da eine Vorgehensweise (Beispiel), mit der man das

zuverlässig reproduzieren kann?

***

Um das Original zu lesen, und auch zuverlässig angehängte Dateien

bereitstellen zu können, benutzen Sie news.cadsoft.de und einen

funktionierenden News-Reader wie Thunderbird!

***

Mit freundlichen Grüßen / Best regards

Alfred Zaffran

--

______________________________________________________________

Alfred Zaffran              Support

CadSoft Computer GmbH       Hotline:   08635-698930

Pleidolfweg 15              FAX:       08635-698940

84568 Pleiskirchen          eMail: <alf@cadsoft.de>

                             Web:   <www.cadsoft.de>

Registergericht: Amtsgericht Traunstein HRB 5573

Geschäftsführer: Thomas Liratsch

______________________________________________________________

EAGLE V6.4 availabe now!

A. Zaffran schrieb:

 

Haben Sie da eine Vorgehensweise (Beispiel), mit der man das

zuverlässig reproduzieren kann?

Wohl nicht mehr, die alten Bibliotheken hab' ich nicht mehr.

Wenn Sie wollen, kann Ihnen mal so ein Problem-Datei-Pärchen zusenden.

Gruß Andreas