Wie kann ich in einem Device, z.B. relay.lbr, package S2XXEX, zwei pads
im finalen Layout ändern, ohne das Package neu editieren zu müssen.
Zwei der Pads sollen einen breiteren Ring bekommen. Ich dachte daran,
einfach ein Pad darüber zu legen. Wie ändere ich Bohrung und Durchmesser
eines Pads?
--
Christoph
Am 19.01.2011 13:19, schrieb Christoph Kukulies:
Wie kann ich in einem Device, z.B. relay.lbr, package S2XXEX, zwei pads
im finalen Layout ändern, ohne das Package neu editieren zu müssen.
Zwei der Pads sollen einen breiteren Ring bekommen. Ich dachte daran,
einfach ein Pad darüber zu legen. Wie ändere ich Bohrung und Durchmesser
eines Pads?
Nur in der LBR, oder global den Restring (DRC- Restring), oder in
diesem Fall, einfach zwei ARC mit 180° und entsprechender Breite
und Signalnamen um die Pads legen. 
Ist das Package falsch definiert?
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: Dipl.-Ing. Klaus Schmidinger, Bodo Badnowitz
_____________________________________________________________
Am 19.01.2011 14:59, schrieb A. Zaffran:
Am 19.01.2011 13:19, schrieb Christoph Kukulies:
>> Wie kann ich in einem Device, z.B. relay.lbr, package S2XXEX, zwei pads
>> im finalen Layout ändern, ohne das Package neu editieren zu müssen.
>> Zwei der Pads sollen einen breiteren Ring bekommen. Ich dachte daran,
>> einfach ein Pad darüber zu legen. Wie ändere ich Bohrung und Durchmesser
>> eines Pads?
Nur in der LBR, oder global den Restring (DRC- Restring), oder in
diesem Fall, einfach zwei ARC mit 180° und entsprechender Breite
und Signalnamen um die Pads legen.
Oder einfach mit einem Stückchen fetter Leiterbahn anfahren.
Bei beiden Methoden ggf. noch CIRCLEs für den Stoplack hinzufügen!
Besser ist immer eine Änderung in der LBR -- aber NIE in den
Eagle-Libs (die werden wieder überschrieben), sondern in eine private
LBR mit den eigenen Varianten kopieren.
Grüße, Hans
Am 20.01.2011 12:28, schrieb Hans Lederer:
Am 20.01.2011 09:28, schrieb A. Zaffran:
>> Am 19.01.2011 16:50, schrieb Hans Lederer:
>>
>>> Besser ist immer eine Änderung in der LBR -- aber NIE in den
>>> Eagle-Libs (die werden wieder überschrieben),
>>
>> Nur wenn man manuell den Pfad der alten Eagle-Installation wählt!
Schon - aber eine neue Eagle-Version auch in einem neuen Verzeichnis
bringt neue Libs hierher mit und setzt den Pfad darauf, oder?
Dann ist die alte geänderte LBR zwar noch da, aber verwaist.
Generell ist es ja richtig, wenn die Libs stets mit aktualisiert werden
-- und eigene Arbeiten gehören da einfach nicht rein, sondern in eigene
Libs.
Nebenbei: warum eigentlich installieren Updates immer in neue
Verzeichnisse? Ich finde das lästig, weil ich jedesmal meine
Verknüpfungen anpassen müsste; und sehe keinen Sinn darin, die alten
Versionen aktiv zu halten. (Gut, ich mache mir bei sowas eh
sicherheitshalber eine Backup-Kopie in eine "Alt"-Ecke, falls ein übler
Fehler in der neuen Version wäre und einen Rückschritt erfordern würde
-- ist mir bei Eagle noch nicht passiert).
Grüße, Hans
Bei mir sind eigene libs auch in einem eigenen Verzeichnis. Bei der
Installation hab ich doch die Möglichkeit zu wählen, ob ich in ein neues
Verzeichnis installiere, oder die alte Version "überbügle".
Ich bevorzuge ein neues Verzeichnis. So habe ich einen schnellen
Vergleich, welche neuen Dateien hinzu gekommen sind.(libs / ulps)
Sollte die neue Version Macken haben, kann ich die alte Version benutzen
ohne sie vorher neu installieren zu müssen. Ist die neue Version OK,
dann fliegt die alte nach ein paar Tagen von der Platte.
Über backups braucht man imho nicht zu reden, das sollte so
selbstverständlich sein, wie das "Amen" in der Kirche. 
--
Mit freundlichen Grüßen / With best regards
Joern Paschedag
Am 20.01.2011 12:28, schrieb Hans Lederer:
Am 20.01.2011 09:28, schrieb A. Zaffran:
>> Am 19.01.2011 16:50, schrieb Hans Lederer:
>>
>>> Besser ist immer eine Änderung in der LBR -- aber NIE in den
>>> Eagle-Libs (die werden wieder überschrieben),
>>
>> Nur wenn man manuell den Pfad der alten Eagle-Installation wählt!
Schon - aber eine neue Eagle-Version auch in einem neuen Verzeichnis
bringt neue Libs hierher mit und setzt den Pfad darauf, oder?
Nein.
Die USE-Liste merkt sich die benutzen LBR inkl. des absoluten Pfad. 
Steht unter Optionen - Verzeichnisse ein $EAGLEDIR.., und räumt man
die USE-Liste nicht einmal leer, USE -*; nachdem eine weitere Eagle-
Version installiert wurde, dann bekommt man die LBRs im ADD-Menu doppelt
angezeigt.
Einmal aus der USE-Liste (absoluter Pfad der alten Installation) und
einmal mit dem Relativen Pfad der aktuellen Version über $EAGLEDIR...
Also einmal USE -*; und dann wieder USE .... und die Welt ist in
Ordnung.
Oder eben den Pfad eindeutig setzen.
Dann ist die alte geänderte LBR zwar noch da, aber verwaist.
Generell ist es ja richtig, wenn die Libs stets mit aktualisiert werden
-- und eigene Arbeiten gehören da einfach nicht rein, sondern in eigene
Libs.
ACK
Nebenbei: warum eigentlich installieren Updates immer in neue
Verzeichnisse? Ich finde das lästig, weil ich jedesmal meine
Viele Anwender möchten dieses Vorgehen, damit sie die alten Eagle-
Versionen parallel auf dem System haben. ***
Auch aus dem Grund, weil viele doch die mitgelieferten Eagle-LBRs
verändern und nicht umbenennen, oder in einen anderen Ordner
verschieben.
Um jetzt nicht einfach die Arbeit der Anwender zu vernichten,
installiert sich eine neue Version/Upgrade in einem "neuen" Pfad,
aber wer will und weiß was er tut, kann mit auf den
alten Pfad umstellen und Eagle darüber installieren. Aber mit dem
Bewusstsein, das Dateien einfach überschrieben werden...
Verknüpfungen anpassen müsste; und sehe keinen Sinn darin, die alten
Versionen aktiv zu halten. (Gut, ich mache mir bei sowas eh
sicherheitshalber eine Backup-Kopie in eine "Alt"-Ecke, falls ein übler
***
Fehler in der neuen Version wäre und einen Rückschritt erfordern würde
-- ist mir bei Eagle noch nicht passiert).
Nicht jeder denkt so konsequent an Datensicherheit und führt sie auch
aus.
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: Dipl.-Ing. Klaus Schmidinger, Bodo Badnowitz
_____________________________________________________________
Joern Paschedag schrieb:
Bei mir sind eigene libs auch in einem eigenen Verzeichnis. Bei der
Installation hab ich doch die Möglichkeit zu wählen, ob ich in ein neues
Verzeichnis installiere, oder die alte Version "überbügle".
Ich bevorzuge ein neues Verzeichnis. So habe ich einen schnellen
Vergleich, welche neuen Dateien hinzu gekommen sind.(libs / ulps)
Sollte die neue Version Macken haben, kann ich die alte Version benutzen
ohne sie vorher neu installieren zu müssen. Ist die neue Version OK,
dann fliegt die alte nach ein paar Tagen von der Platte.
Bei mir liegen /alle/ Arbeitsverzeichnisse komplett abseits der
Programminstallation auf einem Netzlaufwerk (Server).
Bei Updates kann mitgeliefert und mitinstalliert werden, was will - ich
nehme grundsätzlich weiterhin meine eigene Dateien. Nur meine eigenen
Dateien. In die mitgelieferten schaue ich höchstens mal rein, wenn hier
jemand ein Problem damit hat. 
Und ab und zu kopiere ich mal ein ULP von dort in mein eigenes
ULP-Verzeichnis, wenn ich das nützlich finde.
Ich kann daher auch völlig gefahrlos immer ins selbe Verzeichnis
installieren - wenn etwas schief laufen sollte (bisher noch nie),
installiere ich anschließend eben wieder die Vorversion. Und a propos
Installation: niemals mit dem Installer, sondern einfach nur durch
Auspacken der zips.
Über backups braucht man imho nicht zu reden, das sollte so
selbstverständlich sein, wie das "Amen" in der Kirche.
In der Tat.
Tilmann
P.S. Spätestens seit es eingeschränkte Benutzerkonten gibt, haben
Anwendungsdaten im Programmverzeichnis (incl. Unterordner) sowieso
überhaupt nichts verloren. Es ist also schon ab Werk eine
Fehlkonfiguration, daß die Arbeitsverzeichnisse dorthin per Default
angelegt werden. 
Am 20.01.2011 14:48, schrieb Tilmann Reh:
Es ist also schon ab Werk eine Fehlkonfiguration, daß die
> Arbeitsverzeichnisse dorthin per Default angelegt werden. 
Wer traut sich das an Win7 , äh MicroSoft weiterzugeben. 
Ich empfehle nicht erst seit Vista eine Partition D: und E: anzulegen,
und Programme nicht unter C:\Programme (korrekt "C:\Program Files")
oder unter Win7-64bit C:\Programme(x86) zu installieren, sondern unter
D:\Prog (selbst erstellt), damit hat man selber die vollen Rechte,
und wird vom System (MicroSoft) nicht behindert oder ausgesperrt.
Und Daten natürlich auf E: 
Zu "Eigene Dateien", Tempo-Ordner und Auslagerungsdatei sage ich
jetzt lieber nichts, das ist ein anderes (MicroSoft) Thema.
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: Dipl.-Ing. Klaus Schmidinger, Bodo Badnowitz
_____________________________________________________________
A. Zaffran schrieb:
>> Es ist also schon ab Werk eine Fehlkonfiguration, daß die
>> Arbeitsverzeichnisse dorthin per Default angelegt werden. 
Wer traut sich das an Win7 , äh MicroSoft weiterzugeben.
Ich empfehle nicht erst seit Vista eine Partition D: und E: anzulegen,
und Programme nicht unter C:\Programme (korrekt "C:\Program Files")
oder unter Win7-64bit C:\Programme(x86) zu installieren, sondern unter
D:\Prog (selbst erstellt), damit hat man selber die vollen Rechte,
und wird vom System (MicroSoft) nicht behindert oder ausgesperrt.
Und Daten natürlich auf E:
Ja, genauso handhabe ich das schon seit vielen Jahren - damit trennt man
auch gleich die Anwendungen vom Betriebssystem. Aber auch auf
D:\Programme hat ein "normaler" Nutzer keine Schreibrechte.
Zu "Eigene Dateien", Tempo-Ordner und Auslagerungsdatei sage ich
jetzt lieber nichts, das ist ein anderes (MicroSoft) Thema.
Trotzdem ist unter den gegebenen Umständen (hoher Anteil Windows-Nutzer,
Standardkonfiguration wie ausgeliefert nur mit Laufwerk C:) die
Installation ins Programmverzeichnis schlichtweg falsch. Da wäre
vermutlich "Eigene Dateien" (natürlich muß man den Pfad aus der Registry
abfragen) das kleinste Übel.
Mittels TweakUI kann man "Eigene Dateien" übrinx auch nach E: legen.
Tilmann
Am 20.01.2011 04:32, schrieb Tilmann Reh:
A. Zaffran schrieb:
>> Ich empfehle nicht erst seit Vista eine Partition D: und E: anzulegen,
>> und Programme nicht unter C:\Programme (korrekt "C:\Program Files")
>> oder unter Win7-64bit C:\Programme(x86) zu installieren, sondern unter
>> D:\Prog (selbst erstellt), damit hat man selber die vollen Rechte,
>> und wird vom System (MicroSoft) nicht behindert oder ausgesperrt.
>> Und Daten natürlich auf E: 
Ja, genauso handhabe ich das schon seit vielen Jahren - damit trennt man
auch gleich die Anwendungen vom Betriebssystem. Aber auch auf
D:\Programme hat ein "normaler" Nutzer keine Schreibrechte.
Ja, genau. Schon seit NT gibts entweder 3 Platten oder zumindest 3
Partitionen, eine fürs OS, eine für die eigenen Dateien und eine für
Applikationen. Bei 3 HDs bringt das auch Geschwindigkeit weil die
Suchzeiten kürzer werden und bei Backups, Ghost, usw. ist es auch ein
Vorteil (D:\ -> aufs Band).
>> Zu "Eigene Dateien", Tempo-Ordner und Auslagerungsdatei sage ich
>> jetzt lieber nichts, das ist ein anderes (MicroSoft) Thema.
Den Ordner "Eigenen Dateien" habe ich noch nie geöffnet
Tilmann
Gruß, Günter
