Heyho, ich wollte gerne mal eure Erfahrungen den professionellen Hardwareentwurf betreffend hören. Ich finde, derzeit wird Hardwareentwurf noch betrieben, wie Softwareentwurf vor 20 Jahren. Die Dokumentation ist meistens eher nicht vorhanden, weil man hat das ja selbst designed und weiß daher, wie es funktioniert (Analogie: keine Kommentare im Code). Zugegebenermaßen, machen es einen die meisten CAD Tools auch nicht gerade leicht Kommentare in den Schaltplan einzubringen. Dann werden die Schaltpläne meist auch noch mit Bezug zu Papierblättern entworfen, etc. etc. Man merkt eben, das wurde früher alles von Hand gemalt und man hat es einfach 1:1 übernommen. Ein weiteres Ding: Versionsverwaltung. Da die meisten CAD Tools irgendwelche Binärblobs rausschmeißen: extrem schwierig extern zu machen und intern, wenn überhaupt nur sehr rudimentär vorhanden. Selbiges gilt für die Bauteilsuche. Meist sehr mühsam. Analogie dazu: Nicht dokumentierte API. Auch das reuse von Designs besteht zu meist aus dem mehr oder weniger fehlerträchtigen herauskopieren von alten Schaltplänen. Da es auch keine Versionsverwaltung gibt, weiß man auch nie, ob die Baugruppe gerade aktuell ist. Ist das bei euch ähnlich? Macht ihr manche Dinge besser? Fällt das nur mir auf? Das sollte genug Stoff für eine hoffentlich ergiebige Diskussion liefern. Ich bedanke mich schon einmal bei allen Teilnehmern.
Eigentlich alles falsch... Schau dir mal z.B. Altium an. Wenn du eine Schaltplan überarbeitest, solltest du in der Lage sein eine Schaltplanseite für die History zu opfern. Ob du es tust, ist deine Sache! Wie bei den Quellcode-Kommentaren. Der Rest ist eigentlich Standard in teuren Tools...
Achso, noch zur Klärung... Geht es darum das dir die Tools nicht ausreichen oder die Use die Tools nicht ausreichend ausnutzen?
> Die Dokumentation ist meistens eher nicht vorhanden, weil man hat das ja > selbst designed Willst du hier ein Hardwarebashing veranstalten? > Ist das bei euch ähnlich? Nein. > Macht ihr manche Dinge besser? Ja. Im Übrigen: unfähige Entwickler können auch mit noch so guten CAD-Systemen haarsrträubenden Müll erzeugen.
Basti schrieb: > Geht es darum das dir die Tools nicht ausreichen oder die Use die Tools > nicht ausreichend ausnutzen? Dazu ein einfach Ja :D Da die Tools meines Erachtens nach noch nicht so da sind, sind es natürlich auch die Nutzer nicht. Zu Altium: Ja, es hat sich in den letzten 2-3 Jahren einiges Gutes getan, aber meines Erachtens nach ist die Software immer An den Bürovorsteher: Nein, ich möchte kein Hardwarebashing betreiben und es freut mich, dass ihr Dinge besser macht. Wärst du auch noch so nett zu erläutern, wie ihr das macht? Auch besteht meines Erachtens nach natürlich das Problem, dass der Wechsel des CAD Systems extrem aufwendig ist, da man die ganzen Bibliotheken meist nicht so einfach portieren kann.
Schon mal was vom Lasten-/Pflichtenheft gehört? Wie man die Versionsprobleme dann betriebsintern regelt, ist die Frage eines Qualitätsmanagements, dass dann konsequent gelebt werden muss. Wenn man Bauteile auswählt, muss man jede Menge Protokolle und Datensätze pflegen, denn da sind dann ja auch viele Abteilungen, die darauf mal drauf zugreifen müssen. Beispiel: Entwicklung, Einkauf, Fertigung, Prüffeld, Qualitäts- management, Buchhaltung, Vertrieb usw. usf. je nach betrieblicher Organisationsstruktur.
nfet schrieb: > Auch besteht meines Erachtens nach natürlich das Problem, dass der > Wechsel des CAD Systems extrem aufwendig ist, da man die ganzen > Bibliotheken meist nicht so einfach portieren kann. Na und die Altprojekte auch nicht. Daher geht das nur händisch. Es sei denn, es wird eine Software mit angeboten, die einem die Arbeit erleichtert. Ich hab mal mit so einem Programm gearbeitet, das Boards von Protel nach Cadsoft konvertierte, bzw. zumindest es versprach. Wenn die Bauteile in den Bibliotheken nicht kompatibel waren, konnte man das ganze knicken. Arbeitsersparnis war da nahe NULL. Da hätte man locker über ein Jahr gebraucht um die Bibliotheken fehlerfrei kompatibel zu bekommen.
Cyborg schrieb: > Da hätte man locker über ein Jahr gebraucht um die Bibliotheken > fehlerfrei kompatibel zu bekommen. Ja, ich glaube das ist ein ganz großes Problem, weswegen die Entwicklung in der Hardwareentwicklung (hihi) der Software hinterher hinkt. Es gibt keinerlei definierte Standards, so dass alle CAD Hersteller zueinander in absolut jeder Hinsicht inkompatibel sind. Und da beschweren sich die Softwerker, wenn sich ein Compiler ein bisschen anders verhält. Immerhin sind die alle in der Lage ASCII Code zu lesen!
Hm, irgendwie verstehe ich nicht auf was der TE genau hinaus will... Geht es nur um die reine Schaltungs- und Layoutentwicklung, oder geht es auch um das ganze drumherum? Also Fertigung, Anwendung, QS, Service usw.? mfg Gast
Vermutlich langweilt sich der TO nur und will nicht auf den Freitag warten. Aber recht hat er schon, aber ändern wird er das nicht können. Das ist wie bei den Autoherstellern. Bis auf ein paar Ausnahmen (Reifen z.B.)ist da nichts kompatibel.
_Gast schrieb: > irgendwie verstehe ich nicht auf was der TE genau hinaus will... Klarer Fall: Vorbereitung auf Freitag. nfet schrieb: > Ich finde, derzeit wird Hardwareentwurf noch betrieben, wie > Softwareentwurf vor 20 Jahren. Ganz generell wird auch der Softwareentwurf im professionellen Umfeld noch genau so betrieben wie vor 20 Jahren. An dem Fakt, daß es zum eigentlichen Entwickeln eben eines (oder mehrerer) menschlichen Entwicklers bedarf, hat sich garnix geändert. Und sowas wie die Wahl einer Programmiersprache oder eines EDA-Systems sind nachgeordnete Angelegenheiten. Genauso geht es beim Hardwareentwurf. Man kann beides nicht durch das Betreiben irgend einer Software ersetzen. Software aller Art ist nur in den Folgeprozessen relevant: Umsetzung des Entwurfes, Fehlertests, Archivierung, Fertigungsvorbereitung, Steuerung von Fertigungsmaschinen. Den Entwickler kann man eben nicht durch nen Affen+PC ersetzen. Obwohl das mancher gern so hätte. W.S.
Cyborg schrieb: > Vermutlich langweilt sich der TO nur und will nicht auf den > Freitag > warten. Deswegen seid ihr ja wohl auch hier. W.S. ich bin durchaus der Meinung, dass das passende Werkzeug ein notwendiges Kriterium zum guten Entwickeln ist. Aber natürlich macht gutes Werkzeug keinen guten Entwickler. Da muss sich auch die Denke noch verändern. Ich merke es ja selber, wie automatisiert man im Softwarequellcode seinen Code kommentiert, wohingegen meine Gedanken bei den Layouts meist nur auf Nachfrage weitergegeben werden. Selbiges gilt fürs modularisieren. Wann denkt man da schon groß beim Hardwareentwurf dran? Natürlich ist es da nicht so einfach möglich, aber eben auch nicht unmöglich.
Hm, und wer hindert dich daran was dazu zu schreiben? z.B. Uref = 1,123V am FB-Pin von einem Schaltregler. oder Bohrung 1-4 für Montage in Gehäuse X weil mehr machst du bei Software ja auch nicht wenn du diese kommentierst. Du schreibst ja auch nicht das hier jetzt eine Switch-Case Anweisung kommt, weil diese vom Compiler besser umgesetzt wird als verschachtelte If-Then Anweisung. Und beim Layout schreib ich auch nicht dazu, das ich beim Schaltregler die Switching Node auf minimale Ausdehnung auslege, damit die Störaussendung klein bleibt. Warum auch, wer Ahnung von der Sache hat weiß sowas, und der Rest soll die Finger davon lassen weil eh nichts wird. mfg Gast
Ich meinte mit Kommentaren auch eher, was macht dieser Schaltungsteil oder diese Diode ist dafür da. Das man nicht reinschreibt, dass über einen Widerstand wohl Spannung abfällt oder ein Linearregler linear regelt, ist ja wohl klar, solche Kommentare macht man in Software auch nicht. Was man aber sehr wohl beschreiben könnte, wäre was das Zusammenspiel dieser 5 Bauteile bewirkt. Oder warum habe ich hier gerade Linear Regler X und nicht Y genommen. Son Zeug halt. Das das beim Layout etwas weniger nötig ist, als beim Schaltplan erstellen, da kann ich dir zustimmen. Mit dem passenden Schaltplan und wenn das Gehäuse bekannt ist das Layout tatsächlich recht selbtserklärend.
nfet schrieb: > Ist das bei euch ähnlich? Hobbyfrickler oder Industrie ? Selbst der Hobbyfrickler hat begriffen, daß zu einem Projekt eine Mappe gehört, in der alles abgeheftet ist was er während seines Projekts erstellt und gesammelt hat, jedes Datenblatt, jede Handskizze, Messwerte von Tests, Platinenlayout und Gehäusemasszeichnung, Software, Bestelllisten, denn einerseits erleichtert das die Fehlersuche bei Problemen die natürlich erst in 10 Jahren auftreten, bzw. Erweiterungen und Anpassungen. Neben dem Verzeichnis auf dem PC merkt man schnell, daß vor allem die gedruckten Blätter wichtig sind, denn man hat sie immer zur Hand, und man hat sie auch noch nach dem der dritte PC ersetzt worden ist. nfet schrieb: > was macht dieser Schaltungsteil oder diese Diode ist dafür Das ist ja wohl Kinderkram, nur ungewöhnliche Anwendungen sollte man erklären. Interessanter sind Werte wie Stromverlauf am Bauteil und daraus berechnete Verlustleistung, oder Bemerkungen zur Lebensdauer von Bauteilen weil man deren Ausfälle gesehen hat. Also das: nfet schrieb: > warum habe ich hier gerade Linear Regler X und nicht Y genommen
Schaltpläne enthalten viel weniger Informationen als Software. Darum kann sie meist gut graphisch ausreichend dargestellt werden. Das reicht dann meistens. Leider ist ein diff so deutlich schwieriger.
nfet schrieb: > Ich finde, derzeit wird Hardwareentwurf noch betrieben, wie > Softwareentwurf vor 20 Jahren. Es gibt sowohl Hardware- als auch Softwareentwickler, die auf dem Stand vor 20, 10 oder 0 Jahren arbeiten. Ich selbst muss mich auch gelegentlich mit Hardwareentwicklern bei Kunden herumschlagen, die den neuesten Altium Designer immer noch so einsetzen wie ihr geliebtes Protel 99 aus dem letzten Jahrtausend. In Sachen Softwareentwicklung erlebt man aber auch ziemliche Anachronismen. Allerdings muss man schon beachten, dass gerade im Bereich Software sehr viele Hypes entstehen und genauso schnell wieder abklingen. Sobald man nämlich irgendein neues Tool dann wirklich produktiv einsetzen will, zeigen sich dann seine Schwächen. Manche werden behoben, andere nicht. > Die Dokumentation ist meistens eher nicht vorhanden, weil man hat das ja > selbst designed und weiß daher, wie es funktioniert (Analogie: keine > Kommentare im Code). Schaltpläne sind aber meistens wesentlich einfacher zu überblicken als Software. > Zugegebenermaßen, machen es einen die meisten CAD Tools auch nicht > gerade leicht Kommentare in den Schaltplan einzubringen. So ziemlich jedes EDA-Programm der letzten zwanzig Jahre erlaubt es, Kommentare in Schaltplänen unterzubringen, wahlweise als direkten Text oder als Textbox. Gegenfrage: Welche Programmiersprache oder IDE erlaubt es denn, neben einem Syntaxhighlighting mit selbst definierten Textfarben zu arbeiten? > Dann werden die Schaltpläne meist auch noch mit Bezug zu Papierblättern > entworfen, etc. etc. > Man merkt eben, das wurde früher alles von Hand gemalt und man hat es > einfach 1:1 übernommen. Stromlaufpläne werden aber auch heute noch ausgedruckt, weil man sie auch nach der Fertigstellung der Schaltung noch benötigt, z.B. bei der Inbetriebnahme der Schaltung. > Ein weiteres Ding: Versionsverwaltung. Da die meisten CAD Tools > irgendwelche Binärblobs rausschmeißen: extrem schwierig extern zu machen > und intern, wenn überhaupt nur sehr rudimentär vorhanden. Bessere EDA-Systeme besitzen durchaus Anbindungen an externe Versionskontrollsysteme wie z.B. Subversion und erlauben durchaus auch aus dem Programm heraus, ältere Stände zu vergleichen usw.. Der Storage Manager in Altium Designer führt sogar eine interne Versionierung von Zwischenständen durch die mittels "Save" bzw. Strg-S gespeichert werden. Welche in der Softwareentwicklung genutzte IDE bietet denn solch einen Komfort bei der Versionsverwaltung? > Selbiges gilt für die Bauteilsuche. Meist sehr mühsam. Analogie dazu: > Nicht dokumentierte API. Bei der Nutzung von API muss man zusätzlich noch beachten, zu welchen Betriebssystemversionen usw. sie kompatibel sind. Bei elektronischen Bauteilen kann man verschiedene "Generationen" durchaus mischen, d.h. z.B. einen bedrahteten Kohleschichtwiderstand anno 1960 direkt neben einen Zynq packen. > Auch das reuse von Designs besteht zu meist aus dem mehr oder weniger > fehlerträchtigen herauskopieren von alten Schaltplänen. Da es auch keine > Versionsverwaltung gibt, weiß man auch nie, ob die Baugruppe gerade > aktuell ist. Und wieso sollte es da keine Versionsverwaltung geben? Ob jedoch eine Baugruppe aktuell ist, ist eher eine Frage der internen Organisation bzw. Strukturierung von Repositories und Verzeichnisstrukturen. Ich arbeite z.B. sehr gerne und erfolgreiche mit Bibliotheken, die ich per svn:external in ein Projekt einbinde. Bei der Erzeugung von Freigaben werden solche externals dann mit entsprechenden Peg-Revisions verknüpft und somit eingefroren. Dies erfolgt aber nicht aus AD heraus, sondern mit TortoiseSVN oder auf der Linux-Kommandozeile. > Ist das bei euch ähnlich? Macht ihr manche Dinge besser? Nein. Ja. > Fällt das nur mir auf? Ganz einfach: Du bist derjenige, der in Sachen Hardwareentwicklung nicht auf der Höhe der Zeit ist, sondern die erwähnten zwanzig Jahre hinterherhinkt. Daher solltest Du Deine diesbezüglichen Defizite nicht auf Dritte projizieren, die zeitgemäße Methoden erfolgreich anwenden. Und noch ein paar Dinge, bei denen die Softwareentwicklung weitaus rückständiger ist: Wie definiert man denn in den heute gebräuchlichen Programmiersprachen Randbedingungen, deren Einhaltung schon zur Entwicklungszeit, d.h. beim Tippen und allerspätestens beim Kompilieren überprüft wird? Ich denke hierbei an Randbedingungen wie "Der Inhalt von Variable x muss immer um mindestens 2 kleiner sein als der von y." oder "Parameter x darf im Bereich von 1 bis 10 liegen." Das ganze zur Laufzeit per Assertion zu erledigen ist hierbei nicht ausreichend. Das Äquivalent bei modernen EDA-Systemen wäre die Design Rules, z.B. für Leiterbahnabstände oder -breiten und noch viele andere automatisch überprüfbaren Dinge.
:
Bearbeitet durch User
Falls es interessiert: Im PC habe ich jährliche Projektordner mit fortlaufenden Nummern. Jedes potentielle Projekt bekommt eine Nummer. Es macht nichts ob das Projekt durch gezogen wird oder nicht. Das erste Projekt für 2016 wäre dann eine fünfstellige Nummer: "16001" z.B. Jedes Projekt hat bei mir dieselbe grundsätzliche Datei Struktur: Projects ... 2015 2016 16001_Projectname Electrical_Design - Simulation - Dokumentation - datasheets - Testdata Special_Software_Tools PCB_Design Mechanical_Design - Frontpanel - Enclosure ... Reference Documentation - User_Manual Images Firmware* ( Nur fertige FW) - Release - Binaries - Tools ( All software, drivers to build firmware ) Software* Manufacturing (Pcb Hersteller ) [End] 16002_Next 16003_Next ... 2017 ... *) Mit CVS für Projekt Dateien Das habe ich als leeres Template im PC, so dass jedes Projekt gleich anfängt. Auf einem Spreadsheet habe ich ein dann noch ein Verwaltungs Projektverzeichnis mit allen Zeichnungs und PCB Nummern. In speziellen Fällen halte ich auch noch einen Ordner mit Printouts der Platinen und Schaltbilder, Notizen welche beim Bau der Hardware praktischer sind als ein PC Monitor. Für meine Hobbyprojekte reicht es allemal aus. Falls spezielle zusätzliche Ordnerstrukturen notwendig sind lassen sie sich je nach Bedarf natürlich hinzufügen. Grüße, Gerhard
nfet schrieb: > Ich finde, derzeit wird Hardwareentwurf noch betrieben, wie > Softwareentwurf vor 20 Jahren. Also magst du Hardware lieber mit den Methoden von heute wie SCRUMM entwickeln? Also keinen Plan wohin die Reise geht aber den Kunden regelmäßig ne andere Ecke vom PCB vorstellen und die Spec. dan "anpassen"? Ich glaube den beim Flughafen hat man zuletzt versucht "Hardware" auf Software-weise zu entwickeln. Versionsverwaltung etc. gibt es natürlich länger als es RCS-tools und Co gibt. Nennt man Änderungsdienst, Freigabeprozess etc.. Dazu braucht es keine Software/Computer-tools. Nur Mitdenken und Kommunikation mit den richtigen Leuten. Das ist in der Software auch nicht anders, Tools sind Hilfsmittel, der Grips im Schädel macht den Unterschied.
nfet schrieb: > Heyho, > > ich wollte gerne mal eure Erfahrungen den professionellen > Hardwareentwurf betreffend hören. > Ich finde, derzeit wird Hardwareentwurf noch betrieben, wie > Softwareentwurf vor 20 Jahren. > > Die Dokumentation ist meistens eher nicht vorhanden, weil man hat das ja > selbst designed und weiß daher, wie es funktioniert (Analogie: keine > Kommentare im Code). Soso... Ist das so... Ich arbeite so: Start ist ein Blockschaltbild, das wird immer weiter verfeinert. Wenn es vollständig ist, wir es vom Projektmanager abgesegnet. Ich erkläre es ihm dazu in Form einer Präsentation oder so am PC. Zu diesem Zeitpunkt gibt es bereits eine Doku, welche die Blöcke grob beschreibt (aber nur grob, was sie tun, denn mehr will der Projektmanager sowieso nie wissen). Fallweise habe ich dann sogar schon Schaltungen aufgebaut - man sollte schon sicher sein, dass das realsierbar ist. Das ist quasi das Pflichtenheft, welches ich nie bekomme. Bei uns bekommt man Schmierzettel, Flipchart-Papier, oder inkohärentes Gebrabbel als Anforderung. Je nach Projektmanager. Dann erst wird implementiert. Und bevor ich den Schaltplan zeichne, gibt es bereits eine Beschreibung für jeden Block in der Doku. Inklusive Berechnung bzw. Messprotokoll der fallweise aufgebauten Prototypen. Das ist es, was sich nach ungefähr 50 Platinen als die beste Herangehensweise (für mich) herausgestellt hat. Wenn die Platine im Haus ist, geht dadurch die Inbetriebnahme recht schnell. Sollwerte für alles steht in der Doku. Alle Messungen werden dokumentiert. Das spart bei der Fehlersuche später die Zeit mehrfach rein. Mit jeder Entwicklung geht es schneller. Man hat irgendwann für jeden Standardkram eine fertige Berechnung / Doku zur Hand. Wer einmal eine richtig komplexe Platine mit z.B. 15 Din-A-1 Schaltplanseiten und >1000 Bauteilen gemacht hat, wird feststellen, dass es gar nicht mehr anders geht. Sowas wie "den Überblick haben" gibts da sowiso nicht mehr. Wer da wild drauflosfrickelt, wird scheitern. PS: Wer Angst hat, sich dadurch austauschbar zu machen, den kann ich beruhigen. Keiner außer einem anderen Hardwareentwickler wird es sich antun, die Berechnungen nachzuprüfen. Eine Forme, und es wird auf das X geklickt. Wer (wie ich) etwas Übung in Reverse engeneering hat (in unserer Firma zwingend...) kann sowieso alles auch dem Schaltplan entnehmen. Dauert halt länger. --> Man macht sich durch Dokumentation nicht entbehrlich.
Achim schrieb: > Schaltpläne enthalten viel weniger Informationen als Software. Darum > kann sie meist gut graphisch ausreichend dargestellt werden. > Das reicht dann meistens. Leider ist ein diff so deutlich schwieriger. Eigentlich nicht, um den Unterschied zwischen zwei Plänen zu finden, legt man sie übereinander und hält sie gegen das Licht... Solche jahrtausendalte Kulturtechniken scheinen Computerkiddies komplett unbekannt. Und wer es moderner mag ninnt eine Bildbearbeitung wie Gimp und legt die verschiedenen Versionen auf verschiedenen Layer und lässt sich aus diesen ein Diff berechnen. Aber eigentlich genügt ein Blick in die Arbeitsdokumenttaion/Fertigungsunterlagen, da steht welche Fehler gefunden worden in welchem Musterstand die Änderungen durch welchen Zeichner eingeflossen sind und bei welchen Review die Änderung freigegeben wurde. Das lernt man wenn man bei einem alten Hasen in die Lehre geht.
nfet schrieb: > Ist das bei euch ähnlich? Macht ihr manche Dinge besser? Fällt das nur > mir auf? Das sollte genug Stoff für eine hoffentlich ergiebige > Diskussion liefern. Ich bedanke mich schon einmal bei allen Teilnehmern. Bei einfachen Projekten reicht ein Schnellhefter mit der Schmierzettelsammlung. Zudem muss man nicht jeden Mückenschiss dokumentieren, dokumentiert wird nur was nicht dem Schaltplan entnehmbar ist. Oder wenn ich die Auswahl eines ganz bestimmten Bauteils (nein, das 0,1€ billigere passt hier wirklich nicht...) begründen muss. Wichtige Berechnungen gehören auch in den Schnellhefter. Möglicherweise auch eine Kopie wichtiger Fachartikel, sofern zum Verständniss erforderlich. Dass man die Bauelemente im Schaltplan sinnvoll anordnet, sollte aber selbstverständlich sein. Zudem kann man von jedem, der so eine Dokumentation lesen will/muss erwarten, dass er Schaltpläne und Datenblätter lesen kann.
Berufsrevolutionär schrieb: > Aber eigentlich genügt ein Blick in die > Arbeitsdokumenttaion/Fertigungsunterlagen, da steht welche Fehler > gefunden worden in welchem Musterstand die Änderungen durch welchen > Zeichner eingeflossen sind und bei welchen Review die Änderung > freigegeben wurde. Das lernt man wenn man bei einem alten Hasen in die > Lehre geht. Stücklisten+Beyond compare und man hat das sofort. Oder pdf-reader und Alt+Tab oder so hin und herschalten. Im Gegensatz zum Papier kann man da auch zoomen. Das ist bei mir hier schneller, als der Weg zum Drucker. Der ist weit weg. Brauchen tut man all das aber nur, wenn der Entwickler nicht dokumentiert hat. Sonst reichet ein Blick in die Doku, Abschnitt Historie -> fertig. Dazu stehen da die Gründe drin, warum man das geändert hatte...
Die Standards gibt es schon, zum Beispiel auf xml basierend, nur haelt sich niemand dran. Eigentlich muessten die Entwickler sich weigern, ein Tool oder eine Komponente zu verwenden, das die Standards nicht unterstuetzt. Andreas
Noch was Generelles zum Thema Versionen (heißt bei mir Ausgabestand und wird u.a. im entsprechenden Feld des Zeichnungskopfes vermerkt): im Gegensatz zu endlosen SW-Versionen, an denen der Softwerker immer weiter vor sich hinfrickeln kann, muss der Hardwariker irgendwann einmal zu Potte kommen, d.h. er muss aus seinem Stromlauf irgendwann eine Leiterplatte und dann eine Baugruppe machen. Soll heißen, wenn die Gerber- und Excellonfiles zum Leiterplattenhersteller geschickt wurden, ist Schluss mit Schaltungsänderungen und sonstigen Späßchen, dann ist erst einmal Friedhofsstille auf dem Zeichenbrett. Erst wenn die Lp wieder da ist, aufgebaut wurde und trotz allem alles ordnungsgemäß nach Pfh funktioniert, darf oder muss über die endgültige Version nachgedacht werden. Im großen und ganzen sollten einfache Dinge (z.B. Baugruppe Europakarte mit 500 BE, Vierlagen) beim ersten Schuss sitzen. Bei jeder Version sind nämlich schnell mal ein paar Tausender in den Sand gesetzt. Im Konzern stört es dich nicht, aber in der eigenen Firma kann es richtig weh tun. Die Entwicklungsdisziplin muss im HW-Entwurf also viel höher sein, als bei der Software, wo man schnell noch die Akustikfunktion im Motorsteuergerät ändern kann. Es gibt also nur ein, zwei oder allerhöchstens drei Ausgabestände.
Bürovorsteher schrieb: > Es gibt also nur ein, zwei oder allerhöchstens drei Ausgabestände. ...wird aber bei älteren Produkten immer mehr, wegen Lieferschwierigkeiten bei Bauteilen und anderen "tollen" Überraschungen. Bürovorsteher schrieb: > Im großen und ganzen sollten einfache Dinge (z.B. Baugruppe Europakarte > mit 500 BE, Vierlagen) beim ersten Schuss sitzen. Erster Schuss ist sportlich, da muss man doch meist zu Fädeldraht oder Lötkolben greifen (irgendwo ist immer ein Fehler) aber der zweite sitzt normalerweise. Bei Hardwareproblemen gibts immer noch die Frage: "can you fix it in software?!" Das Firmwareupdate kann man im Zweifelsfall auch "irgendwann später" ausliefern, die Hardware ändert sich dagegen nicht mehr, wenn sie einmal beim Kunden steht. Übrigens auch im Automobilbereich, unkritische Softwareupdates werden vom Vertragshändler diskret bei der nächsten Inspektion installiert. Dementsprechend sollte man nich alle Wartungen bei ATU erledigen lassen, sondern gelegentlich zum Ölwechsel in die Vertragswerkstatt fahren. Dementsprechend gibt es viel mehr Softwareversionen wie Hardwareversionen
Bürovorsteher schrieb: > Im großen und ganzen sollten einfache Dinge (z.B. Baugruppe Europakarte > mit 500 BE, Vierlagen) beim ersten Schuss sitzen. Eher nicht. Ich habe schon Platinen dieser Kategorie auf Anhieb (naja...) hingebracht, d.h. ohne Layoutänderung, aber die Regel ist es nicht. Es kommt auch drauf an, wie genau man die Inbetriebnahme macht. Viele kleinere Fehler fallen so erst mal gar nicht auf, oder wirken sihc nur minimal aus. Wenn man nicht genau schaut, wird man sie auch nicht finden. Wieviele man davon ausgemerzt hat (alle findet man sowieso nie), zeigt sich erst viel später in der Zuverlässigkeit der Platine und im Yield. Es ist immer interessant, nach ein paar Jahren in die Produktionsstatistik zu schauen. Man sieht schnell, wie sauber der Entwickler gearbeitet hat...
> Es kommt auch drauf an, wie genau man die Inbetriebnahme macht. Viele > kleinere Fehler fallen so erst mal gar nicht auf, oder wirken sihc nur > minimal aus. Eine Baugruppe, die etwas komplexer ist und auf Anhieb zu funktionieren scheint, sollte äußerst kritisch betrachtet werden J.
nfet schrieb: > Die Dokumentation ist meistens eher nicht vorhanden, weil man hat das ja > selbst designed und weiß daher, wie es funktioniert (Analogie: keine > Kommentare im Code). Wird von Entwicklungsdienstleister geliefert, die haben dann einfach die Kommentare ausgeblendet! Ziel ist das Wettbewerber es nicht ganz so einfach haben auf den Grundlagen wieder was zu bauen. > Zugegebenermaßen, machen es einen die meisten CAD Tools auch nicht > gerade leicht Kommentare in den Schaltplan einzubringen. Wozu kommentieren? Zeichnungen sollten so eindeutig sein, dass Fachleute sie verstehen. Das irgendwelche Dr. Dr. Dr. mecker, ist wohlbekannt. Nur sind die halt auch keie Fachleute! > Dann werden die Schaltpläne meist auch noch mit Bezug zu Papierblättern > entworfen, etc. etc. Zwar nicht übersichtlich, aber die komponentenbezogene Doku war`s auch nicht. > Man merkt eben, das wurde früher alles von Hand gemalt und man hat es > einfach 1:1 übernommen. Bei BMW haben sie noch in den Jahren 2007 mit Coral Draw die Bordnetze-DOKU erstellt!
Andreas schrieb: > Die Standards gibt es schon, zum Beispiel auf xml basierend, > nur haelt sich niemand dran. Die Datenmodelle unterscheiden sich zwischen den verschiedenen EDA-Systemen so stark voneinander, dass deren verlustfreie Abbildung nicht möglich oder nicht sinnvoll ist. Die Verwendung XML-basierter Dateiformate ermöglicht dabei immer noch keinen sinnvollen Vergleich. Die Praxis vieler Programme (egal ob EDA oder für andere Zwecke) zeigt, dass die Anordnung der einzelnen Datensätze auch in Klartextformaten wie z.B. XML sehr stark variieren kann, und zwar auch schon bei trivialen Änderungen der dadurch beschriebenen Daten. Dadurch ist es manchmal nur aufwändig möglich, anhand von Dateiunterschieden auf die wirklichen inhaltlichen Unterschiede zu schließen. Altium Designer verwendet für manche Dateitypen Klartextdateien (DsnWrk, PrjPcb, Harness, DRC) und für andere (SchDoc, PcbDoc) Binärformate, wobei man aber auch SchDoc und PcbDoc explizit im ASCII-Format abspeichern kann. Mir ist aber nicht bekannt, ob dieses ASCII-Format wirklich alle Merkmale auch aktueller AD-Versionen unterstützt. > Eigentlich muessten die Entwickler sich weigern, ein Tool oder eine > Komponente zu verwenden, das die Standards nicht unterstuetzt. Eigentlich müssten sich alle Menschen für den Weltfrieden einsetzen. Wenn sich ein Entwickler weigert, ein vorgegebenes Werkzeug, das für den Zweck vollauf geeignet ist, einzusetzen, ohne dass hierdurch Rechtsverstöße begangen werden, handelt es sich um Arbeitsverweigerung, die zur Abmahnung und Kündigung führen kann.
Andreas schrieb: > Die Standards gibt es schon, zum Beispiel auf xml basierend, > nur haelt sich niemand dran. > Eigentlich muessten die Entwickler sich weigern, ein Tool oder eine > Komponente zu verwenden, das die Standards nicht unterstuetzt. Man muss nicht jeder Verirrung irgendwelcher Sesselfurzer hinterherlaufen, weil man genau so wenig Ahnung von der Praxis hat wie diese "Standardsetzer". Etwas als XML zu speichern ist gleichbedeutend mit verschlüsseln und löschen. Die Werbeaussage XML wäre so toll weil jetzt egal welcher inhalt es mit jedem xml Programm gelesen werden kann, ist hanebüchener Unfug gewesen. Jede Textdatei wäre besser. Standards zur Dokumentation gibt es, z.B. bei der Dokumentation zu CE, und dort steht nichts über XML. Aber diese CE-Doku ist bloss ein Teil des Gesamtdoku zu einem Projekt. Das Problem an der Doku: Zu 99% braucht man sie nie wieder. Als darf es keine Arbeit machen, sie zu erstellen. Also ist eine einfache Sammlung von allen Informationen, die man im Laufe des Projekts hatte, in der Form in der sie anfielen, die angemessene Form. Und PDF bleibt dabei PDF, Schaltplan bleibt SCH und Platinenlayout BRD (je nach programm), da wird nichts in XML verwandelt und damit unlesbar gemacht. Und die Programme, die man verwendet hat, sollte man als Installsatz auch speichern, denn wer weiss schon, ob dann, wenn man das Projekt wieder anfassen muss, noch der Rechner mit dem Programm existiert. Damit ist auch das Dateiformat immer lesbar. Immer wenn einer mit XML kommt weiss man: A fool with a tool is still a fool.
Michael B. schrieb: > Etwas als XML zu speichern ist gleichbedeutend mit verschlüsseln und > löschen. Die Werbeaussage XML wäre so toll weil jetzt egal welcher > inhalt es mit jedem xml Programm gelesen werden kann, ist hanebüchener > Unfug gewesen. Jede Textdatei wäre besser. Immer wenn einer mit so einer Aussage daherkommt, weiß man, es handelt sich um einen laberkopp
Achim schrieb: > Schaltpläne enthalten viel weniger Informationen als Software. Darum > kann sie meist gut graphisch ausreichend dargestellt werden. > Das reicht dann meistens. Leider ist ein diff so deutlich schwieriger. Darum lieben EEs LabView: weil es soo schön GUI ist und Quellcode ist bäh. Aber diffs bei der Versionierung... ?!? Pläne übereinander gege Licht halten? Und bei ordentlichem Refactoring (logischer, sinnvoller aufteilten z.B. auf mehr Blätter), wie finde ich da die funktionsgleichen Teile wieder? Es gibt ja CAEs/EDAs mit Bibliothekskonzepte (auch für Teilschaltungen inkl. SECs) aber man muss sie halt nutzen... a Tool with a tool is still a fool Prozesse u. Abläufe machen das Spiel. Werkzeuge sind nicht unwichtig, jedoch alleine nicht ausreichend. Geht in Richtung Firmen- u. Arbeitskultur; wenn es daran fehlt, weil (per Chefs Order) Abkürzungen begangen werden... tja... Warum darf ein Schema einfach so abgelegt/produziert/archiviert werden, ohne dass darin oder in einem begleitenden Dokument die ach so vermissten Kommentare/Entscheidungen/Berechnungen auch da sind? Da ist nicht die "Schuld" beim CAE Tool zu suchen... - - - Ausserdem: ich wäre froh, wenn in der SW mehr wie in der Mechanik geprüft würde - Eignungsabklärung vor der Anschaffung von SW-Tools/-libs/-Frameworks, verbindliche Reaktionszeiten Seitens Lieferanten f. Fehlerbehebung (Funktionsmängel, Sicherheitslücken, usw.), rigoroses Einhalten von öffentlichen Standards (Datenaustauschformate?) - hier ist die SW-branche definitiv NICHT im Vorsprung! Anregung zum Nachdenken: Fahrzeuge dürfen nur amtlich Zugelassen operieren, Personen nur mit amtlichem Führerschein fahren. SW? - Wildwest!!! Ich denke da an z.b. ERP und BusinessIntelligence Tools, mit denen letztlich über die Existenz eines Betriebes bestimmt wird, inkl. der Existenz der Belegschaft. (ja, der Kreis wird groooss...)
Tach, ja, die bekannte Problematik...und täglich grüsst das Murmeltier. Ich machs kurz: - Kicad kann gut mit git/svn und dank der hierarchischen Struktur lassen sich Unterschemas gut wiederwerverten, wenn man die Annotation gleich von vornherein entsprechend plant - Die angesprochenen XML-Standards funktionieren bei uns sehr gut, angefangen bei der Gerätebeschreibung, am Schluss wird Docbook XML für die technische Doku verwendet. Das nehmen auch einige Verlage so an. Eigentlich lassen sich alle Probleme von Formaten und Versionsverwaltung mit ein paar einfachen Basics und etwas Fähigkeit im Schreiben von Scripten oder Stylesheets lösen. Genau an dem Punkt ist man teils mit OpenSource recht produktiv. Wo ist das Problem?
D. I. schrieb: > Immer wenn einer mit so einer Aussage daherkommt, weiß man, es handelt > sich um einen laberkopp Immer wenn jemand in einem Beitrag auf den Namen eines Diskutanden Bezug nimmt, weiss man, es handelt sich um einen Idioten ohne Argumente.
Michael B. schrieb: > Immer wenn jemand in einem Beitrag auf den Namen eines Diskutanden Bezug > nimmt, weiss man, es handelt sich um einen Idioten ohne Argumente. Stimmt, die habe ich bei dir vergeblich gesucht um darauf eingehen zu können. Das einzige was ich rauslesen konnte ist, dass du offensichtlich nicht weißt, wann und wie man XML (heutzutage auch gerne JSON) richtig einsetzen kann, um sowohl Datendarstellung als auch Datenaustausch/-konvertierung zu erreichen. Und da wären wir wieder bei "A fool with a tool is still a fool". Ich hoffe doch, dass du mir wenigstens in dem Punkt zustimmst, dass Textformate einfacher zu prozessieren sind als Binärformate. Nur weil eine Technik vergewaltigt, missbraucht oder anderweitig schief von irgendwelchen Predigern verwendet wird, heißt das nicht, dass die Technik schlecht wäre oder es keine sinnvollen Anwendungen dafür gäbe.
Michael B. schrieb: > Etwas als XML zu speichern ist gleichbedeutend mit verschlüsseln und > löschen. Die Werbeaussage XML wäre so toll weil jetzt egal welcher > inhalt es mit jedem xml Programm gelesen werden kann, ist hanebüchener > Unfug gewesen. Jede Textdatei wäre besser. XML-Dateien sind Textdateien. Das ist ja gerade das Schöne an dem Format. > da wird nichts in XML verwandelt und damit unlesbar gemacht. Was soll an XML unlesbar sein?
D. I. schrieb: > Nur weil eine Technik vergewaltigt, > missbraucht oder anderweitig schief von irgendwelchen Predigern > verwendet wird, heißt das nicht, dass die Technik schlecht wäre oder es > keine sinnvollen Anwendungen dafür gäbe Du musst DDR Bürger sein. "Nur weil die Umsetzung mies war heisst das nicht daß der Sozialismus eine schlechte Idee wäre." An dich als XML Fanboy hätte ich nur eine Frage: Mit welchen Bytes (das erste Tag) beginnt eine normkonforme XML-Datei, die im EBCDIC Zeichensatz (welche sich in der offiziellen Liste der in XML erlaubten Zeichensätze befindet http://www.iana.org/assignments/character-sets/character-sets.xhtml ) formuliert ist.
:
Bearbeitet durch User
Mark B. schrieb: > Was soll an XML unlesbar sein? Der INHALT. XML ist die textuelle Entsprechung des Wimmelbild-Adventures. Jeder normale Ingenieur kann einen ordentlich gemachten Stromlaufplan weitaus besser lesen als jedes XML. Aber kannst DU (jaja du selbst) durch Draufschauen auf den Wortschwall-Wust bei XML irgend etwas von dessen Inhalt un Sinn erkennen? Nein, natürlich nicht. Sowas könnte eine Maschine (sprich ein Programm) - ja wenn dieses Programm denn menschliche Intelligenz hätte. Ist aber nicht. Also nochmal: Wenn ihr hier das Hardware-Entwickeln schon soweit reduziert, daß ihr euch nur auf das Zusammenkriegen irgendwelcher Leiterplatten beschränkt: Ein gut gezeichneter Stromlaufplan ist sowohl Arbeitsmittel zum Layouten als auch Dokumentation - und in ausgedruckter Form auch als direkter Vertragsbestandteil geeignet. Das ist ein Wert, der hier bei allem Geschwätz sträflichst vernachlässigt wurde. Das Gleiche gilt für alle anderen technischen Zeichnungen. Man mag ja zum Finden einer Konstruktion ein beliebiges System benutzen und dessen Daten den Zulieferern zur Verfügung stellen, aber als Interface zum Zulieferer bedingt unsereiner sich grundsätzlich aus, daß in jedem Zweifelsfalle die gedruckte Zeichnung gilt. Basta. Die kann nämlich jeder angucken - selbst der Patentanwalt. Bei allem anderen Zeugs in maschinenlesbarer Form (ob nun XLM oder sonst was) ist das nicht so. Kurzum: dies hier ist wieder mal ein echtes Freitagsthema. W.S.
Die rege Beteiligung freut mich und noch mehr freut mich, dass es bei vielen besser zu laufen scheint. Interessant fand ich den Punkt mit den Prozessen in der Entwicklung. Ich glaube, da sind Softwerker einfach offener für neues, da diese tatsächlich öfter Änderungen an ihrem Produkt machen können. BTW schade, aber durchaus verständlich finde ich, dass die Ansätze zur Verifikation durch Simulation direkt im Schaltplan gescheitert sind. Glaubt ihr, in dem Bereich wird es Fortschritte in der Zukunft geben?
Michael B. schrieb: > An dich als XML Fanboy hätte ich nur eine Frage: Mit welchen Bytes (das > erste Tag) beginnt eine normkonforme XML-Datei, die im EBCDIC > Zeichensatz (welche sich in der offiziellen Liste der in XML erlaubten > Zeichensätze befindet > http://www.iana.org/assignments/character-sets/character-sets.xhtml ) > formuliert ist. Kann ich dir nicht aus dem Kopf sagen, da ich mit solchen Exoten von Zeichensätzen nichts zu tun habe. 99% meiner XML-Anwendungsfälle wird mit UTF-8 abgewickelt. Weiß auch nicht was diese Frage soll oder worauf sie abzielt. W.S. schrieb: > Der INHALT. > > XML ist die textuelle Entsprechung des Wimmelbild-Adventures. > > Jeder normale Ingenieur kann einen ordentlich gemachten Stromlaufplan > weitaus besser lesen als jedes XML. Oh man, darum gehts auch nicht, ...
W.S. schrieb: > Aber kannst DU (jaja du selbst) durch Draufschauen auf den > Wortschwall-Wust bei XML irgend etwas von dessen _Inhalt un Sinn_ > erkennen? Nein, natürlich nicht. Sowas könnte eine Maschine (sprich ein > Programm) - ja wenn dieses Programm denn menschliche Intelligenz hätte. > Ist aber nicht. Dasjenige Programm, welches die XML-Datei erzeugt hat, kann diese in der Regel auch einlesen und "verstehen". Wäre sonst ja 'n bisschen komisch, meinst Du nicht? Der Vorteil von XML ist, dass man mit den Informationen auch dann noch etwas anfangen kann, wenn man das Originalprogramm eben nicht mehr hat oder keinen Rechner mehr hat, auf dem das originale Tool noch läuft. Einfach weil man die Datei mit jedem beliebigen Texteditor öffnen und anschauen kann.
:
Bearbeitet durch User
nfet schrieb: > Interessant fand ich den Punkt mit den Prozessen in der Entwicklung. > Ich glaube, da sind Softwerker einfach offener für neues, da diese > tatsächlich öfter Änderungen an ihrem Produkt machen können. Ich vermute mal, dass Du ein reiner Softwerker mit nur einem sehr oberflächlichen Verständnis von Hardwareentwicklung bist und nun auf Teufel heraus versuchst, uns und vor allem Dir selbst einzureden, warum das viel besser sei. Der große Unterschied zwischen diesen Welten besteht nun einmal darin, dass man bei der Hardwareentwicklung wesentlich sorgfältiger arbeiten muss, weil man eben nicht die Möglichkeit hat, billige weitere Durchläufe zu machen. Daraus auf Persönlichkeitsmerkmale der Entwickler zu schließen ist schon etwas vermessen. Bei der Softwareentwicklung für Produkte, bei denen man nicht eben mal schnell ein kleines Online-Update nachschieben kann, muss man mit schon mit einem ähnlichen Qualitätsanspruch herangehen wie bei der Hardwareentwicklung oder gar dem Chip- oder ASIC-Design. Dass aber manche Leute oder Organisationen solche Qualitätserfordernisse nur vorschieben, um einen möglichst aufwändigen bürokratischen Prozess zu betreiben, steht auf einem ganz anderen Blatt. Und da es Elektronikentwicklung wesentlich länger gibt als (Embedded-)Softwareentwickler, konnten sich dementsprechend auch mehr unflexible Konzernbeamte und ähnliche Bürokraten dort einnisten. > BTW schade, aber durchaus verständlich finde ich, dass die Ansätze zur > Verifikation durch Simulation direkt im Schaltplan gescheitert sind. Wieso sollte das gescheitert sein? Im Altium Designer kann man Schaltplanseiten direkt für die Simulation verwenden. Allerdings ist es durchaus sinnvoll, nicht die gesamte Schaltung, wie sie auf die Leiterplatte gepackt werden soll, am Stück zu simulieren, sondern sich auf die wirklich wichtigen Aspekte zu konzentrieren. Und z.B. für die Berechnung von Schaltreglern o.ä. gibt es Plugins wie z.B. TI Webench. > Glaubt ihr, in dem Bereich wird es Fortschritte in der Zukunft geben? Wie ich schon zuvor erwähnt habe, bist offenbar DU derjenige, der sich konsequent weigert, sich mit dem aktuellen Stand der Technik im Bereich EDA bzw. Hardwareentwicklung zu beschäftigen. Vermutlich liegt das an einer unzureichenden Offenheit gegenüber Neuerungen.
Mark B. schrieb: > Einfach weil man die Datei mit jedem beliebigen Texteditor öffnen und > anschauen kann. Oder eben auch mit speziellen XML-Editoren wie z.B. aus den Altova XML Tools , mit denen man auch formale Prüfungen auf Einhaltung des XML-Standards durchführen kann. Außerdem bietet solche Editoren auch noch Unmengen an Funktionen zur Darstellung der XML-Daten, zum Sortieren, usw.. https://www.altova.com/xml_tools.html Eine Stromlaufplan- oder Leiterplattendarstellung wird man da aber sicherlich kaum finden.
nfet schrieb: > Interessant fand ich den Punkt mit den Prozessen in der Entwicklung. > Ich glaube, da sind Softwerker einfach offener für neues, da diese > tatsächlich öfter Änderungen an ihrem Produkt machen können. TREFFER!!! Wenn ich Hardware entwickel, dann muss die einfach laufen. Wenn die Hardware beim Kunden steht, dann ändert die sich nicht mehr und hat auch noch in 20 Jahren unverändert und fehlerfrei zu laufen. Doch einen Fehler gemacht? Schlecht, ein Produktrückruf ist teuer und ruiniert den eigenen Ruf... Wenn ich Software entwickel und einen Fehler gemacht habe, kein Problem, so ein Firmwareupdate kostet mich ja fast nichts. Muss der Kunde halt eine Runde mit dem Laptop durch seine Firma drehen. Positiver Nebeneffekt: Kunde merkt, dass man sich um die Produktpflege kümmert. Software ist wie Bananen, beide kann man grün ausliefern und beim Kunden reifen lassen.
D. I. schrieb: > Weiß auch nicht was diese Frage soll oder worauf sie abzielt. Dachte ich mir, daß der XML Fanboy leider keine Ahnung von XML hat. Hättest du dich mit der Frage beschäftigt, hätte die Antwort wohl auch dein verschrobenes Weltbild über den Haufen geworfen. Andreas S. schrieb: >> Einfach weil man die Datei mit jedem beliebigen Texteditor öffnen und >> anschauen kann. Welchen Sinn soll das haben ?
Michael B. schrieb: > Dachte ich mir, daß der XML Fanboy leider keine Ahnung von XML hat. > Hättest du dich mit der Frage beschäftigt, hätte die Antwort wohl > auch dein verschrobenes Weltbild über den Haufen geworfen. Komm auf den Punkt, ich habe keine Zeit fürs unnötige Rätsel raten. XML erlaubt unterschiedliche charsets, soweit nichts Neues, das wusste ich auch vor deinem Einwand, und nu?
>>> Einfach weil man die Datei mit jedem beliebigen Texteditor öffnen und >>> anschauen kann. Michael B. schrieb: > Welchen Sinn soll das haben ? Man findet darin die ganzen ">" und "<" oder "/", die die Leute in ihren C-Quelltexten so oft vergessen. MfG Paul
D. I. schrieb: > und nu? Da du nicht denken willst oder kannst, mach ruhig weiter dein XML Fanboy Gehabe. https://www.youtube.com/watch?v=VRrMu7B1L2I
Andreas S. schrieb: > Gegenfrage: > Welche Programmiersprache oder IDE erlaubt es denn, neben einem > Syntaxhighlighting mit selbst definierten Textfarben zu arbeiten? Was bitte soll das denn bringen? Syntaxhighlighting ist sinnvoll, alles andere ist unlesbar für andere. > Bessere EDA-Systeme besitzen durchaus Anbindungen an externe > Versionskontrollsysteme wie z.B. Subversion und erlauben durchaus auch > aus dem Programm heraus, ältere Stände zu vergleichen usw.. Der Storage > Manager in Altium Designer führt sogar eine interne Versionierung von > Zwischenständen durch die mittels "Save" bzw. Strg-S gespeichert werden. What?! Ernsthaft? Also eine schlechtere Anbindung an ein VCS als in Altium hab ich noch nie gesehen. Wenn man sein Projekt kompiliert (was auch schon mehr als grenzwertig ist...), ändert sich in der Projektdatei irgendetwas mit den eingerichteten Druckern am Rechner, wenn der letzte Commit auf einem anderen Rechner war. Sonst ändert sich in dieser Datei nichts. Permanent wird hier also etwas geändert, was überhaupt nicht geändert gehört und diffs unmöglich macht. Des weiteren sind Binärdateien im VCS immer scheiße. Normales diffen geht nicht mehr, also ist man auf Altium angewiesen. Und dieses diffen ist sowas von schlecht, man kann nichtmal übersichtlich sehen welches Bauteil dazu kam, und wo der Pin umbenannt wurde. > Welche in der Softwareentwicklung genutzte IDE bietet denn solch einen > Komfort bei der Versionsverwaltung? Jeder Editor, bsp Emacs, bietet wesentlich besseren VCS-Komfort, weil es sich darin um keine Binärdateien handelt, die im VCS nicht verloren haben. Wie schafft es Kicad denn, keine Binärkacke in ihren Files zu haben und trotzdem am CERN eingesetzt zu werden, obwohl doch "moderne Profis" sich über den Schrott in Altium freuen sollen?! > Ganz einfach: Du bist derjenige, der in Sachen Hardwareentwicklung nicht > auf der Höhe der Zeit ist, sondern die erwähnten zwanzig Jahre > hinterherhinkt. Daher solltest Du Deine diesbezüglichen Defizite nicht > auf Dritte projizieren, die zeitgemäße Methoden erfolgreich anwenden. Ich glaube eher du hängst hier ein wenig hinterher, weil du nicht weißt, was für ein Segen ein sinnvolles Versioning ist (sprich Textdateien). Und wo ist das Github der EEs?! Wo ist das pip/npm der EEs?! TL;DR Ja, definitv sind die Softwerker wesentlich weiter, was die angesprochenen Dinge angeht. Ich sehe es auch so wie der TO.
Schreiber schrieb: > nfet schrieb: >> Interessant fand ich den Punkt mit den Prozessen in der Entwicklung. >> Ich glaube, da sind Softwerker einfach offener für neues, da diese >> tatsächlich öfter Änderungen an ihrem Produkt machen können. > > TREFFER!!! > > Wenn ich Hardware entwickel, dann muss die einfach laufen. Wenn die > Hardware beim Kunden steht, dann ändert die sich nicht mehr und hat auch > noch in 20 Jahren unverändert und fehlerfrei zu laufen. Es gibt definitiv Fälle, in denen die Hardware im Lauf der Zeit geändert wird. Zum Beispiel bei Schiffen, Flugzeugen und bei der Eisenbahn kann es sehr wohl sein, dass ein neues Gerät nachträglich eingebaut wird: Ein neues Radar etwa, oder eine andere Zugsicherung etc. Da wird dann auch schon mal der Stromlaufplan nachträglich geändert, neue Strippen werden gezogen und dergleichen.
:
Bearbeitet durch User
Andreas S. schrieb: > Der große Unterschied zwischen diesen Welten besteht nun einmal darin, > dass man bei der Hardwareentwicklung wesentlich sorgfältiger arbeiten > muss, weil man eben nicht die Möglichkeit hat, billige weitere > Durchläufe zu machen. Diese Möglichkeit hat man auch in der Software nicht immer: Nämlich spätestens dann, wenn man ein kompliziertes Verfahren durchlaufen muss, damit die Software überhaupt erst für den Betrieb zugelassen wird. Flugzeuge, Eisenbahnen und Automobile lassen grüßen.
Michael B. schrieb: > D. I. schrieb: >> Weiß auch nicht was diese Frage soll oder worauf sie abzielt. > > Dachte ich mir, daß der XML Fanboy leider keine Ahnung von XML hat. > Hättest du dich mit der Frage beschäftigt, hätte die Antwort wohl > auch dein verschrobenes Weltbild über den Haufen geworfen. > > Andreas S. schrieb: >>> Einfach weil man die Datei mit jedem beliebigen Texteditor öffnen und >>> anschauen kann. > > Welchen Sinn soll das haben ? Erstens mal hast Du falsch zitiert. Zweitens habe ich eine Begründung weiter oben schon genannt. Offensichtlich hast Du kein Interesse an einer ernsthaften und sinnvollen Diskussion. Dann lass es doch einfach bleiben.
Mark B. schrieb: > Es gibt definitiv Fälle, in denen die Hardware im Lauf der Zeit geändert > wird. Zum Beispiel bei Schiffen, Flugzeugen und bei der Eisenbahn kann > es sehr wohl sein, dass ein neues Gerät nachträglich eingebaut wird: Ein > neues Radar etwa, oder eine andere Zugsicherung etc. > > Da wird dann auch schon mal der Stromlaufplan nachträglich geändert, > neue Strippen werden gezogen und dergleichen. Ich bezog mich aber eher auf die einzelnen Geräte oder zumindest leicht wechselbare Baugruppen. So ein Schiff/Flugzeug ist im wesentlichen ein großes Metallteil, das mit tausenden, teilweise miteinander verbundenen, Einzelgeräten vollgestopft ist. Zudem werden diese Änderungen nicht "einfach so" vom Kunden durchgeführt, sondern erfordern einen erheblichen Zeit-, Sach- und Personalaufwand und umfassende Planung. Wenn ich einen Kunden auffordere eine neue Firmware zu installieren, dann macht der das ohne zu meckern. Bei neueren Geräten liefert man ein Firmwareupdate per Email, bei älteren per Post in Form eines EEPROMS. Wenn ich dagegen ein Tütchen mit Kleinteilen ausliefere und ihn auffordere zwei Kondensatoren und ein IC zu tauschen sowie noch zwei Leiterbahnen mit Skalpell und Fädeldraht zu ändern, dann wird er sich einen neuen Lieferanten suchen!
Mark B. schrieb: > Diese Möglichkeit hat man auch in der Software nicht immer: > Nämlich spätestens dann, wenn man ein kompliziertes Verfahren > durchlaufen muss, damit die Software überhaupt erst für den Betrieb > zugelassen wird. Flugzeuge, Eisenbahnen und Automobile lassen grüßen. Selbst für Flugzeuge gibts gelegentlich Softwareupdates. Teilweise sind die Updates sogar vorgeschrieben, entweder das Flugzeug bekommt eine neue Software oder es wird zu einem Bodenstehzeug. Wer genau das Update wie installieren kann und darf ist situationsabhängig. Hier gibt es alles von "Gerät ausbauen und einschicken" bis hin zu "Pilot mit einer SD-Karte". Letzteres ist dann fast wie ein Softwareupdate beim heimischen Fernseher... zu dem "can you fix it in Software" ein praktisches Beispiel: Beim Triebwerk NH90 wird/wurde der Anlasser (gleichzeitig auch Generator) per Softwareupdate der Triebwerkssteuerung mit einer zusätzlichen Funktion ausgestattet: Er kann die Turbinenwelle jetzt auch ganz langsam drehen, scherzhaft auch als Dönerspießmodus bezeichnet. Der Grund: Man hat bei der Entwicklung nicht berücksichtigt, dass sich Metall bei Erwärmung ausdehnt. Dementsprechend dehnt es sich bei ungleichmäßiger Erwärmung ungleichmäßig aus. Das Ergebniss war, dass sich das Triebwerksgehäuse nach dem Abschalten ungleichmäßig abgekühlt hat, wodurch es sich "bananenförmig" verbogen hat. Die Turbinenwelle hat sich gleichmäßig abgekühlt und ist dementsprechend gerade geblieben. Daher war es erforderlich nach dem abstllen des Triebwerks mehrere Stunden(!) zu warten, bis das gesamte Treibwerk gleichmäßig abgekühlt, und somit wieder gerade, war. Abhilfe soll der Dönerspießmodus bringen, die Turbinenwelle wird langsam gedreht und somit Umgebungsluft wie ein Ventilator durch das Triebwerk bläst. Das soll die gleichmäßige Abkühlung fördern..
Horst schrieb: > Was bitte soll das denn bringen? Syntaxhighlighting ist sinnvoll, alles > andere ist unlesbar für andere. Guckst Du hier (Tip 2: Add notes into your schematic) http://www.fedevel.com/welldoneblog/2016/07/7-tips-to-make-your-schematic-look-professional/ Eine konsistente(!) farbliche Kennzeichnung hilft ausgezeichnet bei der Dokumentation des Projektes. Auch in reinen Texten arbeitet man mit unterschiedlichen Schriftattributen. Problematisch kann es jedoch werden, wenn solche Attribute formale Auswirkungen auf das Verhalten eines Programms oder einer Schaltung bekommen sollten. > What?! Ernsthaft? Also eine schlechtere Anbindung an ein VCS als in > Altium hab ich noch nie gesehen. Dann hast Du noch keine EDA-Systeme gesehen, in denen gar keine VCS-Anbindung vorliegt. Das einzige, was ich bei Altium extrem ärgerlich finde, ist die feste Integration von CVS und Subversion, so dass es nicht möglich ist, auf beliebige VCS-Provider, z.B. für Git zurückzugreifen. Das (aus Sicht des Unternehmens Altium) einzig richtige VCS ist jedoch Altium Vault, welches intern aber auch größtenteils auf Subversion basiert. Da ich mit Altium Vault noch nicht gearbeitet habe, ist mir nicht bekannt, ob dort Inkonsistenzen auftreten. > Wenn man sein Projekt kompiliert (was > auch schon mehr als grenzwertig ist...), ändert sich in der Projektdatei > irgendetwas mit den eingerichteten Druckern am Rechner, wenn der letzte > Commit auf einem anderen Rechner war. Sonst ändert sich in dieser Datei > nichts. Das nervt in der Tat. Allerdings ist die PrjPcb-Datei im Klartextformat und lässt sich sehr gut vergleichen, erfüllt also eine wesentliche Anforderung. Zudem wird die Datei niemals überschrieben, es sei denn, dass man es mit "Save All" oder "Save Project" explizit veranlasst. Ebenso nervt es auch, dass die Information über den DRC-Status in der PcbDoc-Datei gespeichert wird und nicht nur in den ebenfalls generierten DRC- und HTML-Dateien. Da ich üblicherweise jeweils einen DRC unmittelbar vor der Erzeugung der Fertigungsdaten und einmal nach Erzeugung der Fertigungsdaten durchführe, kann ich auf Grund der veränderten PcbDoc nicht auf Anhieb sagen, ob sich womöglich eine versehentliche Änderung eingeschlichen hat. > Permanent wird hier also etwas geändert, was überhaupt nicht > geändert gehört und diffs unmöglich macht. Altium Designer ändert keine Projektdateien ohne vorheriges explizites Speichern. > Des weiteren sind Binärdateien im VCS immer scheiße. Normales diffen > geht nicht mehr, also ist man auf Altium angewiesen. Und dieses diffen > ist sowas von schlecht, man kann nichtmal übersichtlich sehen welches > Bauteil dazu kam, und wo der Pin umbenannt wurde. Textuelle Diffs von Klartextformaten besitzen bei grafischen Darstellungen auch nur eine sehr beschränkte Aussagekraft. Diffs auf z.B. Gerber- oder Bohrdateien schaue ich mir auch nur dann an, wenn ich minimale Änderungen vorgenommen habe und sicherstellen will, keine anderen Strukturen verschoben zu haben. Leider scheitert das (unabhängig vom eingesetzten EDA-System) auch dann, wenn dadurch gefüllte Flächen verändert werden. Dann müssen zwangsweise Unmengen von Vektoren verändert werden, obwohl man eigentlich nur ein einziges Via verschoben hat. Und wie schon erwähnt, kann man bei AD auch die Verwendung von Klartext-Projektdateien erzwingen. > Jeder Editor, bsp Emacs, bietet wesentlich besseren VCS-Komfort, weil es > sich darin um keine Binärdateien handelt, die im VCS nicht verloren > haben. Das ist entweder Unkenntnis, eine Lüge oder eine sonstige Verleugnung der Realität. Es gibt sehr viele IDEs, die mit binären Projektdateien arbeiten, was dort um einiges ärgerlicher ist. Nur weil Emacs und sehr viele IDEs glücklicherweise auf Binärdateien verzichten, ist eine Verallgemeinerung nicht zulässig. > Wie schafft es Kicad denn, keine Binärkacke in ihren Files zu haben und > trotzdem am CERN eingesetzt zu werden, obwohl doch "moderne Profis" sich > über den Schrott in Altium freuen sollen?! Ich vermute, dass am CERN auch noch Unmengen an anderer Software eingesetzt wird, die mit "Binärkacke" arbeitet. > Ich glaube eher du hängst hier ein wenig hinterher, weil du nicht weißt, > was für ein Segen ein sinnvolles Versioning ist (sprich Textdateien). Ich arbeite seit vielen Jahren mit unterschiedlichen Versionskontrollsystemen und kenne daher selbstverständlich deren Vor- und Nachteile sowie natürlich auch die Grenzen. Und da muss man eben auch zur Kenntnis nehmen, dass "textuell diffbare" Dateiformate in manchen Fällen eben nicht sinnvoll sind. Z.B. mögen bei einfachen Vektorgrafiken solche Formate noch sinnvoll sein, aber z.B. bei Fotos oder Videos sind sie es nicht mehr.
Mark B. schrieb: > Andreas S. schrieb: >> Der große Unterschied zwischen diesen Welten besteht nun einmal darin, >> dass man bei der Hardwareentwicklung wesentlich sorgfältiger arbeiten >> muss, weil man eben nicht die Möglichkeit hat, billige weitere >> Durchläufe zu machen. > > Diese Möglichkeit hat man auch in der Software nicht immer: > Nämlich spätestens dann, wenn man ein kompliziertes Verfahren > durchlaufen muss, damit die Software überhaupt erst für den Betrieb > zugelassen wird. Flugzeuge, Eisenbahnen und Automobile lassen grüßen. Du solltest mich nicht sinnentstellend unvollständig zitieren.
@Schreiber (Gast) >Beim Triebwerk NH90 wird/wurde der Anlasser (gleichzeitig auch >Generator) per Softwareupdate der Triebwerkssteuerung mit einer >Abhilfe soll der Dönerspießmodus bringen, die Turbinenwelle wird langsam >gedreht und somit Umgebungsluft wie ein Ventilator durch das Triebwerk >bläst. Das soll die gleichmäßige Abkühlung fördern.. Klarer Fall von vermurkstem Design. Aber der NH90 ist sowieso eine Lachnummer, ein "schönes" 100% Subventionsprojekt für die Industrie und es kommt wie so oft nur akademischer Spielkram raus. Da fragt man sich ernsthaft, wie die Leute vor 50 Jahren ohne CAD solide Triebwerke gebaut haben.
Andreas schrieb: > Die Standards gibt es schon, zum Beispiel auf xml basierend, > nur haelt sich niemand dran. Nein der Standard für menschenlesbare Netzlisten ist EDIF, das kann auch Altium: http://techdocs.altium.com/display/ADOH/Netlist+Outputs und xilinx und Altera und Mentor und und . EDIF entstand lange vor XML nämlich 1983 und ist inzwischen standardisiert (EN 61690-1, EN 61690-2). http://www.elgris.com/content/edif_overview.html Dort ein diff/parser drüber laufen lassen ist keine Hexerei, das sollte jeder XML-Tölpel können.
Falk B. schrieb: > Da fragt man sich > ernsthaft, wie die Leute vor 50 Jahren ohne CAD solide Triebwerke gebaut > haben. Ganz einfach, das waren noch richtige Handwerker die das Konstruieren mit Schweiss und Tränen am Schraubstock von der Picke auf gelernt haben. Der Softwerker verzieht keine Miene wenn er einen Fehler einbaut, gestestet wird das eh an einer anderen ecke der Welt und verwendet wieder wo anders. Von dem Ganzen Leid was die verbugte Software mit sich bringt, erfährt der Progger nichts, der sieht nur eine dünne Zeile Fehlerreport. Maschinenbauer wie Hans Joachim Pabst von Ohain dagegen war schon in der Gefahr von ihrenen eigenen Konstruktionen "gegrillt" zu werden und haben schon aus puren Überlebensinstinkt ihren Job mit Sorgfalt erledigt.
Falk B. schrieb: >>Abhilfe soll der Dönerspießmodus bringen, die Turbinenwelle wird langsam >>gedreht und somit Umgebungsluft wie ein Ventilator durch das Triebwerk >>bläst. Das soll die gleichmäßige Abkühlung fördern.. > > Klarer Fall von vermurkstem Design. Aber der NH90 ist sowieso eine > Lachnummer, ein "schönes" 100% Subventionsprojekt für die Industrie und > es kommt wie so oft nur akademischer Spielkram raus. Da fragt man sich > ernsthaft, wie die Leute vor 50 Jahren ohne CAD solide Triebwerke gebaut > haben. Nein, das Triebwerk ist ein Meisterwerk der Ingenieurskunst, es zeigt was heute technisch machbar ist. Vor 50 Jahren ist keiner auf die Idee gekommen, dass ein Druckverhältniss von 14:1 bei einem vierstufigen(!) Turboverdichter überhaupt technisch möglich ist. Heute ist es möglich, erfordert aber extrem geringe Toleranzen, einen minimalen Abstand zwischen Turbine und Gehäuse (da liegt das größte Problem) sowie eine optimale Verdichtergeometrie. Kann man machen, das Triebwerk wird dann schön leicht, leistungsfähig und sparsam, aber eben unschön empfindlich. Vor 50 Jahren waren die Turbinen zwar robuster, dafür aber schwerer und haben bei gleicher Leistung deutlich mehr Kraftstoff benötigt. Wenn sich das Triebwerk beim Abkühlen leicht verbogen hat (hat es auch damals schon), dann hat das keinen Interessiert. Zur Größenordnung beim Druckverhältniss: Vor 50 Jahren haben die Russen beim TW2 (für Mi-8) ein Druckverhältniss von 6,6:1 mit einem zehnstufigen Verdichter erreicht, in Europa und den USA hat man ein Druckverhältniss von 7,4:1 (Lycoming T53) erreicht, mit einem sechsstufigen Verdichter. Ich wünsche den NH90-Mechanikern schon mal viel ganz Spaß, wenn der Hubschrauber in der Wüste (Sand) und am Meer (Salzablagerungen) eingesetzt wird. Der Wirkungsgrad von Sandfiltern liegt bei weniger als 100% und gegen Salz hilft nur Triebwerk waschen, waschen, waschen (mit einer Mischung aus destilliertem Wasser und Methanol) Gegen sandbedingte Schäden hilft nur ein vorzeitiger Engine overhaul, normalerweise kommt der mit einem siebenstelligem Preisschild...
Berufsrevolutionär schrieb: > Ganz einfach, das waren noch richtige Handwerker die das Konstruieren > mit Schweiss und Tränen am Schraubstock von der Picke auf gelernt haben. nein, vil einfacher: Damals konnte man (zu vertretbaren Preisen) nicht so genau fertigen wie heute und hat dementsprechnd großzügige Toleranzen eingeplant. Kleinere Probleme sind dadurch erst gar nicht aufgetreten. Zudem konnte man damals in vielen Fällen nicht rechnen, sondern musste schätzen und experimentieren. Damals sind viele (Fehl-)Konstruktionen als Prototyp auf dem Prüfstand auseinandergeflogen...
Schreiber schrieb: > Berufsrevolutionär schrieb: >> Ganz einfach, das waren noch richtige Handwerker die das Konstruieren >> mit Schweiss und Tränen am Schraubstock von der Picke auf gelernt haben. > > nein, vil einfacher: Damals konnte man (zu vertretbaren Preisen) nicht > so genau fertigen wie heute und hat dementsprechnd großzügige Toleranzen > eingeplant. Nein, man hat auch damals auf 100stel genau gedreht und entworfen, außer in Russland. Deshalb haben die ja nur Grobzeug zustande gekriegt und haben moderne Triebwerke entweder als Kriegsbeute als Deutschland mitgebracht ode über Lend-Lease von den Allierten bekommen (Bspw das Rolls-Royce Nene II für die MiG-15). > Kleinere Probleme sind dadurch erst gar nicht aufgetreten. Zudem konnte > man damals in vielen Fällen nicht rechnen, sondern musste schätzen und > experimentieren. Damals sind viele (Fehl-)Konstruktionen als Prototyp > auf dem Prüfstand auseinandergeflogen... In Russland vielleicht, in Deutschland etc. ist schon ne Menge gerechnet und im Windkanal gemessen worden. Nicht zuletzt wurden wegen diese langweiligen Rechnerei im Flugbau von Konrad Zuse der erste Computer entwickelt. Das mag jetzt recht Deutschverherrlichung klingen ist aber so. Bei MTU und Co wurde schon damals gerechnet und exakt gefertigt, es ging schon damals nicht ohne ein Mindestmass an Präzesion.
@ Schreiber (Gast) >Nein, das Triebwerk ist ein Meisterwerk der Ingenieurskunst, es zeigt >was heute technisch machbar ist. Jain. >Vor 50 Jahren ist keiner auf die Idee gekommen, dass ein >Druckverhältniss von 14:1 bei einem vierstufigen(!) Turboverdichter >überhaupt technisch möglich ist. Heute ist es möglich, erfordert aber >extrem geringe Toleranzen, einen minimalen Abstand zwischen Turbine und >Gehäuse (da liegt das größte Problem) sowie eine optimale >Verdichtergeometrie. Kann man machen, das Triebwerk wird dann schön >leicht, leistungsfähig und sparsam, aber eben unschön empfindlich. Eben DORT liegt das Problem. Ein hochgezüchtetes Triebwerk ohne ausreichende Robustheit. >Vor 50 Jahren waren die Turbinen zwar robuster, dafür aber schwerer und >haben bei gleicher Leistung deutlich mehr Kraftstoff benötigt. Sicher, aber gerade in diesem Bereich ist Robustheit nicht so ganz falsch. Nicht nur im militärischen Bereich, auch im zivielen. >Ich wünsche den NH90-Mechanikern schon mal viel ganz Spaß, wenn der >Hubschrauber in der Wüste (Sand) und am Meer (Salzablagerungen) >eingesetzt wird. Der Wirkungsgrad von Sandfiltern liegt bei weniger als >100% und gegen Salz hilft nur Triebwerk waschen, waschen, waschen (mit >einer Mischung aus destilliertem Wasser und Methanol) >Gegen sandbedingte Schäden hilft nur ein vorzeitiger Engine overhaul, >normalerweise kommt der mit einem siebenstelligem Preisschild... Ganz tolles Design!!! Von Akademikern für Akademiker. Klar Fall von Overengineering!!! Siehe auch die Exzesse im Bereich von Carbonfahrrädern und anderem Leichtbauirrsinn, welche keine 1000km halten. FAIL! Das Gesamtpaket passt nicht! Aber vielleicht hat auch das sein Gutes. Die diversen (deutschen) Militärprojekte der Neuzeit sind ja alles lahme Enten, sei es NH90, Eurofighter, Puma etc. Vielleicht sorgt der weltfremde Perfektionismus für mehr Frieden ;-)
@Berufsrevolutionär (Gast) >und Co wurde schon damals gerechnet und exakt gefertigt, es ging schon >damals nicht ohne ein Mindestmass an Präzesion. Waren die Ingenieuere immer betrunken und sind getorkelt? ;-) https://de.wikipedia.org/wiki/Pr%C3%A4zession Oder meintest du eher das? https://de.wikipedia.org/wiki/Pr%C3%A4zision Kleiner, aber feiner Unterschied.
Falk B. schrieb: > Ganz tolles Design!!! Von Akademikern für Akademiker. > > Klar Fall von Overengineering!!! Klarer Fall von Overexclamationmarking. :-)
:
Bearbeitet durch User
Andreas S. schrieb: > Guckst Du hier (Tip 2: Add notes into your schematic) > http://www.fedevel.com/welldoneblog/2016/07/7-tips... > > Eine konsistente(!) farbliche Kennzeichnung hilft ausgezeichnet bei der > Dokumentation des Projektes. Auch in reinen Texten arbeitet man mit > unterschiedlichen Schriftattributen. Problematisch kann es jedoch > werden, wenn solche Attribute formale Auswirkungen auf das Verhalten > eines Programms oder einer Schaltung bekommen sollten. Bis sich jemand anderes aber zwischen der Seite mit den Farberklärungen und der entsprechenden Schematic tausend mal hin und hergeklickt hat, um zu sehen ob es nur Design- oder Layout-Notes sein sollen, hätte man mit 1 Sekunde nachdenken schon 3 mal herausgefunden, welches der beiden Themen dieser Kommentar nun betrifft. > Dann hast Du noch keine EDA-Systeme gesehen, in denen gar keine > VCS-Anbindung vorliegt. Wenn es sinnvolle Textdateien sind, braucht es das nicht zwangsläufig. Klar, bei Footprints wäre ein grafisches Diff nice, aber nur wenn das vernünftig ist, nicht wie bei Altium. > Das einzige, was ich bei Altium extrem ärgerlich > finde, ist die feste Integration von CVS und Subversion, so dass es > nicht möglich ist, auf beliebige VCS-Provider, z.B. für Git > zurückzugreifen. Das (aus Sicht des Unternehmens Altium) einzig richtige > VCS ist jedoch Altium Vault, welches intern aber auch größtenteils auf > Subversion basiert. Da ich mit Altium Vault noch nicht gearbeitet habe, > ist mir nicht bekannt, ob dort Inkonsistenzen auftreten. Exakt, und man ist durch Binärdateien darauf angewiesen, dass Altium das implementiert. Inklusive aller Altium-typischen Bugs. Wären es vernünftig versionierbare Textdateien, ginge git auch super (siehe Kicad). > Das nervt in der Tat. Allerdings ist die PrjPcb-Datei im Klartextformat > und lässt sich sehr gut vergleichen, erfüllt also eine wesentliche > Anforderung. Zudem wird die Datei niemals überschrieben, es sei denn, > dass man es mit "Save All" oder "Save Project" explizit veranlasst. Auf einmal ist Klartextform doch eine wesentliche Anforderung? Und ja, man könnte es vernünftig diffen, wenn die Australier sich mal überlegt hätten, wie man versionierbare Dateien händelt. Dass jeder Rechner seine scheiß Druckerkonfig da reinschreibt, ist Bullshit. Das mit dem Save stimmt, aber wenn man neue Schematic sheets hinzufügt, muss man speichern.. > Ebenso nervt es auch, dass die Information über den DRC-Status in der > PcbDoc-Datei gespeichert wird und nicht nur in den ebenfalls generierten > DRC- und HTML-Dateien. Da ich üblicherweise jeweils einen DRC > unmittelbar vor der Erzeugung der Fertigungsdaten und einmal nach > Erzeugung der Fertigungsdaten durchführe, kann ich auf Grund der > veränderten PcbDoc nicht auf Anhieb sagen, ob sich womöglich eine > versehentliche Änderung eingeschlichen hat. Jap, ebenso ein totaler Designfehler der Dateistrukturen. > Altium Designer ändert keine Projektdateien ohne vorheriges explizites > Speichern. Wenn man neue Sheets hat muss man das aber, s.o. > Textuelle Diffs von Klartextformaten besitzen bei grafischen > Darstellungen auch nur eine sehr beschränkte Aussagekraft. Diffs auf > z.B. Gerber- oder Bohrdateien schaue ich mir auch nur dann an, wenn ich > minimale Änderungen vorgenommen habe und sicherstellen will, keine > anderen Strukturen verschoben zu haben. Leider scheitert das (unabhängig > vom eingesetzten EDA-System) auch dann, wenn dadurch gefüllte Flächen > verändert werden. Dann müssen zwangsweise Unmengen von Vektoren > verändert werden, obwohl man eigentlich nur ein einziges Via verschoben > hat. Besser beschränkte Aussagefähigkeit als garkeine. Gute grafische Difftools sind ein schönes Addon, aber selbst die liefert Altium ja nicht. > Und wie schon erwähnt, kann man bei AD auch die Verwendung von > Klartext-Projektdateien erzwingen. Das werde ich mir in jedem Fall mal ansehen, danke für die Info. > Das ist entweder Unkenntnis, eine Lüge oder eine sonstige Verleugnung > der Realität. Es gibt sehr viele IDEs, die mit binären Projektdateien > arbeiten, was dort um einiges ärgerlicher ist. Nur weil Emacs und sehr > viele IDEs glücklicherweise auf Binärdateien verzichten, ist eine > Verallgemeinerung nicht zulässig. Hab ich gesagt, dass alle IDEs gut sind? Welche die Binärdateien verwenden sind genauso ein Schrott wie EDA-Tools. Btw bei welchen IDEs ist das denn so? > Ich vermute, dass am CERN auch noch Unmengen an anderer Software > eingesetzt wird, die mit "Binärkacke" arbeitet. Mit Sicherheit, die ist dann aber eben genauso wenig gescheit versionierbar wie der Altium-Schrott. > Ich arbeite seit vielen Jahren mit unterschiedlichen > Versionskontrollsystemen und kenne daher selbstverständlich deren Vor- > und Nachteile sowie natürlich auch die Grenzen. Und da muss man eben > auch zur Kenntnis nehmen, dass "textuell diffbare" Dateiformate in > manchen Fällen eben nicht sinnvoll sind. Z.B. mögen bei einfachen > Vektorgrafiken solche Formate noch sinnvoll sein, aber z.B. bei Fotos > oder Videos sind sie es nicht mehr. Fotos und Videos gehören eben auch nicht in ein VCS (genauer, eine einzige Grundversion schon, aber mehr nicht). Wenn man daran rumeditiert, gehören zB die Textoverlays inkl ihrer Koordinaten ins VCS (oder gleich der Latex-Quellcode). Nichtdestruktive Bildbearbeitung sollte genau so funktionieren. Wie da VCS-Anbindung aussieht, weiß ich aber nicht.
Falk B. schrieb: > Ganz tolles Design!!! Von Akademikern für Akademiker. Nein, von Politikern bestellt, von Ingenieuren für Politiker entwickelt und von Politikern für gut befunden. Sogar die explosionsartig anwachsende Wunschliste der Politiker konnte man halbwegs umsetzen. Und der Hubschrauber fliegt sogar noch, obwohl er dadurch viel schwerer wie ursprünglich geplant wurde ohne dass der Bauraum für das Triebwerk größer wurde... Und die Auftragsverteilung erfolgt nach europapolitischem Proporz, kann ja nicht sein, dass der mit der meisten Erfahrung die Teilaufträge bekommt! Falk B. schrieb: >>Vor 50 Jahren waren die Turbinen zwar robuster, dafür aber schwerer und >>haben bei gleicher Leistung deutlich mehr Kraftstoff benötigt. > Sicher, aber gerade in diesem Bereich ist Robustheit nicht so ganz > falsch. > Nicht nur im militärischen Bereich, auch im zivielen. Früher gab es, verglichen mit heute, im zivilen und beim Militär: 1. Triebwerke mit mindestens doppeltem Kraftstoffverbrauch 2. Triebwerke mit mindestens zehnfacher Lärmentwicklung 3. Triebwerke mit mindestens hundertfachen Schadstoffausstoß 4. 5-Mann-Cockpit mit Pilot, Copilot, Boardingenieur, Navigator und Funker 5. überall nur robuste und wartungsfreundliche Technik 6. garantiert keine Softwareprobleme 7. viel mehr Arbeitsplätze für das gleiche Ergebniss 8. höhere Kosten für ein schlechteres Ergebniss 9. viel mehr tödliche Unfälle!!!
Angehängte Dateien:
-
ad_pcb_ascii.png
9,6 KB -
ad_sch_ascii.png
10 KB -
ad_storage_manager.png
130 KB
Horst schrieb: > Bis sich jemand anderes aber zwischen der Seite mit den Farberklärungen > und der entsprechenden Schematic tausend mal hin und hergeklickt hat, um > zu sehen ob es nur Design- oder Layout-Notes sein sollen, hätte man mit > 1 Sekunde nachdenken schon 3 mal herausgefunden, welches der beiden > Themen dieser Kommentar nun betrifft. Wenn die Verwendung der Farben konsistent erfolgt, kennt man sie irgendwann auswändig. Dann muss man nicht immer wieder auf der Seite mit den Farberklärungen nachschauen. >> Dann hast Du noch keine EDA-Systeme gesehen, in denen gar keine >> VCS-Anbindung vorliegt. > > Wenn es sinnvolle Textdateien sind, braucht es das nicht zwangsläufig. Wieso ignorierst Du eigentlich meine Ausführungen über den AD Storage Manager? Hast Du ihn Dir überhaupt schon einmal angeschaut? Ich finde die Integration von externer und interner Versionierung dort sehr gelungen. So etwas habe ich bisher noch nicht in anderen Entwicklungsumgebungen gesehen, was aber nicht bedeutet, dass es sie dort nicht auch gäbe. > Klar, bei Footprints wäre ein grafisches Diff nice, aber nur wenn das > vernünftig ist, nicht wie bei Altium. Altium Designer ist nur ein Beispiel; in der Tat sind manche Dinge dort sehr schlecht umgesetzt, z.B. grafische Diffs in Stromlaufplänen. Neben der grafischen Darstellung enthalten diese Diffs aber auch eine textuelle Beschreibung, anhand derer sich die Änderungen besser nachvollziehen lassen. > Exakt, und man ist durch Binärdateien darauf angewiesen, dass Altium das > implementiert. Inklusive aller Altium-typischen Bugs. Wären es > vernünftig versionierbare Textdateien, ginge git auch super (siehe > Kicad). Wieso klammerst Du Dich an die völlig unhaltbare Behauptung, Altium Designer verwende immer nur Binärdateien? Wie schon etliche Male erwähnt, kann man Stromlaufpläne und Layouts im ASCII-Format speichern, siehe Screenshots. > Auf einmal ist Klartextform doch eine wesentliche Anforderung? Es war Deine Anforderung, und die wird durch AD-Projektdateien erfüllt. Selbstverständlich finde ich Klartextdateien auch besser, wenn es um Daten geht, die sich auf diese Weise sinnvoll vergleichen oder beurteilen lassen. > Und ja, man könnte es vernünftig diffen, wenn die Australier sich mal > überlegt hätten, wie man versionierbare Dateien händelt. Dass jeder > Rechner seine scheiß Druckerkonfig da reinschreibt, ist Bullshit. Was die Druckerkonfiguration da soll, habe ich mich auch schon etliche Male gefragt. Insbesondere bei Lieferungen an Dritte möchte ich eigentlich nicht, dass anschließend die halbe Welt einen Teil unserer internen Netzwerkstruktur kennt. Aber da es sich um Klartextdateien handelt, kann man diese Informationen ggf. auch einfach entfernen. > Das mit dem Save stimmt, aber wenn man neue Schematic sheets hinzufügt, > muss man speichern.. Dann hat sich aber an der Projektdatei auch mehr geändert als nur die Druckereinstellung. Wenn man ein ordentliches Programm zum Einchecken (z.B. TortoiseSVN) verwendet, kann man die geänderten Druckereinstellungen auch einfach verwerfen. Bei uralten Versionen von M$ Office erlaubte es sich Word sogar, schon beim Einlesen eines Dokuments den gesamten Seitenumbruch neu durchzuführen, und zwar gemäß des Seitenformats des Standarddruckers. Welch eine Scheiße... > Jap, ebenso ein totaler Designfehler der Dateistrukturen. Und zwar unabhängig von einem binären oder textuellen Datenformat. > Hab ich gesagt, dass alle IDEs gut sind? Welche die Binärdateien > verwenden sind genauso ein Schrott wie EDA-Tools. Du hast behauptet, dass JEDER Editor auf die Verwendung von Binärdateien verzichte. Es erfolgte keine Einschränkung auf gute oder schlechte IDEs. > Btw bei welchen IDEs ist das denn so? Ältere Versionen von Microsoft Visual Studio verwenden binäre Projektdateien. Simatic Step7 speichert sogar AWL-Quelltexte ohne jegliche Not in Binärdateien, obwohl es sich um rein textuelle Beschreibungen handelt. Darüber hinaus kann man nicht einmal die Dateinamen oder Verzeichnisstrukturen vorgeben, sondern sie werden automatisch in fortlaufend numerierten Dateien gespeichert. Diese Scheiß-Software ist der größte Anachronismus. Mir ist nicht bekannt, ob Siemens das bei TIA Portal mittlerweile geändert hat. > Fotos und Videos gehören eben auch nicht in ein VCS (genauer, eine > einzige Grundversion schon, aber mehr nicht). Wenn man daran > rumeditiert, gehören zB die Textoverlays inkl ihrer Koordinaten ins VCS Wie bitte? Selbstverständlich gehören sämtliche Bestandteile einer Dokumentation ins CVS, und dazu gehören natürlich auch Fotos. Meine übliche Vorgehensweise besteht darin, das unbearbeitete Foto einzuchecken und anschließend die Bearbeitungen, d.h. zuschneiden, skalieren, ggf. beschriften. > (oder gleich der Latex-Quellcode). Es wäre wenig sinnvoll, Dokumente nur als Latex-Quellcode einzuchecken, die selbst gar nicht mit Latex erstellt und bearbeitet werden. Latex besitzt außer im universitären Bereich oder einige Forschungsinstituten kaum mehr Relevanz. Außerdem geht es im konkreten Fall nicht um in Textdokumente eingebettete Grafiken, sondern um die Bilddateien selbst. Für die Lieferung an Dritte dürfen auch keine Overlays o.ä. mehr enthalten sein, weil sie entfernt werden können. Konkrete Beispiele befinden sich im Anhang. Die Bilder sind absichtlich mit einem einfachen Malprogramm bearbeitet, damit sich eben die übermalten Bereiche nicht mehr rekonstruieren lassen. > Nichtdestruktive Bildbearbeitung > sollte genau so funktionieren. Wie da VCS-Anbindung aussieht, weiß ich > aber nicht. Aha?
:
Bearbeitet durch User
Danke an Andreas, für die Einblicke in die neueste Altium Version. Da hat sich ja doch einiges getan! Wenn man sich jetzt noch auf ein gemeinsames herstellerübergreifendes Format für Bauteile einigen könnte, würden diese Errungenschaften wohl auch schneller in den Firmen ankommen.
Beitrag #5322937 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.