Warum analoge und digitale Masse trennen?

Oliver Bartels schrieb: .....

Wenn man für ein paar neue bunte Knöpfe und, im Tausch gegen alte bekannte, einen Sack voll neuer Bugs einen Haufen Geld jedes Jahr hinblättert und die Hoffnung, es habe sich nun endlich wirklich mal etwas signifikant verbessert, zum x-ten mal enttäuscht wird, hat man einfach irgend wann einmal die Schnauze voll von Wartungsverträgen und Updates. ;-)

Moins Paul

Dann sollte man sich einen Anbieterwechsel überlegen, so wie beim Auto auch, dass ständig liegenbleibt.

Das wäre _logisch_.

Obwohl es bei Elektronikdesign und Layout eigentlich um streng naturwissenschaftlich orientierte Jobs geht, vehalten sich manche Nutzer seltsam künstlerisch-philosophisch denn logisch, zum Beispiel:

a) Aus "ein X macht Probleme" wird ein "alle Y der Klasse, in der auch X liegt, müssen Probleme machen, weil ein X Probleme macht." ( siehe hier: Updates, Autorouter, Low Dropout Regler ;-)

oder

b) "Meine Leiterkarten müssen schön aussehen, der Bus klar sichtbar sein", Optik geht über Funktion (*), ( obwohl die Konstellation beim Übergang von Hex. 0xFFFF auf

oder

c) "Ich will keine bunten Knöpfe, aber ich kaufe nur Produkte, die viele bunte Knöpfe beinhalten" ;-)

Jungs, bei Euch in der Branche läuft viel mehr Voodoo und Hifi-PMPA-sauerstoffarmes-Kupfer-Marketing als Ihr wahrhaben wollt ;-/

Gruß Oliver

P.s.: (*) An der Stelle sind Elektroniker nicht alleine, Architekten bauen auch sehr gerne von Außen nach Innen, das Gebäude sieht dann hübsch aus, ist aber extrem unpraktisch. Tja, und was dem Architekten sein Baudenkmal, das ist dem Layouter sein Leiterkarten-Denkmal: "Schau mal wie hübsch die aussieht, die hab ich _designed_". Mir kann keiner erzählen, dass _das_ nicht ein, wenn nicht sogar der wesentliche Grund für Handlayout von völlig unkritisch automatisch entflechtbaren Digitalschaltungen bei vielen Layoutern ist.

Na ja, einer meiner Freunde ist Architekt; wenn man nach Selbstverwirklichung strebt, ist irgendwas mit Software oder Elektronik allemal besser.

Wenn wir in der Nachbarschaft mal an einem Jugendstilhaus vorbeifahren, stöhnt er gelegentlich "Sowas möchte ich auch mal bauen dürfen. - aber mir wollen sie noch jede Stahlbetonsäule streichen, auch wenn ich sie für die Statik brauche....".

Er muss wirklich dauernd den Spagat machen zwischen Kundenwunsch und Bauamt und Kosten. In Potsdam saniert er gerade einen Altbau; für die Farben der Fensterrahmen hat er im Bauantrag sinnvolle Defaultwerte angegeben die sich an den restaurierten Nachbarhäusern orientieren. Nein, nicht pink.

Das geht aber nicht. Ohne bauhistorisches Gutachten ist da nix zu machen. Vermutlich kriegt da jemand ein Kickback vom Gutachter (meine als Außenstehender völlig unfundamentierte Meinung...)

MegaCAD gibt es übrigens wirklich. Gerade bei Architekten beliebt. Ich hab's hier auch auf dem Rechner, weil wir hier auch manchmal einen Bauplan plotten, als Fallback-Solution. Nehmt als Negativbeispiel besser einen anderen Identifier.

Gruß, Gerhard

Oliver Bartels schrieb:

Genau so logisch, wie man natürlich nicht sein neues Auto, was eben nicht mehr liegenbleibt, nachdem man die Macken im Selbstversuch getestet hat und zu berücksichtigen weiß, sofort auf den Müll wirft. Der Gebrauchtwagenmarkt bei CAE/CAD-Software ist ja nicht so ergiebig wie bei Autos. TopCAD schein hier die große Ausnahme zu sein. Und ohne jemandem zu nahe treten zu wollen, wird auch das neue CAE/CAD-Auto nicht ohne Tränen und einigem Aufwand für die Systemumstellung zum flutschendem Alltagswerkzeug mutiern. Auch BAE nicht.

Speziell Layoutdienstleister, zumindest die kleineren Firmen, sind auch nicht gerade die, welche im Geld schwimmen und sich darum sehr gut überlegen müssen, wofür sie wann ihre Kohle verbrennen. Zumal sie typischerweise nicht nur mit einem System auch in gewissem Umfang an ihre Kunden gebunden sind.

Moins Paul

Jawoll. Ich bin zwar kein Layouter, aber meine Kunden benutzen so ziemlich alles von [A, C-Z]*. Ariadne bis Zucken. Import/Export-Möglichkeiten sind da ganz einfach _wesentlich_ wichtiger als ein obergeiler Autorouter. Nein, ich will einfach Daten im/exportieren und keine Programme in irgendeiner user language schreiben.

Ich will mein FPGA-Pinout zwangskorrekt mit dem Layout synchronisiern können. Differenzleitungen automatisch routen können mittlerweile viele. Und für die richtige Hochfrequenz kommt man eben an einem Interface zu ADS oder Genesys oder HFSS auch nicht herum. Wenn ich ein Haarnadelfilter in ElectroMagnetics simuliert & optimiert habe, muss das zwangsweise richtig ins Layout übertragbar sein, am besten auch vom Layout nach Electromagnetics. Ohne neu malen.

_Das_ sind die Punkte die ich _WIRKLICH_ vermisse.

Gruß, Gerhard

auch

Träumen ist erlaubt ;-) 100%ige Konverter die nicht auch noch jeweils Unsummen kosten (um dann doch nur lausig zu funktionieren) wären natürlich der Hit. Das ist für komplette Layout-Datensätze allerdings auch nicht ganz trivial. Aber da klemmt es ja bei Systemen, die ich hier nicht näher benennen möchte, schon beim konvertieren flacher Netzlisten ohne Attribute und Schnickes. ;-)

Beispiel: Zielvorgabe war: ...

Das ist zwar kein Hit und fix behoben, aber wo soll der Kunde Vertrauen in die Sache bekommen, wenn schon so simple Sachen nicht funktionieren? (Dieses Problem ist vermutlich schon längst behoben, was allerdings dem Dienstleister und seinem Kunden, den er auf das nicht näher erwähnte System umstellen wollte, völlig schnurz sein dürfte. Auch das der Konverter in diesem Fall kostenfrei, allerdings auch nicht völlig selbstlos war, da man ja nicht nur einen potentiellen Kunden umstellen wollte, ist da nur ein schwacher Trost. ;-)

Moins Paul

Die mit dem zweiten Buchstaben nutzen dann wohl unser Netz ;-)

Da haben wir es natürlich relativ einfach:

- Primär Produktentwicklung und bedarfsweise werden EDA Lizenzen einkalkuliert, irgendwozu muss so ein Gemischtwarenladen, wie wir ihn haben, ja gut sein.

Gibt es längst, nicht nur bei uns, Protel macht z.B. viel Werbung damit.

Z.B. erzeugt Xilinx entsprechende Pinout-Dateien, daraus baut das System dann ein Symbol und die log. zu phys. Namenszuordnung.

Gibt es auch schon längst. Du weißt allerdings auch, was die Tools kosten, deren Namen Du da gerade eben mal hingeschrieben hast. Genau daran scheitert es meistens.

Was allerdings jetzt kommt, ist die integrierte Lösung (es gibt mittlerweile irgendwie so komische Routinen, die Geometriedaten in eine Matrix kippen und irgendwelche, die letztere rechnen ;-) bei uns allerdings nur in den großen Systemen. Damit braucht man garnichts mehr konvertieren.

Gruß Oliver

Ja, und das Orcad & PADS DXP-Interface scheint auch zu gehen.

Argh, noch ein Electromagnetics-Simulator.

Der füllt eine dringend benötigte Lücke.

In meinem Bekanntenkreis wird eigentlich schon genug diskutiert, ob im jeweiligen Fall gerade Momentum, HFSS, Genesys, CST, Sonnet oder Appwave recht hat.

Die Welt des Benutzers braucht Interfaces und kein n++ für ein Problem, das NP-complete ist.

Ein tatsächlicher added value wäre aber der effiziente Umgang mit Clustern aus 8-core-Prozessoren oder so.

Gruß, Gerhard

Hallo Oliver,

Mein Layouter liefert mit nicht taufrischer Software immer saubere Arbeit. Am Ende ist Gerber File = Gerber File. Muesste ihn mal fragen, was er fuer ein Auto faehrt ....

Noe, ich wuerde einen Sitz besorgen und einbauen. Oder Neupolstern, schon oefter bei Sitzmoebeln gemacht.

Ist bei Autos und Hardware anders. Da erwarte ich, dass z.B. Ersatzteile weit mehr als 10 Jahre lieferbar sind. Sah letztens eine Armaturenfirma der Nobelklasse anders. Mit dem Erfolg, dass wir (und inzwischen etliche Nachbarn) die naechsten 30-40 Jahre nichts mehr von denen kaufen werden.

Ich kenne hier in USA fast niemanden, der Eagle benutzt :-(

Keine Sprueche, die Marke Cadsoft und das Produkt war bei saemtlichen meiner Kunden voellig unbekannt. Und das sind schon einige. So laesst sich keine Markenpraesenz aufbauen. Ohen Werbung geht es nicht.

Richtig. Doch man muss sich ueberlegen, ueber welche Kundenkreise man in den Markt eindringen moechte und das dann konsequent durchziehen. Sonst kann man die entsprechende Region in Sachen Marketing getrost vergessen. Ich weiss aus der Medizintechnik, wie das laeuft (und habe meinen ersten Kontakt ins Marketing dort geheiratet ...).

Oder man macht es wie Cadsoft und bietet ein Projekt an, bei dem wenig Support noetig ist und selbiger grossenteils ueber User Foren erfolgt. Das haben die exzellent gemacht, so wie m.W. keine andere Firma. Wenn jemand festhaengt, helfen wir uns gegenseitig. Nur mit der Werbung hapert's.

Hm..hast du schonmal Circuit Cellar gelesen? Ich glaub die haben keine Ausgabe wo Eagle nicht eine DINA4 Seite belegt.

Das klappt aber nur wenn bereits eine gewisse Grundmasse an Kunden da ist. Ausserdem ist es gefaehrlich weil Kunden sich dann manchmal zusammenrotten und dreiste Wuensche aeussern. :-)

Olaf

Hallo Oliver,

Ok, aber man koennte sich fragen, welche weiteren Gruende es gibt, warum das EDA Geschaeft so muehsam ist. Gerhard sprach einen sehr wunden Punkt an: EDIF hat de-fakto fuer User wie mich nichts gebracht. Manche Firmen wie Cadsoft sind zur Offenheit der Schnittstellen bereit, die meisten anderen nicht.

Warum klappt das bei Messgeraeten, wo es ebenso harte Konkurrenz gibt? Konkretes Beispiel: Neues DSO hier auf dem Tisch, per PC auf Fernsteuerbarkeit getestet. Der komplette Instrument Command Set offengelegt und an die Industriegepflogenheiten angelehnt. Kannst Du bei Instek herunterladen, ohne Password und solchen Firlefanz. Das fluppte noch am gleichen Tag.

Hallo Olaf,

Das wird eher von Hobbyisten gelesen, seltener von Consultants wie mir oder Leuten in Kleinbetrieben. Muesste man mal ueberlegen, wie OrCad vor zig Jahren Marktfuehrer wurde. Ich hatte damals eine Werbung gesehen, in Deutschland. War nicht mal in Deutsch uebersetzt worden, hatte mich aber zum Kauf gebracht und zum Kunden gemacht. Ich glaube, das war 1989 oder so. Vorher kannte ich nur Futurenet-Dash und Racal-Redac.

Das tun die in Eagle Foren auch. "Koennte Eagle nicht oben links den Fuellstand des Bierfasses im Kuehlschrank anzeigen?"

Doch der Clou ist: Man hilft sich gegenseitig.

Ja, wir kommen der Sache langsam näher ;-)

Es liegt wohl nicht nur daran, dass der Anbieter zu dumm ist, eine Werbeagentur zu beauftragen ;-)

Nack, offene Schnittstellen bekommst Du bei den allermeisten Systemen, die sind nicht das Problem.

Hast Du schon mal probiert, auf so einer Schnittstelle zu programmieren ?

Ich schon, und dabei merkt man schnell zwei Dinge: a) Nicht jedes Zielsystem unterstützt jede Funktion des Quellsystems, weil letztlich jede Funktion mit Datenrelevanz Einzug in eine solche Schnittstelle findet. Konkret: b) Viele Layoutsysteme haben nur eine sehr eingeschränkte Connectivität und erlauben den Import von geometrischen Elementen nur in einer Form, welche konform zur systemspezifischen Anbindung der Geometrie an die Verbindungsinformation ist.

Auch darum ist EDIF im Bereich der Geometrie gescheitert, wohingegen es bei Netzlisten sehr gut funktioniert. Und exakt deshalb funktioniert auch Gerber, es hängt schlicht keine editierfähige Connectivity dran.

Es ist kein böser Wille, die Formate sind meistens recht gut dokumentiert.

Nur: Was willst Du denn bitte machen, wenn das Zielsystem schlicht nicht kann, was man von ihm per Format verlangt ?

Bei uns im System kann eine Leiterbahn z.B. mitten auf Kupfer enden und wird korrekt erkannt, dahinter steht ein _erheblicher_ Rechenaufwand, da dies in Realtime geschehen muss. Deshalb hab' ich auch keine Probleme damit, wenn Gerhard irgendwelche HF Filter von ADS & Co als Kupfer importieren möchte, geht, wird längst praktiziert, wird längst drüber telefoniert (über die importierten Filter ;-)

Aber was bitte soll denn ein armes "kleines" System machen, dessen Connectivity Rubberband- oder bestenfalls Eckpunkt- basierend ist, da _fehlen_ schlicht die Routinen, um bei Import den Schnitt der Leiterbahn mit dem Polygon zu erkennen, da _fehlen_ Routinen, um besagtes Polygon in einen Vergleich Soll- zu Ist-Netzliste einzubinden, da _fehlen_ die Routinen für Kreisbögen bei HF-tragenden Stripline Leiterbahnen.

Und Du wirst doch jetzt nicht allen Ernstes erwarten, dass jetzt alle auf den kleinsten gemeinsamen Nenner gehen und keine Filter mehr mit Polygonen bauen, jede Ecke in einer Stripline von Hand korrigieren, weil Kreisbögen nicht gehen usw.

Weil es dort auch nur bezüglich der Ansteuerung per se klappt, nicht aber bezüglich des Funktionsumfangs.

Und, was machst Du, wenn Du eine Anwendung hast, die z.B. Sequences a'la LeCroy auf dem DSO verlangt und Dein DSO das halt nicht kann und auch nie können wird ?

Oder wenn Du ein Signal erzeugen willst und das IEEE488 Programm spricht den Arbiträrgenerator beim Vektormodulator an, der in Deiner Kiste nicht eingebaut ist.

Genau _daran_ scheitert EDIF für Geometrien. Nicht am bösen Willen der Anbieter, die wären heilfroh, wenn man nur noch _ein_ Interface pflegen bräuchte. Zumindest kann ich das für uns klipp und klar sagen. Btw. Wir haben z.B. einen EDIF Geometrie Import im Schaltplan, den nutzt nur kaum einer.

Gruß Oliver

P.s.: Ich hab' das bei einem IC-Layout gehabt, das Zielsystem der Foundry konnte _formal_ GDS2, hat aber bei bestimmten legalen Konstrukten, die wirklich nicht komplex waren, Gift und Galle gespuckt. Die Jungs waren fix- und fertig, weil die Daten eindeutig legal waren und die noch nie erlebt hatten, dass ihr _Fertigungs_- system derartige Zicken macht. Wir haben die dann im Interface umgeschrieben. Seitdem gibt es unterschiedliche GDS2 Outputs für diese und für jene Foundry. Wie kommt das: Nun ja, der Anbieter des Systems hatte halt nur gegen Vendor M und Vendor C Daten getestet und hatte mal eben ein paar Elemente des Standards nicht implementiert, von denen er glaubte, dass sie eh' in den Daten nicht vorkommen.

Hallo Oliver,

Leider nicht. O-Ton von Eagle: Koennten wir machen, doch Cadence rueckt die Format-Info nicht raus.

Nein, ich bin kein Programmierer. Als Designer wuerde ich erwarten, dass die Schnittstelle einfach funktioniert. Z.B. OrCad Schaltplan in Eagle oder umgekehrt. Nicht mal das geht.

Waere ok. Ich wuerde nicht erwarten, dass aber auch alles funktioniert. Ein Schaltbild mit Chips, Transistoren und Widerstaenden ist jedoch nicht gerade Raketenwissenschaft. Layout schon, das ist was anderes.

Die sind IMHO an mangelnder Bereitschaft einiger "Stake Holders" gescheitert.

Das ging wohl eher auf die uebliche: Eine Firma wurde Marktfuehrer und deren Format wurde Standard. So wie *.doc und *.pdf.

Das hatte mir Cadsoft aber ganz anders erzaehlt.

Ein geschicktes System meldet sich dann zu Wort bzw. zu Bildschirm ;-)

Das muss es doch gar nicht. Wenn ich ":acquire:average_8" eingebe und es diese Funktion hat, antwortet es entsprechend. Sonst eben nicht.

Dann erscheint von meinem Scope eine Meldung, dass es diese Funktion nicht kennt.

Der Instumentenbus ist offenbar nicht dran gescheitert.

Bei mir vorige Woche schiefgelaufen: SC-75 Pinout. Nicht mal das haben die EDIF Jungens auf die Reihe bekommen. Die Hersteller auch nicht, denn offenbar redet man nicht miteinander. Nur drei Pins, au Mann.

Also haben wir jetzt einen Autonetics-Analogconsultants Standard eingefuehrt:

Joerg schrieb:

Das Elend fing ja speziell bei diesen Dreibeinern schon mit SOT23 an. ;-) Da kann ich nur raten auf alphanumerische, sinnige Bezeichnungen zu wechseln. Insbesondere, wenn man mit getrennten Bibliotheken arbeitet, damit es wenigstens beim Layouter klingelt, wenn die Zuordnung nicht stimmt (z.B. Schaltplan u. Netzliste Orcad / Layout was anderes). Beispielsweise E B C; S G D; A K AK A1 A2 ...; ... (K wegen C).

Moins Paul

Ach. Soso ;-)

Hmm, dann geht der Import von OrCAD Schema nach BAE wohl ungefähr so:

1. Der Kunde lädt den Schaltplan in OrCAD
2. Der Kunde wählt EDIF 3 0 0 Export aus.
3. Es geschieht ein Wunder! Wir beten alle zur heiligen Madonna! Denn eine EDIF Datei mit allen Daten hat auf wundersame Weise den Weg zur Erde auf die Festplatte gefunden.
4. Der Kunde geht ins BAE Schema. Er wählt : Datei => Import/Export => EDIF-Daten Import und gibt ein paar weitere Daten wie den Dateinamen ein.
5. Es geschieht noch ein Wunder! Wir verneigen uns vor dem Rechner mit dem Heiligenschein ;-) Denn das Schema wurde importiert.

Und es muss sich um ein Wunder handeln, denn es ist doch ganz klar, das Cadsoft nur und immer und grundsätzlich Recht hat und alle anderen nicht und wenn die sagen, dass man aus OrCAD nix exportieren kann, dann muss das so sein und dann ist das, was da geschieht, halt ein Wunder ;-)

Es ist schon korrekt, dass Cadence nach meiner Erfahrung gerne mal die Nase sehr weit oben trägt, _aber_: Was nicht richtig ist, ist nicht richtig, das gilt selbst für Dinge, die man dem pösen Mitbewerb unterschieben möchte:

Natürlich kann man bei Orcad Schema einen EDIF Export vornehmen und man kann die Daten dann auch z.B. in unserem System per EDIF Import wieder nutzbar machen.

Wenn Du es nicht glaubst:

Hier:

Dass Cadence das _Binär_format nicht rausrückt, ist klar, das bekommst Du von uns auch nicht.

Und zwar unter anderem aus dem ganz einfachen Grund, weil es sich um ein komplexes Datenbankformat handelt und weil wir keinen Bedarf verspüren, dass uns obskure Konverter in internen Strukturen rumpfuschen und wir dann z.B. wegen einem vermurksten B-Tree, der erst viele Monate später bei nachfolgenden Operationen auffällt, Fehler in die Schuhe geschoben bekommen, die nicht unsere sind.

Für Datenaustausch gibt es offizielle dokumentierte _Schnittstellen_, eben wie EDIF.

Exakt danach hast Du gefragt, dazu sind sie da, über die kann man Daten ein- und ausspielen und bei der Gelegenheit werden die auch zumindest soweit auf Plausibilität geprüft, dass bei nachfolgenden Operationen auf der Datenbank nichts schief gehen kann.

Schaust Du in mein vorheriges Posting, da hatte ich Dir schon geschrieben, warum es bei manches Systemen in der Praxis trotzdem klemmt, wenn die programminterne Logik nicht ausreicht, um volles EDIF zu verarbeiten, dann reicht sie eben nicht aus.

Layout geht auch. Schaust Du z.B. Menüpunkt Datei => Import/Export => OrCAD MIN-Import.

Scheint also schon irgendwie machbar zu sein, wenn man nur will.

Aber wahrscheinlich willst Du mir jetzt sagen, dass wir zu wenig Werbung dafür machen, dass Interfaces auch mal zufälligerweise funktionieren können ;-)

Nö, nimm das Beispiel oben: Dein Lieblingssystem ist nämlich genau so ein Kandidat, wo man über die internen Fähigkeiten des Programms durchaus diskutieren kann.

Versuch mal, einen Leiterzug _wahlfrei_ und transitiv (indirekte Verbindung zwischen drei oder mehr Pins, z.B. A-D wird über A-B-C-D realisiert) ohne viel Handstand einzugeben, unter Einbeziehung mindestens einer Kupferfläche, und nein, bitte nicht auf die Ecken zielen, dann wirst Du ganz schnell merken, was ich meine. Eingeben heißt hier eingeben und heißt nicht hintricksen, denn letzteres kann ein Interface nicht.

Es gibt genügend Designs, sei es Allergro, BAE usw., deren Import exakt deshalb Probleme machen wird bzw. ganz scheitern kann.

Gerber ist so einfach, dass es im Prinzip wirklich jeder bearbeiten kann.

Ausnahmen bei Kreisbögen und Polygonen (Extended Gerber) bestätigen die Regel.

Ich hätte hier schon noch ein paar (Gummi-)Bären abzugeben, und Kordel zum draufbinden hast Du sicher selber ;-)

Noch Fragen ?

Wir lernen: Genau so funktioniert Marketing, auch dann, wenn ein Produkt mal etwas nicht kann.

Ach ;-)

Das schaut nur etwas blöd aus, wenn man einen Import macht und das Zielsystem dann sagt: "Leiterbahnen-Kupfer-Connectivity kann ich nicht" "Transitive Leitungen kann ich auch nicht wirklich" "Bitte halten sie sich an die intern gerechneten Gummibänder" "Vermeiden sie bitte allzuviele T-Stücke"

Dann könnte dem Kunden nämlich sehr schnell klar werden, was sein System alles nicht kann. Und das möchte man doch eher nicht, Du weißt schon, Marketing ...

Ich bin lange genug in dem Geschäft und hab' einen kompletten Kern eines (PCB/IC) Systems, das sehr wohl einen echten Soll/Ist-Abgleich der Connectivity _inkremental_ (und damit in akzeptabler Zeit online parallel beim Arbeiten) und einen DRC ebenfalls inkremental und online machen kann, geschrieben, dass ich Dir sagen kann: a) Ich weiß, was für eine Arbeit das ist und wie lange es braucht, um das hinzubekommen. Diverse Open Source Projekte sind daran gescheitert, nachdem sie gemerkt haben, wo der Hase im Pfeffer liegt. b) Ich weiß auch, dass viele EDA Softwareentwickler sich genau diese Arbeit gespart haben und das Fehlen diverser Funktionen aus diesem Dunstkreis mit ganz vielen Bunti Bildi, "Assistenten" und sonstigen Krücken kaschieren.

EDIF funktioniert auch. Siehe oben. Du wolltest EDIF @ Work, Du hast ein Beispiel bekommen.

Dass nicht jedes EDA System EDIF-Schemas importieren kann, wohl aber die meisten etwas besseren Messgeräte einen Busanschluß haben, liegt ganz einfach daran, dass ein EDIF-Import ungleich schwieriger zu implementieren ist.

Es gibt aber auch Instrumente ohne Bus, z.B. einfache Multimeter.

Du hast Dir im übertragenen Sinn ein solches einfaches Multimeter zugelegt, auch wenn Du glaubst, es würde wie ein großes Keithley aussehen. Letzteren Glauben bewirkt das Marketing ;-)

Nur kann auch das Marketing keine Wunder vollbringen und aus Deinem einfachen Multimeter ein volles Keithley mit allen Features machen, es gibt halt einige Dinge, die Deinem einfachen Multimeter fehlen.

Dafür war es _billig_. You get what you pay for.

Billig heißt hier übrigens nicht schlecht, sondern einfach nur, dass es halt bestimmte Funktionen nicht hat und nicht kann und auch nach Schönreden nicht können wird und Du gerade eben bei exakt einer solchen Funktion hart angestoßen bist.

Das ist so, wie wenn Du Dir als Transportunternehmer einen kleinen Pickup-Wagen für kleines Geld holst, der absolut zuverlässig läuft, und damit beim Kunden vorfährst und der Dir dann sagt: "Nu fahrn se mal an der Rampe 8 vor und laden dann mit dem Gabelstabler dort die 25 Paletten mit Maschinenteilen ein, Gewicht ca. 30 Tonnen."

Da ist dann halt ein anderes Tool gefragt ;-)

Also EDIF Transfer wird von unseren Kunden regelmäßig ohne Probleme praktiziert.

Vielleicht solltest Du Dir ganz einfach einen geeigneten LKW besorgen, wenn Du als Unternehmer gedenkst, am gewerblichen Güterfernverkehr teilzunehmen.

Es gibt bei den Dreibeinern historisch gewachsen in den Datenblättern zwei Varianten, nämlich Deine und 1/2 vertauscht. Wenn man die Bibliothek mit importiert, stellt das aber kein Problem da. Ansonsten bei Anpassungen gehört das auf die "bitte beachten" Liste.

Gruß Oliver

Ack, die Hersteller waren sich bei der Numerierung nicht einig und sind es auch heute noch nicht. Inzwischen geht es meist gegen den Uhrzeigersinn rum.

Gutes Stichwort, auch bei BGA:

Kann eigentlich jedes EDA System alphanumerische Pinbezeichner im Layout verarbeiten, und wenn ja, seit wann ? ;-)

Gruß Oliver

P.s.: Bei soetwas ist es wichtig, dass es eine vom Layoutsymbol und Schemasymbol getrennte Zuordnung (Logikdefinition) und eine lokale Kopie von Elementen in den Projekten gibt. Dann kann man gefahrlos auf ein anderes Layoutbauteil schwenken und schrittweise die Logikdefinitionen vereinheitlichen, ohne unliebsame Überraschungen bei Altprojekten befürchten zu müssen.

Das Problem geht sogar noch weiter: Es ist gar nicht nötig, den Standard bewußt unvollständig zu implementieren. Man kann nun mal nicht gegen alle existierenden Produkte testen. Ich habe dieses Problem sowohl als Benutzer als auch als Programmierer einer Schnittstelle kennengelernt und bin daher immer sehr vorsichtig mit Bewertungen. Die hängt dann eher am Support: Wenn der mir in einem solchen Fall weiterhelfen kann, ist ja alles OK.

Viele Grüße,

Georg

Oliver Bartels schrieb:

Jedes System, welches für mich als "Haussystem" in Frage kommt schon. ;-) Was sich dann sonst noch so ansammelt ... Na ja. :-( Bei Joerg war es Orcad, wenn ich mich recht erinnere. Orcad kann _das_, ebenso wie das Pads seines Layouters, zumindest auch. *g*

Ack.

Moins Paul