Actions
Forum Thread Details
  • Replies 17 replies
  • Subscribers 178 subscribers
  • Views 1408 views
  • Users 0 members are here
Related

Polygone für Print freirechnen

autodeskguest

Polygone werden bekanntlich nur als Umriss gespeichert;  um sie richtig

zu sehen,  muss man sie erst mit RATSNEST freirechnen lassen.

 

Das setzt aber dann das "Board verändert"-Flag,  so dass in der Folge im

Zeichnungsrahmen das Speicherdatum >LAST_DATE_TIME als "nicht

gespeichert" angezeigt wird.  (Eagle 6.3.0 Pro)

 

Wenn ich nun von einem fertigen und somit "eingefrorenen" Board die Doku

(PDFs) erzeugen will,  werden entweder die Polygone oder das Datum nicht

richtig angezeigt!  Speichern gilt nicht,  denn ich will die Boarddatei

ja nicht mehr ändern und dann wäre das Datum auch falsch.

 

Entweder sollte RATSNEST das Geändert-Flag nicht setzen (ändert ja auch

nichts,  oder?),  oder PRINT sollte eine Option "Polygone freirechnen"

bekommen.

 

 

--

Grüße,  Hans Lederer

 

 

Parents

  • Uwe Bonnes schrieb:

     

    Eagle bemerkt doch dass das Board geaendert wurde, indem >last_date_time als

    "nicht gespreichert" dargestellt wird.  Beim Schreiben der Datei koennte man

    das Datum beim Schreiben in der XML Struktur versenken und  fuer

    last_date_time  dieses Datum verwenden, solange das "nicht gespeichert" Flag

    nicht gesetzt ist.

     

    Denke die von mir mehrmals geschilderte Situation doch einmal bis zu

    Ende durch. Auch ein in der Datei separat gespeichertes Datum würde das

    Problem nicht lösen, da ja tatsächlich Änderungen am Board vorgenommen

    wurden - nur eben keine, die für die Leiterplatte selbst relevant wären.

     

    Ein Zeiteintrag in der Datei würde nur dann einen Vorteil bringen, wenn

    das Dateidatum einzig aufgrund eines Kopier- oder Übermittlungsvorgangs

    neu gesetzt wurde. (Immerhin - deswegen bin ich ja auch durchaus dafür.)

     

    Tilmann

     

     

  • in reply to autodeskguest

    Tilmann Reh schrieb:

     

    Eagle bemerkt doch dass das Board geaendert wurde, indem >last_date_time als

    "nicht gespreichert" dargestellt wird.  Beim Schreiben der Datei koennte man

    das Datum beim Schreiben in der XML Struktur versenken und  fuer

    last_date_time  dieses Datum verwenden, solange das "nicht gespeichert" Flag

    nicht gesetzt ist.

     

    Denke die von mir mehrmals geschilderte Situation doch einmal bis zu

    Ende durch. Auch ein in der Datei separat gespeichertes Datum würde das

    Problem nicht lösen, da ja tatsächlich Änderungen am Board vorgenommen

    wurden - nur eben keine, die für die Leiterplatte selbst relevant wären.

     

    so sehe ich das auch, und so praktiziere ich das auch.

     

    Natürlich besteht das Risiko, dass man einmal vergisst, das Datum

    anzupassen. Hatte ich auch einmal. Das ist ärgerlich, fällt aber bei

    einer funktionierenden Qualitätskontrolle nicht erst auf, wenn man

    1000 Stück produziert und ausgeliefert hat.

     

    Ich würde diesen Text trotzdem niemals image von einer Automatik setzen

    lassen.

     

    Ein Zeiteintrag in der Datei würde nur dann einen Vorteil bringen, wenn

    das Dateidatum einzig aufgrund eines Kopier- oder Übermittlungsvorgangs

    neu gesetzt wurde. (Immerhin - deswegen bin ich ja auch durchaus dafür.)

     

    Genau. Im Schaltplan oder auch außerhalb des Kupfers sehe ich durchaus

    einen gewissen Nutzen für so einen Wert. Wenn auch nur eingeschränkt.

     

    Servus

     

    Oliver

    --

    Oliver Betz, Munich (oliverbetz.de)

     

Reply
  • in reply to autodeskguest

    Tilmann Reh schrieb:

     

    Eagle bemerkt doch dass das Board geaendert wurde, indem >last_date_time als

    "nicht gespreichert" dargestellt wird.  Beim Schreiben der Datei koennte man

    das Datum beim Schreiben in der XML Struktur versenken und  fuer

    last_date_time  dieses Datum verwenden, solange das "nicht gespeichert" Flag

    nicht gesetzt ist.

     

    Denke die von mir mehrmals geschilderte Situation doch einmal bis zu

    Ende durch. Auch ein in der Datei separat gespeichertes Datum würde das

    Problem nicht lösen, da ja tatsächlich Änderungen am Board vorgenommen

    wurden - nur eben keine, die für die Leiterplatte selbst relevant wären.

     

    so sehe ich das auch, und so praktiziere ich das auch.

     

    Natürlich besteht das Risiko, dass man einmal vergisst, das Datum

    anzupassen. Hatte ich auch einmal. Das ist ärgerlich, fällt aber bei

    einer funktionierenden Qualitätskontrolle nicht erst auf, wenn man

    1000 Stück produziert und ausgeliefert hat.

     

    Ich würde diesen Text trotzdem niemals image von einer Automatik setzen

    lassen.

     

    Ein Zeiteintrag in der Datei würde nur dann einen Vorteil bringen, wenn

    das Dateidatum einzig aufgrund eines Kopier- oder Übermittlungsvorgangs

    neu gesetzt wurde. (Immerhin - deswegen bin ich ja auch durchaus dafür.)

     

    Genau. Im Schaltplan oder auch außerhalb des Kupfers sehe ich durchaus

    einen gewissen Nutzen für so einen Wert. Wenn auch nur eingeschränkt.

     

    Servus

     

    Oliver

    --

    Oliver Betz, Munich (oliverbetz.de)

     

Children
No Data