Hallo, wir haben noch ein paar alte Platinen auf Protel 98 und da wir mit diesen immer noch arbeiten würde ich gerne diese uralt Software ersetzen und die Platinen auf Altium migrieren. Bei neuen Projekten arbeiten wir heute mit Kicad was für unsere Aufgaben okay ist. So jetzt zur Frage, wisst ihr woher man eine etwas ältere Altium Version kaufen kann? Eine noch aus Zeiten ohne Abo aber wenn möglich auf jeden Fall eine die schon 64bit kann. Ich hab schon gegoogelt aber nichts gefunden (außer irgendwelche illegalen Seiten, was auf keinen Fall in Frage kommt). Evtl habt ihr mir einen Tipp?
Altium ist erst seit 2018 64Bit-fähig. Zum Abo zwingt dich keiner, das geht auch heute noch ohne. Du kannst aber Altium auch monatsweise mieten. Wenn du das Projekt nur kurz überarbeiten willst, ist das billiger.
Gibt es eigentlich einen brauchbaren Weg, Projekte aus protel98 in KiCad zu überführen?
DerEinzigeBernd schrieb: > Gibt es eigentlich einen brauchbaren Weg, Projekte aus protel98 in > KiCad > zu überführen? Nein. Mit diesem ganzen Import zeugs wirst du bei Kicad nicht glücklich. Selbst der Eagle Import, der schon lange existiert, ist nur so gerade brauchbar für einfache dinge.
DerEinzigeBernd schrieb: > Gibt es eigentlich einen brauchbaren Weg, Projekte aus protel98 in KiCad > zu überführen? die Idee mit der Miete wäre dafür ggf. eine gute Idee. https://www2.futureware.at/KiCad/ Wobei wir dann vermutlich komplett auf Eagle gehen würden und nicht auf Kicad.
okay das wusste ich nicht. das ändert einiges weil einmalig wäre es zu überlegen. wobei die Preise glaub auch völlig irre sind, hab gerade auf der homepage gesehen ~11.000€ für eine unlimitierte Lizenz. schon irre
Rudi W. schrieb: > okay das wusste ich nicht. das ändert einiges weil einmalig wäre es zu > überlegen. wobei die Preise glaub auch völlig irre sind, hab gerade auf > der homepage gesehen ~11.000€ für eine unlimitierte Lizenz. schon irre Deutlich übler als diese einmaligen Kosten ist der versteckte Zwang, zusätzlich noch Features per Abo lizensieren zu müssen. Beispielsweise lassen sich in aktuellen(!) AD-Versionen keine gemischten Layer Stacks mehr anpassen. Hierfür benötigt man zusätzlich(!) noch eine AD Pro-Subskription. Das ist wohlgemerkt ein Feature, dass früher in AD enthalten war und erst ab ca. Version 20 "ausgelagert" wurde. Die schmierigen Vertriebler von Altium lassen einen als Kunden diesbezüglich im Unklaren. Selbst wenn man gezielt nach den "ausgelagerten" Features fragt, bekommt man als Antwort nur einen Link auf die allgemeine Featureliste.
Alles eine Frage der Verhandlungen mit dem Vertrieb. Wir haben kürzlich eine Pro-Lizenz mit Subscription gekauft (Hurra, nie wieder Circuit Studio) für unbedeutend mehr als daß, was wir im Erstangebot für die Baselizenz hingelegt hätten.
Andreas S. schrieb: > Deutlich übler als diese einmaligen Kosten ist der versteckte Zwang, > zusätzlich noch Features per Abo lizensieren zu müssen. Beispielsweise > lassen sich in aktuellen(!) AD-Versionen keine gemischten Layer Stacks > mehr anpassen. Hierfür benötigt man zusätzlich(!) noch eine AD > Pro-Subskription. Das ist wohlgemerkt ein Feature, dass früher in AD > enthalten war und erst ab ca. Version 20 "ausgelagert" wurde. Was sind gemischte Layer Stacks? Folienleiter mit starren Parts? Und was hindert einen daran, für solche Einzelfälle noch eine 19'er oder 20'er Version parallel installiert zu haben? fchk
Frank K. schrieb: > Was sind gemischte Layer Stacks? Folienleiter mit starren Parts? Ja, das wäre eine Ausführung. Man kann aber auch z.B. starre Leiterplatten mit Inlays definieren. > Und was hindert einen daran, für solche Einzelfälle noch eine 19'er oder > 20'er Version parallel installiert zu haben? Mir ist nicht bekannt, in welcher konkreten Version diese Umstellung durchgeführt wurde, aber es geht mehr um die allgemeine Thematik, dass irgendwelche sehr selten verwendeten, aber dann doch sehr wichtigen Features plötzlich nicht mehr enthalten sind und nachgelöhnt werden muss. Ich kann durchaus verstehen, dass Features, die Zugriff auf fortwährend gepflegte Online-Datenbestände benötigen, abopflichtig werden, da ja hierfür auch beim Betreiber fortwährend Kosten entstehen, aber für schon existente Features, die auch nicht grundlegend überarbeitet und erweitert werden, zusätzlich zum Kaufpreis und zur normalen Wartung nochmals in Form eines Abos bezahlen zu müssen, grenzt schon an Betrug.
Andreas S. schrieb: > grenzt > schon an Betrug. grenzt? Das ist Betrug! Die ganzen Altium User kommen mir manchmal vor wie die Schafe. Die halten auch still und lassen alles mit sich machen :-( Was den TO (Rudi W.) anbelangt ist es 100x gescheiter das ganze in KICad nach zu pinseln, zumal KiCad Kenntnisse ja vorlegen. Ich weiss vielen graus vor sowas, aber in nachhinein ärgert man sich, , dass man das nicht schon früher gemacht hat.
Rudi W. schrieb: > DerEinzigeBernd schrieb: >> Gibt es eigentlich einen brauchbaren Weg, Projekte aus protel98 in KiCad >> zu überführen? > > die Idee mit der Miete wäre dafür ggf. eine gute Idee. > https://www2.futureware.at/KiCad/ > Wobei wir dann vermutlich komplett auf Eagle gehen würden und nicht auf > Kicad. KiCad 6 kann Altium Dateien direkt importieren. Seitdem ist altium2kicad eigentlich obsolet, da mir nichts bekannt ist was altium2kicad besser importiert als der integrierte Importer.
Rotringvertreter schrieb: > Was den TO (Rudi W.) anbelangt ist es 100x gescheiter das ganze in KICad > nach zu pinseln, zumal KiCad Kenntnisse ja vorlegen. > Ich weiss vielen graus vor sowas, aber in nachhinein ärgert man sich, > , dass man das nicht schon früher gemacht hat. Ich finde es faszinierend, wie viele in den letzten Jahren von Altium auf KiCAD umgestellt haben. Den Sales-Droiden scheint das inzwischen auch Bauchschmerzen zu bereiten ...
Olaf L. schrieb: > Nein. Mit diesem ganzen Import zeugs wirst du bei Kicad nicht glücklich. ALso ich habe mehrer Projekte von Eagle und Altium importiert. Klappt perfekt.
Andreas S. schrieb: > Deutlich übler als diese einmaligen Kosten ist der versteckte Zwang, > zusätzlich noch Features per Abo lizensieren zu müssen. Beispielsweise > lassen sich in aktuellen(!) AD-Versionen keine gemischten Layer Stacks > mehr anpassen. Hierfür benötigt man zusätzlich(!) noch eine AD > Pro-Subskription. Das ist wohlgemerkt ein Feature, dass früher in AD > enthalten war und erst ab ca. Version 20 "ausgelagert" wurde. Das stimmt, aber niemand hindert einen daran, eine AD20 Version zu installieren, selbst wenn ich heute eine AD23 kaufe, kann ich die alten voll nutzen. Man muss nur aufpassen, die wollen jetzt ums verrecken auf on demand lizenzen umstellen. Das Problem dabei: Soweit ich das gehört habe, ist es so, dass jede Latium Instanz eine eigene on demand Lizenz zieht. D.h. hat man 2 verschiedene Versionen offen, werden auch 2 Lizenzen benötigt. Hat man indess eine Stand alone Lizenz, so ist diese auf den rechner bezogen und man kann soviele Altium Versionen öffnen, wie man mag bzw, wie der Rechner schafft. Also 3 gehen auf jeden Fall gleichzeitig, mehr hab ich nicht installiert und konnte es deshalb auch noch nicht testen. Außerdem nutzen wir in der Firma für alle nicht Hardwareentwickler noch eine alte Viewer Version. Die unterstützt zwar vieles neue nicht mehr (Am ärgerlichsten ist, dass der Variantenmanager dabei noch nicht geht) aber ist unbegrenzt gültig und man kann durch die Schaltpläne surfen und hat das Crossprobing. Fürs Signalverfolgen reicht das allemal. Wenn man keine solche alte Version hat, muss man alle halbe Jahre eine Lizenzverlängerung für eine Viewer Lizenz beantragen. So wie ich das sehe, ist es dann nur noch ein kleiner Schritt, Viewer Lizenzen ebenfalls kostenpflichtig zu machen. Aber, wenn man mit den älteren Versionen arbeitet, (Bis AD19/20) kann man eigentlich alles machen, was man so braucht. automatisches Bauteilausrichten am Polarkoordinatensystem, Starr Flex und Semiflex sind dabei als Sondertechnologien voll nutzbar. Bei neueren Versionen geht das nämlich nicht mehr. Ich hab da erst Mitte Dezember einen Disput mit den Altium Strolchen durch, die mir unbedingt für alle unsere Lizenzen eine Subscription Wiedereingliederung und Verlängerung andregen wollten. Ich hab ihm dann insbesondere beim Starrflex die Problematik gezeigt, dass ich eben nicht, entgegen seiner Aussage, einen entsprechenden Platinenaufbau bearbeiten kann. Ansehen ja, aber editieren: nein. Das geht nur mit älteren Versionen. Also hab ich immer mindestens 2 parallel installiert um alles abdecken zu können, was ich so brauche. ich bin schon sehr gespannt, wie das ausgegangen ist, bestimmt hab ich morgen eine mail im Postfach wenn ich es wieder öffne
Rudi W. schrieb: > die Idee mit der Miete wäre dafür ggf. eine gute Idee. Na da gehen die meinungan aber weit auseinander. > https://www2.futureware.at/KiCad/ Reiner LIB Converter wie es scheint. > Wobei wir dann vermutlich komplett auf Eagle gehen würden und nicht auf > Kicad. ??? Ich denke ihr benutzt schon Kicad. Was willste denn jetzt noch mit dem angestaubten Mietadler? Wühlhase schrieb: > für unbedeutend mehr als daß, was wir im > Erstangebot für die Baselizenz hingelegt hätten. HAHA, so machen die das nunmal. Wen die nochmal kräftig Umsatz brauchen für die Verkaufsprovisionen, verschleudern die Altium an Neukunden. Wenn Ihr dann bis zu den Eiern im Altium Universe steckt und da ein paar dutzend Projekte drin laufen, die Probleme beginnen, weil entweder etwas dringend benötigtes nicht läuft oder ein neues Update wieder was kaputtgespielt hat das immer gut lief, oder plötzlich etwas extra Geld kostet das immer inklusive war, dann werdet ihr feststellen wie Altium sein Geld verdient.
Max M. schrieb: >> Wobei wir dann vermutlich komplett auf Eagle gehen würden und nicht auf >> Kicad. > ??? > Ich denke ihr benutzt schon Kicad. > Was willste denn jetzt noch mit dem angestaubten Mietadler? wir haben zwei relativ umfangreiche Hauptplatinen welche jedoch in verschiedenen Variationen bestückt werden. Dieses Variationen Handling ist halt in Kicad grottig oder besser gesagt eigentlich nicht wirklich unterstützt, das sieht halt in eagle wesentlich besser aus. Ansonsten wäre Kicad für uns völlig ausreichend
Rudi W. schrieb: > Dieses Variationen Handling > ist halt in Kicad grottig oder besser gesagt eigentlich nicht wirklich > unterstützt Unterschätze nicht die mächtigen Funktionen von Kicad + Python. Du könntest z.B. mehrere Variantenfelder in den Bauteilen definieren. Ich habe z.B. die Einträge einer Kunden DB in die Bauteile eingefügt und exportiere über ein angepassten BOM Script eine CSV die direkt von seiner IT verarbeitet werden kann, weil die genauso aussieht wie die BOM seiner intern verwendeten CAD Lösung. Für mich ist es in dem Fall z.B. ein 10K 0805. In seiner DB kommt der u.U. mal von Vishay mal von KOA. Eine genaue Typnr erhält der erst wenn die Verknüpfung BOM / DB stattfindet. Ich könnte aber auch Scripte bauen um zwischen alternativen FP zu wechseln oder je nach Variante verschiedene BOMs zu erzeugen. Da setzt nur die Fantasie Grenzen. Du kannst beliebige Felder definieren und damit beliebige Sachen machen.
Max M. schrieb: > Wühlhase schrieb: >> für unbedeutend mehr als daß, was wir im >> Erstangebot für die Baselizenz hingelegt hätten. > > HAHA, so machen die das nunmal. > Wen die nochmal kräftig Umsatz brauchen für die Verkaufsprovisionen, > verschleudern die Altium an Neukunden. > Wenn Ihr dann bis zu den Eiern im Altium Universe steckt und da ein paar > dutzend Projekte drin laufen, die Probleme beginnen, weil entweder etwas > dringend benötigtes nicht läuft oder ein neues Update wieder was > kaputtgespielt hat das immer gut lief, oder plötzlich etwas extra Geld > kostet das immer inklusive war, dann werdet ihr feststellen wie Altium > sein Geld verdient. Keine Sorge, ich kenne Altium lange genug und Neukunden sind wir für die ja auch nicht. ;)
Angehängte Dateien:
-
Rigid_Plan.jpg
27 KB -
Rigid_Setting.jpg
31 KB
Christian B. schrieb: > Aber, wenn man mit den älteren Versionen arbeitet, (Bis AD19/20) kann > man eigentlich alles machen, was man so braucht. automatisches > Bauteilausrichten am Polarkoordinatensystem, Starr Flex und Semiflex > sind dabei als Sondertechnologien voll nutzbar. Bei neueren Versionen > geht das nämlich nicht mehr. Das ist ganz klar gegen die Aussagen von einigen Altium Mitarbeitern auch gegen die von einem etwas "höheren" Mitarbeiter. Es wird nichts weg genommen. Wer also ein Feature gekauft hat und seine Subscription fort führt verliehrt nichts. Wer seine Subscription beendet und später neu beginnt muß sich für ein Modell entscheiden, kann sein das man dann Pro braucht. Das Starr Flex nicht mehr gehen soll ist mir neu. Konnte ich im Feature Vergleich auch nicht finden. Ich sehe auch keine Beschwerden im Altium Forum (sind mir jedenfalls nicht aufgefallen). Im Vorfeld gab es Verwirrung siehe Rigid_Plan.jpg, die Wortwahl war unglücklich. Es hieß Rigid-Flex Support nur für Pro das war aber unter der Überschrift MCAD CoDesigner und nicht im PCB. Wie sind die Advanced Settings ? (Rigid_Setting.jpg)
Angehängte Dateien:
-
TedPawela_1.jpg
28 KB -
TedPawela_2.jpg
18 KB
Hab die Aussage von dem "höheren" Mitarbeiter gefunden. Ted Pawela Chief Ecosystem Officer & Head of Cloud (Nexar) Business Unit at Altium Hier der Link: https://forum.live.altium.com/#/posts/252342/802203
:
Bearbeitet durch User
@Taz: Ja, die Aussage daß der neue Lizenzierungskram nur die Kollaborateure betreffen, habe ich auch mal im Forum gelesen. Ich muß aber sagen, es bleibt irritierend wenn man das hier liest: https://www.altium.com/de/altium-designer/subscription/ Altium hat dieses Jahr ein neues Feature rausgebracht namens Harness Integration (ein unglücklicher Name, es hat nix mit dem Signal Harness zu tun). Und das ist meines Wissens tatsächlich erst ab der Pro-Lizenz enthalten und wird nicht in der Base-Licence veröffentlicht.
Angehängte Dateien:
-
Harness_Tool.jpg
98 KB
Wühlhase schrieb: > Altium hat dieses Jahr ein neues Feature rausgebracht namens Harness > Integration In der Pro ist der Multiuser,Multiboard und MCAD Kram drin, aber ganz ehrlich ich will nur eine Platine designen und dafür brauche den Mist nicht. Und dieses Harness Tool, Bitte, was soll das ? Da gib's bessere Möglichkeiten. Hat auch so gar nichts mit Platine routen zu tun.
:
Bearbeitet durch User
Taz G. schrieb: > In der Pro ist der Multiuser,Multiboard und MCAD Kram drin, aber ganz > ehrlich ich will nur eine Platine designen und dafür brauche den Mist > nicht. Naja, wenn du EINE Platine bauen willst, brauchst du das in der Tat nicht. Ich baue aber gerade ein System, das aus, mal schauen, sechs oder sieben Platinen oder so besteht. Und wenn die dann noch sowohl mechanisch als auch elektrisch zusammenpassen müssen, dann ist das schon deutlich besser so. Vor allem wenn du relativ viele Stecker zwischen den Platinen hast. Einen Stecker magst du ohne Probleme mit Papier und Bleistift oder im Schematic verwalten, bei drei mal sechs Steckern macht das schon sehr viel weniger Spaß. Taz G. schrieb: > Und dieses Harness Tool, Bitte, was soll das ? Wenn du eine Multiboardverbindung erstellt hast, kannst du daraus Kabelpläne erstellen. Nicht nur zur Dokumentation, sondern auch als Zusammenbauanleitung für die Produktion. Ich werde das mal testen, ein paar Kabelverbindungen habe ich bei meinem Projekt momentan auch. Relativ einfaches Zeug wie acht verdrillte Aderpäärchen, aber auch komplexeres wo 40 Adern wild verdrahtet sind, teilweise verdrillt, teilweise nicht... Taz G. schrieb: > Da gib's bessere Möglichkeiten. Hm, welche denn? Mir ist keine bekannt.
Angehängte Dateien:
-
AD21_Sicht.png
140 KB -
AD19_Sicht.png
280 KB
Taz G. schrieb: > Das Starr Flex nicht mehr gehen soll ist mir neu. ok, dann haben sie vermutlich den Workflow komplett verändert, was am Ende aufs gleiche raus läuft: Im Anhang hab ich mal 1 Beispiel: Das selbe Design, einmal mit AD21: Ich kann die Bereiche des Flexiblen Teils zwar sehen, aber fast nichts editieren, neu erstellen gar nicht. Bei AD19 Ansicht kann ich sie sehen und editieren. Auch mit dem vorgeschlagenen Weg, aus der AD21 Hilfe kam ich da nicht weiter. Sogesehen würde ich vorschlagen: Probiere es aus und wenn du einen Weg gefunden hast währe ich dir sehr verbunden, mir den mitzuteilen. Altium selbst ist jedenfalls nicht in der Lage, mir zu erklären, wie das in den neueren Versionen gehen soll. Sie schreiben nur etwas von: "improved" bezüglich dieses Features. Ein Anruf beim Support ergab dann die Aussage, dass dafür eine Pro Lizenz nötig sei. Soviel zum Thema. Da wir nur wenig Starrflex machen, ist das auch nicht sofort aufgefallen und mein Workaround (eine alte Version dafür zu nutzen) hat dem AD Mitarbeiter auch nicht sonderlich gefallen. Ich hab damals einiges versucht und auch oft genug mit dem Support telefoniert. hier meine Antwort auf die letzte Mail von Altium dazu: In den (board planning...) Mode komme ich schon, aber ich kann dort keine Bereiche neu anlegen. Vorhandene Bereiche editieren geht in Grenzen. Wie gesagt, es ist nicht unsere Kernkompetenz. In 10 Jahren haben wir jetzt 2 Starr Flex Platinen. Aber genau das macht eine Zusatzlizenz für solch eine Funktion vollkommen unattraktiv. Das Problem ist weniger in die Ansicht zu kommen als vielmehr, dass sie mir nichts nützt, da ich weder Flexible Bereiche angeben noch Biegebereiche definieren kann. Ich habe das eben nochmal versucht. Im AD19 kann ich im Board planning mode unter „Design“ Split lines und bending lines definieren., diese Menüs gibt es in der 21-er Version, wie ich sie nutze, aber gar nicht. Somit kann ich mir eine fertige Platine zwar ansehen, die Daten ausgeben und sogar bestehende Bereiche in Grenzen editieren (ich kann sie verschieben, aber z.B. bei den Biegebereichen weder den Winkel noch die Breite verändern, in dem dieser wirksam ist), diese aber nicht neu erstellen. Am meisten nervt mich daran, dass ich da fast einen Tag herumprobiert habe, bis ich aufgab. Da sollten Sie entsprechend in den Tutorials auch drauf hinweisen, dass das eben nur geht, man man eine spezielle Zusatzlizenz erworben hat. Letzteres war ganz klar die (mündliche) Aussage des Altium Mitarbeiters. Das war im Sommer 21.
Wühlhase schrieb: > Hm, welche denn? Mir ist keine bekannt. Das ist anwendungsabhängig. Ich verbinde zwei maximal drei Platinen. Da reicht ein Blockschaltbild oder ein PowerPoint. Hast Du mein angehänges Bild gesehen ? Das kann man ganz einfach mit PowerPoint, Excel und Paint erstellen. Diese Tools sind verhanden, laufen und es auch nicht nötig sich in neues buggy Tool einzuarbeiten. Der Arbeitsaufwand ändert sich auch nicht. Aber Du hast Recht, willst Du z.B. die Verkabelung in einem Auto lückenlos dokumentieren, jede Menge Platinen, Kabelstränge, Kabellängen, Biegungen, Farben, Stecker und und und da ist so ein Tool hilfreich. Aber was hat das mit PCB Design zutun ? Wenn Du diese Features gebrauchen kannst bitte, gerne. Ich sage ja nicht, das die Pro Features schlecht sind oder zu nichts zu gebrauchen sind. Ich sage nur, dass ich die für meine Platinenerstellung nicht brauche und ich denke die meisten PCB Router brauchen die nicht.
Angehängte Dateien:
-
BendingLine.jpg
20 KB
Christian B. schrieb: > ok, dann haben sie vermutlich den Workflow komplett verändert Ja Workflow "improved", scheint aber kein Lizenzproblem zu sein. Ich hab noch keine Starr-Flex Platine gemacht, aber mal rum probiert. - Beim ersten Versuch war ich auf einer mech. Lage und dort kann ich keine Bending Lines platzieren, muste auf Multilayer wechseln. - Den platzierten Bending Line konnte ich nicht editieren, musste den Bereich (Region) vorher mit Shift+Klick markieren, dann kann ich editieren. - Eine Split line kann ich ohne zu markieren platzieren bekomme aber die Meldung "One bending line was added" ?
:
Bearbeitet durch User
Taz G. schrieb: > Hast Du mein angehänges > Bild gesehen ? Das kann man ganz einfach mit PowerPoint, Excel und Paint > erstellen. Diese Tools sind verhanden, laufen und es auch nicht nötig > sich in neues buggy Tool einzuarbeiten. Ja, habe ich. Sicher kannst du das in jedem beliebigen Zeichenprogramm nachbasteln, das geht schon. Du hast damit aber keine Referenz darüber, welche Signal an welchem Stecker wo rausgehen sollen. Pinbelegung, Aderfarben, Verdrillung usw. ebenso wenig. Und wenn du da was änderst hast du keine Kontrollmöglichkeit oder keine Warnung, daß da was auseinanderläuft. Aber mit dem buggy könntest du Recht haben...so wie ich Altium kenne dauert es erstmal zwei Jahre, bis das halbwegs brauchbar funktioniert. Aber ausprobieren werde ich es trotzdem. Taz G. schrieb: > willst Du z.B. die Verkabelung in einem Auto > lückenlos dokumentieren, jede Menge Platinen, Kabelstränge, Kabellängen, > Biegungen, Farben, Stecker und und und da ist so ein Tool hilfreich. > Aber was hat das mit PCB Design zutun ? Der Kabelbaum im Auto ist jetzt ein Extremfall, aber ja: Wo sollte so ein Werkzeug denn sonst angesiedelt sein wenn nicht bei denen, die die Leiterkarten machen? Pinzuordnung, Verdrillung, Schirmung usw. geben doch nur die Elektronikentwickler vor, den Mechanikern würde auch ein dicker generischer Schlauch ausreichen. Und Programme wie EPLAN sind da auch fehl. Taz G. schrieb: > Ich sage ja nicht, das die Pro Features schlecht sind oder zu nichts zu > gebrauchen sind. Nein, aber du fragtest doch wozu man das braucht... ;)
Dann muss man Flex Platinen halt wieder so machen wie früher als es die Features noch nicht gab und alles manuell in mech layern beschreiben. Sieht man dann natürlich nicht in der 3D Ansicht usw. Nervig, aber deswegen eine Pro Lizenz kaufen? Naja sorry Altium, eher nein, so selten wie das vorkommt.
Wühlhase schrieb: > Nein, aber du fragtest doch wozu man das braucht... ;) Punkt für Dich 1:0 Wühlhase schrieb: > Pinbelegung, Aderfarben, Verdrillung usw Pinbelegung kann ich ganz einfach von Altium nach Excel kopieren und ob ich die Farben und Verdrillung in Altium oder Excel einpflege macht keinen Unterschied. Wühlhase schrieb: > Kontrollmöglichkeit oder keine Warnung Da geb ich Dir Recht, aber ob das Altium kann steht noch aus. Würde man aber erwarten.
Zum als uebertrieben betrachteten Funktionsumfang von Altium. Altium hat das Platinen Layout laengst hinter sich gelassen. Schon seit vielleicht 8 Jahren geht es auch Richtung integrated Manufacturing. Zu jeden Bauteil kann ein pdf Datenblatt hinterlegt sein. Bedeutet man kann im Schema auf pdf druecken und es erscheint. Man kann sich zusammen mit dem Produktionslager eine gemeinsame Datenbank halten, dann wird schon beim Design das Lager angeschaut, allenfalls reserviert. Bedeutet, ein 1k 0.25W, 1206 ist ein eigenes schematisches Bauteil, nicht einfach RES1. Man kann auch Lieferanten und Hersteller, zB Digikey, und deren Teilenummern hinterlegen. Man kann heute auch gleich das aktuelle Lager bei Digikey, Mouser, Arrow, Motorola, Analog Devices .. zu einem hinterlegten Device anschauen. Highspeed Busse wurden erwaehnt. Differentiell, mit Laengenabgleich. Ich kann angeben, diese 4 Differentialbits muessen gleich langs sein, und das geschieht automatisch, im Layout. Abhangig vom Layerstack werden die Tracebreiten fuer eine vordefinierte Impedanz gerechnet. Wenn man also durch ein Via geht, und die Dicke oder der Wert des Dielektrikums aendert, aendert sich auch gleich die Leiterbahnbreite. Ein eingekauftes Zusatzpacket von CST, jetzt Simulia, kann kopplungen von Leiterbahnen rechnen. So kann man optimieren was wo nicht koppeln darf. Wirft man jetzt noch Kabel- und Harnesse hinzu, kann man an einem Stecker Verbindungen tauschen, um zB die Kopplung zu minimieren. Das wird dann auf das Harness uebertragen. Ich habe gehoert, aber nie benoetigt, dass auch Speisungen gerechnet werden. Also GND und Vcc sind nicht mehr einfach GND und Vcc, sondern mit Spannungsabfaellen versehen. So kann man an verschiedenen Verbindungen Stroeme vorgeben, und zusammenhaengend mit der Leiterbahnbreite und der Leiterbahnfuehrung wird gleich der Spannungsabfall an verschiedenen Punkten mitgerechnet. Ein Vergleich mit Kicad ist eher sinnlos. Braucht man diese neueren Goodies nicht, kann man bei einer aelteren Version bleiben. Ich bin noch bei 15.4. Die Subscription ist mir zu teuer, resp bringt mir nichts.
:
Bearbeitet durch User
Purzel H. schrieb: > Ich habe gehoert, aber nie benoetigt, dass auch Speisungen gerechnet > werden. Also GND und Vcc sind nicht mehr einfach GND und Vcc, sondern > mit Spannungsabfaellen versehen. So kann man an verschiedenen > Verbindungen Stroeme vorgeben, und zusammenhaengend mit der > Leiterbahnbreite und der Leiterbahnfuehrung wird gleich der > Spannungsabfall an verschiedenen Punkten mitgerechnet. Das wird das sog. Power Delivery Network Analyzer (kurz PDN) sein. Hat aber auch nur die verteilte Stromdichte errechnet und bunt im Layout angezeigt, nachdem man relativ umständlich die Stromsenken und -quellen in das Tool eintragen mußte. Und dann auch nur statisch, nix mit dynamischen Vorgängen, keine Temperatur (auch wenn die Ergebnisanzeige sowas reflexartig vermuten ließ). Ein allgemein relativ nutzloses Ding, das zwar von Altium recht heftig beworben wurde, aber von einer anderen Firma gebaut und als Plugin angeboten wurde. Wie gesagt eine relativ nutzlose Angelegenheit, dafür aber damals extrem teuer. 2.000€/a, kaufen war gar nicht.
Purzel H. schrieb: > Bedeutet, ein 1k 0.25W, 1206 ist ein eigenes > schematisches Bauteil, nicht einfach RES1 Bei mir in Kicad wird es zum speziellen Bauteil durch die Zuordnung einer Lagernummer. Durch ein leicht modifiziertes Python BOM Script kann die LagerSW das direkt importieren. Ich fand diese Starre Zuordnung in Altium immer ganz grausig. Ich designe oft ein Schematic noch ohne die finalen Bauteilwerte. Zum einen habe ich mehr Zeit während die PCB gefertigt wird und zum anderen ergibt sich manches erst am Prototypen. Purzel H. schrieb: > Schon seit vielleicht > 8 Jahren geht es auch Richtung integrated Manufacturing. Schon Protell99SE hatte diese Ansätze. Das ist also alles noch sehr, sehr viel älter. Aber es ist eben auch eine lange und traurige Geschichte von einer SW die angetreten ist fast alles zu können, dabei ständig über die eigenen Füsse stolpert und am Ende fast nichts mehr ohne Bugs und Workarrounds kann. Wir haben eingeführte Tools und einen Workflow der funktioniert. Das ist zwar alles nicht integraler Teil von Kicad, aber man muss nicht bei jedem Update zittern was die jetzt wieder kaputtmachen und dafür auch noch fett Kohle abdrücken.
Max M. schrieb: > Ich fand diese Starre Zuordnung in Altium immer ganz grausig. > Ich designe oft ein Schematic noch ohne die finalen Bauteilwerte. > Zum einen habe ich mehr Zeit während die PCB gefertigt wird und zum > anderen ergibt sich manches erst am Prototypen. Das ist, mit Verlaub, eine sehr seltsame Heranghehensweise. Normalerweise hat man schon feste Werte für Bauteile, während man den Schaltplan erstellt. Man kann diese ja nach einer Inbetriebnahme problemlos anpassen. Man sollte vielleicht noch erwähnen, dass es in Altium nicht die eine Library gibt. Es gibt imho mittlerweile 4 Möglichkeiten, die Bauteile zu Verwalten, wobei sogar Mischungen untereinander möglich, wenngleich regelmäßig nicht sinnvoll, sind. Purzel H. schrieb: > Schon seit vielleicht > 8 Jahren geht es auch Richtung integrated Manufacturing. Zu jeden > Bauteil kann ein pdf Datenblatt hinterlegt sein. Bedeutet man kann im > Schema auf pdf druecken und es erscheint. Dieses feature gibt es schon deutlich länger (1). Nur im PDF wird der Link erst seit der 15-er Version mitgepflegt und ist von dort heraus aufrufbar. (1) wenn man Datenbank libraries verwendet. Bei integrierten oder den einfachen Standard Libs kenne ich mich nicht so gut aus. Max M. schrieb: > dabei ständig über die eigenen > Füsse stolpert und am Ende fast nichts mehr ohne Bugs und Workarrounds > kann. Naja, ganz so schlimm ist es ja nun jetzt auch wieder nicht. Die Kernkompetenz, Schaltpläne zu erstellen und daraus Leiterplatten zu generieren, funktioniert auch heute noch weitgehend Problemlos und gewährt dem Entwickler viele Freiheiten. Detaillösungen funktionieren nicht gut, das mag ich zugeben aber das ist akzeptabel in meinen Augen. Max M. schrieb: > aber man muss nicht > bei jedem Update zittern was die jetzt wieder kaputtmachen und dafür > auch noch fett Kohle abdrücken. Man muss die Updates ja nicht installieren. Altium ist kein Betriebssystem. Wenn man mit einem Stand zufrieden ist, so kann man den bis in alle Ewigkeiten nutzen (Sofern man stand alone Lizenzen hat) Man kann sogar in unterschiedlichen Varianten parallel arbeiten, wenn man das will. Max M. schrieb: > Aber es ist eben auch eine lange und traurige Geschichte von einer SW > die angetreten ist fast alles zu können Das stimmt allerdings. Das Problem war schon immer, dass Detaillösungen nur in einem festen Setting funktionieren. Weicht man davon ab, ist das ein Problem. Ich hab mich z.B. 2010, als ich das System in der Firma eingeführt habe, sehr auf die Möglichkeit gefreut, Spice Simulationen direkt im Schaltplan durchführen zu können. Die Realität hat mich hier schnell eines besseren belehrt (Dieses Feature ist weitgehend nutzlos, wenn man eine Datenbank basierte Library verwendet, da die Spice Modelle an die Schematic Symbole gekoppelt sind. D.h. ich muss für jedes zu simulierende Bauteil ein eigenes Schematic Symbol anlegen, was der idee einer Datenbanklib gelinde gesagt, etwas widerspricht und dann kann der integrierte Spice kernel natürlich keine Fremdmodelle verwenden, wenn diese Verschlüsselt sind. ebenfalls ein show stopper an dieser Stelle) Andere Funktionen, bei denen Altium zu den Pionieren zählt (z.B. das einbinden von step Modellen ins System, wobei einbinden meint, die tatsächlichen Dimensionen zu beachten und nicht nur ein Grafisches Element an den Footprint zu koppeln, die Umsetzung der Starr-Flex Geschichte, zumindest wie es in der 19 / 20 war incl. der Möglichkeit, das gefaltete Board als Step Datei auszugeben (welches dann in der Mechanikabteilung eingebunden werden kann) sind definitiv Meilensteine, welche auch heute noch nicht von allen Mitbewerbern gleich gut umgesetzt werden. Zum Thema Starrflex: Ich habe nun nochmal etwas herumprobiert: Altium hat hier tatsächlich den Workflow massiv geändert zwischen der 20 und der 21-er Version. Früher musste man entsprechende Bereiche des Boards auswählen, welche dann einem Stack-teil zugeordnet wurden. Bei neueren Versionen ist die ganze Platine eine board-region, welche man zerschneiden und anschließenddie entstandenen Teile den entsprechenden Stackupbereichen zuweisen muss. Danach kann man Biegelinien einfügen, welche sich mit Biegeradius und Biegewinkel definieren lassen. Ich muss also meine Aussage von weiter oben, dass das nicht mehr im Stand alone funktioniert, revidieren. Es geht, aber wird vollkommen anders gehandhabt als bisher.
Christian B. schrieb: > Max M. schrieb: >> Ich fand diese Starre Zuordnung in Altium immer ganz grausig. >> Ich designe oft ein Schematic noch ohne die finalen Bauteilwerte. >> Zum einen habe ich mehr Zeit während die PCB gefertigt wird und zum >> anderen ergibt sich manches erst am Prototypen. > > Das ist, mit Verlaub, eine sehr seltsame Heranghehensweise. Das dachte ich auch, als ich das gelesen habe. Ich betrachte den Schaltplan als den Teil, in dem jegliche elektrische Auslegung stattfindet, da will ich den Widerstand final festlegen. Wobei ich dennoch der Meinung bin, daß Max schon weiß was er tut, auch wenn es mir absonderlich erscheint. Aber vielleicht kann Max das ja mal etwas näher beschreiben. Christian B. schrieb: > Ich hab mich z.B. 2010, als ich das System in der Firma > eingeführt habe, sehr auf die Möglichkeit gefreut, Spice Simulationen > direkt im Schaltplan durchführen zu können. Die Realität hat mich hier > schnell eines besseren belehrt (Dieses Feature ist weitgehend nutzlos, > wenn man eine Datenbank basierte Library verwendet, da die Spice Modelle > an die Schematic Symbole gekoppelt sind. D.h. ich muss für jedes zu > simulierende Bauteil ein eigenes Schematic Symbol anlegen, was der idee > einer Datenbanklib gelinde gesagt, etwas widerspricht Ich meine, daß es für Simulationsmodelle einen eigenen Parameter wie bei Footprints gibt. Ich hatte damals allerdings beschlossen, diese nicht zu verwenden, weil ich damals noch keine automatisierte Lösung für das Erstellen vieler Spicemodelle hatte. Aber ich arbeite daran, daß zu ändern. Dauert aber wohl noch etwas... Es gab neulich auch mal ein Webinar von Altium zur Spicesimulation, die haben da anscheinend einiges verbessert. Christian B. schrieb: > und dann kann der > integrierte Spice kernel natürlich keine Fremdmodelle verwenden, wenn > diese Verschlüsselt sind. ebenfalls ein show stopper an dieser Stelle) Da kann aber Altium nichts dafür, wenn z.B. TI die eigenen Modelle verschlüsselt sodaß man sie nur noch in deren Tina-Simulation verweden kann. Aus diesem Grund vermeide ich Teile von TI normalerweise, aber bei einigen Spezial-OPVs kommt man um diese Schandfirma leider nicht herum.
Christian B. schrieb: > Das ist, mit Verlaub, eine sehr seltsame Heranghehensweise. > Normalerweise hat man schon feste Werte für Bauteile, während man den > Schaltplan erstellt. Man kann diese ja nach einer Inbetriebnahme > problemlos anpassen. So seltsam ist das nicht und was bei Dir normal ist, muss für andere nicht gelten. Was meinst Du was ich schon an Unmengen falsch dimensionierter Bauteile in fremden Schaltungen gefunden habe, weil die Herren Entwickler nach vielen Stunden Berechnungsorgie und Simulation so überzeugt von sich waren, das der Prototyp nie anständig durchgemessen wurde. Du selbst sagst das man Werte ja später anpassen kann. Wo ist jetzt also der große Unterschied? Ich brauche doch nicht 7324+-X Widerstände in der Lib anlegen um die E96 Reihe in allen möglichen FP, TK und Toleranzen zu haben, von denen ich die meisten nie brauchen werde. Ich brauche EIN Widerstandssymbol. Dem ordne einen Footprint, einen Wert und letztendlich eine Lagernummer zu, die den dann eindeutig mit Hersteller und Typ definiert. Dieses stark sequentielle Vorgehen kostet enorm Zeit. 'Ich berechne alle Werte unter Berücksichtigung der Lagerliste, melde alle neue benötigten Bauteile an den CAD Sklaven der als einziger Bauteile erstellen darf, warte darauf das der das irgendwann mal getan hat, warte auf den Validierungsprozess, warte auf die Rückmeldung, setze den ein, mache das Layout, gebe die PCB in Auftrag' Den Fall habe ich ebenfalls erlebt und das ist keine Freude. Aber da scheiden sich die Geister. Die einen sehen jeden Freiheitsgrad beim CAD als Möglichkeit Fehler zu machen. Ich sehe Freiheiten als Möglichkeit Dinge sehr schnell zu machen. Ziel ist nicht ein fehlerfreier Prototyp nach langer Zeit, sondern ein schneller Prototyp in kurzer Zeit. Prototypen sind doch ohnehin nie fehlerfrei.
Wühlhase schrieb: > Da kann aber Altium nichts dafür, wenn z.B. TI die eigenen Modelle > verschlüsselt sodaß man sie nur noch in deren Tina-Simulation verweden > kann. Aus diesem Grund vermeide ich Teile von TI normalerweise, aber bei > einigen Spezial-OPVs kommt man um diese Schandfirma leider nicht herum. Natürlich ist das nicht die Schuld von Altium, aber es betrifft auch LT und Würth Komponenten. Wühlhase schrieb: > Ich meine, daß es für Simulationsmodelle einen eigenen Parameter wie bei > Footprints gibt. es gibt derer 6... Aber es funktionierte nicht. Nachdem sich die Softwareentwickler bei Altium selbst darum gekümmert haben, ging dann zumindest die Einbindung eines 2 poligen Bauteils. Aber bei OPVs war wieder Schluss, denn für deren Einbindung hätte ich das Simulationsfile mit dem schematic Symbol in der entsprechenden Library verheiraten müssen. Über die Datenbank verlinken funktionierte bei geteilten Parts einfach gar nicht. Wenn ich nun aber 10 OPVs habe, welche alle den selben Schematic Aufbau haben, wieso sollte ich dann 10 verschiedene Symbole anlegen? Der Sinn einer Datenbank ist ja, dass man gleiche Teile möglichst oft widerverwendet und nicht für jedes Teil alles neu erstellen muss. Aber wie gesagt, unterm Strich ist das alles auch gar nicht so praktisch, wie ich mir das vorgestellt habe. den zu simulierenden Schaltungsteil schnell im LT Spice neu aufzubauen, ist halt doch einfacher als die komplette Lib zu pflegen. Max M. schrieb: > Ich brauche EIN Widerstandssymbol. > Dem ordne einen Footprint, einen Wert und letztendlich eine Lagernummer > zu, die den dann eindeutig mit Hersteller und Typ definiert. so ist das bei mir auch. Aber ich hab nicht die gesammte E96 reihe angelegt sondern nur die Bauteile, die wirklich in Verwendung sind, das sind deutlich weniger Max M. schrieb: > Dieses stark sequentielle Vorgehen kostet enorm Zeit. > 'Ich berechne alle Werte unter Berücksichtigung der Lagerliste, melde > alle neue benötigten Bauteile an den CAD Sklaven der als einziger > Bauteile erstellen darf, warte darauf das der das irgendwann mal getan > hat, warte auf den Validierungsprozess, warte auf die Rückmeldung, setze > den ein, mache das Layout, gebe die PCB in Auftrag' > Den Fall habe ich ebenfalls erlebt und das ist keine Freude. Naja, da ich selbst Herr über die Datenbank bin, ist die Struktur hier recht einfach, brauch ich ein neues Bauteil, liegt es nur an meinem Elan, wann dieses zur Verfügung steht, wobei wirklich für den Universaleinsatz freigegeben wird es dennoch erst, wenn mindestens ein Projekt damit erfolgreich die Erstinbetriebnahme durchlief. Max M. schrieb: > Ich sehe Freiheiten als Möglichkeit Dinge sehr schnell zu machen. > Ziel ist nicht ein fehlerfreier Prototyp nach langer Zeit, sondern ein > schneller Prototyp in kurzer Zeit. das muss sich ja nicht ausschließen. Das Anlegen eines neuen Widerstandswertes dauert keine 30 sekunden, Öffnen der DB und speichern inklusive. Max M. schrieb: > Was meinst Du was ich schon an Unmengen falsch > dimensionierter Bauteile in fremden Schaltungen gefunden habe, weil die > Herren Entwickler nach vielen Stunden Berechnungsorgie und Simulation so > überzeugt von sich waren, das der Prototyp nie anständig durchgemessen > wurde. Nagut, das muss man sich ja nicht auf die Fahnen schreiben. Bei uns läuft das eben nicht so. Man hat Startwerte und kann dann, spätestens bei der Verifizierung eine Änderung anschubsen. Wenn man das nicht tut, muss es wohl auch mit den möglicherweise nicht idealen Bauteilwerten funktionieren.
:
Bearbeitet durch User
Max M. schrieb: >> Normalerweise hat man schon feste Werte für Bauteile, während man den >> Schaltplan erstellt. Max M. schrieb: > Ich brauche doch nicht 7324+-X Widerstände in der Lib anlegen Das sind zwei unterschiedliche Proble und sollten nicht zusammengeworfen werden. Das Eine hat mit dem Anderen nicht zu tun. Das bei der Schaltplanentwicklung noch nicht alle Werte feststehen kenne ich auch. Wir haben Verstärkerstufen bei denen die Gain ohne Simulation, ohne Tests, ohne Messungung vorher nicht genau vohersehbar sind. Ich vermeide es aber stark einfach überall 1k einzubauen. Ich bespreche das mit den Kollegen ob man eine Simulation oder Schätzung machen kann, damit ich ansatzweise schon mal richtig liege. Zur Bauteillibrary Frage. Altium ist da offen, einige verfolgen den unique Ansatz jedes Bauteil im Lager ist ein Bauteil in der Lib. Andere arbeiten eher generisch ein Widerstand, Kondensator, OP in der Lib und später Werte dran schreiben. Ich habe ein Mix. Die Kleinteile wie Widerstand,Kondensator usw. sind unified/generisch. Ich habe einen 1206 Widerstand in der Lib, der Wert (Comment) wird im Schaltplan drangeschrieben. Bauteile wie DCDC Wandler, OPs usw. sind einzigartig und genau mit Bestellnummer/Herstellernummer in der Lib eingepflegt.
Taz G. schrieb: > Zur Bauteillibrary Frage. Altium ist da offen, einige verfolgen den > unique Ansatz jedes Bauteil im Lager ist ein Bauteil in der Lib. Andere > arbeiten eher generisch ein Widerstand, Kondensator, OP in der Lib und > später Werte dran schreiben. Den Mix Ansatz habe ich natürlich auch unter Kicad. Es gibt immer Teile bei denen es genau dieses IC in genau diesem FP sein muss, weil nix anderes passt. Der Unique Ansatz hört sich auch erstmal super an. Alles was da ist, ist geprüft und in der Lagerhaltung. Mit einer Unternehmensweiten DB bekommt man aber ohne zentrale Bauteilerstellung und Validierung einen furchtbaren Wildwuchs. Und schon hat man den einen Flaschenhals, dem man seine Bauteile meldet die man braucht und ab da nix mehr am Schaltplan tun kann. Und das dauert dann von 2Std bis zu 3W. Das Ergebniss gibt einem scheinbar recht. Die Zahl der Fehler sinkt. Die Produktivität sinkt aber noch viel stärker und das kostet dann 10 mal mehr als mal ein paar Fädeldrähte am Prototypen. Super. Mit ein paar Wochen Verzögerung habe ich dann nur noch 3 Fehler am Prototypen statt 5. Hätte mich am Prototypen 30min gekostet ohne den ganzen Firlefanz.
Max M. schrieb: > melde > alle neue benötigten Bauteile an den CAD Sklaven der als einziger > Bauteile erstellen darf, warte darauf das der das irgendwann mal getan > hat, warte auf den Validierungsprozess, warte auf die Rückmeldung, setze > den ein, mache das Layout, gebe die PCB in Auftrag' > Den Fall habe ich ebenfalls erlebt und das ist keine Freude. Das lässt sich sogar noch steigern. :-( Vor langer Zeit entwarfen wir bei einem früheren Arbeitgeber eine Baugruppe, bei der von vornherein schon ziemlich klar war, dass zu einem späteren Zeitpunkt zwei größere SRAM-Bausteine eingesetzt werden sollten. Diese besaßen auch dieselbe Pinbelegung wie die kleineren Bausteine, abgesehen von zwei zusätzlichen Adressleitungen. Da unser Hardwareentwickler und die Layouterin keine Berechtigung besaßen, selbst Bauelemente anzulegen oder zu editieren, musste alles über die zentrale Bauelementestelle in der Konzernzentrale laufen. Dort gab es die Vorgabe, dass NC-Pins (not connected) nicht im Schaltplansymbol auftauchen durften, so dass es nicht möglich war, die beim kleineren SRAM unbelegten Adressleitungen in weiser Voraussicht anzuschließen. Und um ein Schaltplansymbol für das größere RAM anzulegen benötigte die Bauelementestelle wiederum die Freigabe durch den Einkauf. Der Einkauf lehnte diesen Antrag aber ab, weil das größere SRAM teurer wäre. Außerdem hätte dafür ein Vertreter des Herstellers zuvor persönlich anrücken müssen, um das größere SRAM vorzustellen. Und dafür gab es keine Notwendigkeit. Also gab es auch keine interne Freigabe für das neue Schaltplansymbol. Im Laufe des Projektes stellte sich dann, wie abzusehen war, heraus, dass das kleine SRAM nicht ausreichte. Da dieses aber nun schon in Stein gemeißelt war, weil die Materialbeschaffung für die Serienproduktion schon lief, konnte auch nicht mehr auf das größere SRAM gewechselt werden. Also wurden in einer neuen Layoutversion mehrere SRAM-Bänke realisiert. Als die Serienproduktion dann irgendwann zunächst einwandfrei lief, gab es ab einem bestimmten Tag dann 100% Ausfall im Fertigungstest. Ich bekam eine der defekten Baugruppen auf den Tisch und stellte fest, dass dort etliche Teile fehlten, d.h. unter anderem alle SRAMs bis auf eines. Irgendein dümmlicher kaufmännischer Controller hatte die Aufgabe, die Stücklisten aller Produkte auf Redundanzen zu prüfen. Dabei fiel ihm auf, dass in der Stückliste für das besagte Produkt mehrere baugleiche SRAMs und Flashes bestückt wurden, deren Preise oberhalb einer (willkürlich gesetzten) Schwelle lagen. Der Controller fragte dann irgendeinen Hardwareentwickler in der Konzernzentrale, ob diese redundanten Bauteile überhaupt benötigt würden. Der Hardwareentwickler bestätigte dann, dass die Baugruppe aus Hardwaresicht auch mit nur einem SRAM und Flash funktionieren, ohne sich jedoch darüber auszulassen, dass die Firmware dann nicht mehr läuft. Das Resultat: Ein ganzes Fertigungslos ging in die Hose. Diese Kosten wurden dann unserem Kieler Standort aufgebürdet, an dem die Firmwareentwicklung stattfand, denn schließlich sei das ja ein Firmwarefehler. Es ging bei der ganzen Sache (Pinbelegung, Minderbestückung) auch überhaupt nicht um die Technik, sondern ausschließlich um die wirklich harten Kämpfe zwischen verschiedenen Standorten im Konzern.
Wenn man in einem großen Konzern arbeitet, dann ist das so, da dauert es halt. Aber gerade dort kann man doch erst recht nicht mit Schaltplänen ankommen, die einen Haufen TBD Werte enthalten. Mir persönlich ist es wichtiger, eine stimmige Datenlage am Ende zu haben, auch wenn der ein- oder andere Bauteilwert vermutlich erst während der Inbetriebnahme final festgelegt wird. Das anzupassen ist eine Sache von wenigen Augenblicken und man kann es sogar übers Variantenmanagement erledigen und so die einzelnen Entwicklungsstände nachvollziehbar halten. Aber eine BOM mit 20 Widerständen drin, wo überall tbd (to be defined) steht, das ist doch Chaos pur. Außerdem sitzt man dann nochmal ne Stunde mindestens und räumt die BOM auf, bevor die Platine in die Serie gehen kann und wehe dem, der dann in der Zeile verrutscht und aus einem 49,9k einen 0Ohm widerstand macht. Sorry, diese Arbeitsweise hab ich durch, mit Egale damals gings nicht anders und ich war Heilfroh, dass ich eine Bauteildatenbank nutzen konnte die mir die Bauteile eindeutig definiert zur Verfügung stellt. Klar führt das dazu, dass man bei jedem größeren Neuprojekt auch einen Sack voll Bauteile anlegen muss, aber das muss ich im Designprozess sowieso tun, wieso nicht gleich am Anfang? So kann ich nach erfolgter Inbetriebnahme den Datensatz direkt freigeben, weil ich weiß, dass der Stimmig ist. Unterm Strich sind wir halt alle Individualisten, jeder Weg hat seine Vor- und Nachteile. Jeder muss für sich entscheiden, was für ihn sinnvoller ist. Ein Schaltplan voll leerer Widerstände währe es in meinem Fall sicher nicht. Aber ich habe auch selten nur ein Projekt sondern in der Regel mehrere Parallel in der Pipeline. Teilweise bestücken wir die Prototypen dafür selbst, müssen also die Bauteile auch noch beschaffen, da den Überblick zu behalten, wenn man die Bauteilwerte nicht vorher festlegt, ist nahezu unmöglich. Mein Job ist so schon stressig genug, da muss ich mir nicht noch selbst Knüppel zwischen die Beine legen.
Andreas S. schrieb: > Das lässt sich sogar noch steigern.......... LOL, einfach Klasse die Story. Musste so was von in mich hinein lachen (weil kommt einem irgendwie bekannt vor).
Max M. schrieb: > Mit einer Unternehmensweiten DB bekommt man aber ohne zentrale > Bauteilerstellung und Validierung einen furchtbaren Wildwuchs. Das ist aber ein Problem mangelhafter Vorgaben und Anforderungen. Sinnvolle Vorgaben, wie ein Bauteil zu sein hat, und dann geht das. Andreas S. schrieb: > Das lässt sich sogar noch steigern. :-( Vor langer Zeit... Alter, das tut ja schon beim Lesen weh. Wie hält so eine Drecksbude denn die Leute bei der Stange, da müssen die Entwickler doch in Scharen davonlaufen? Man verbringt doch immerhin einen Großteil seins Tages in diese Sauladen, wer tut sich diesen Scheiß denn freiwillig an?
Wühlhase schrieb: > Alter, das tut ja schon beim Lesen weh. Wie hält so eine Drecksbude denn > die Leute bei der Stange, da müssen die Entwickler doch in Scharen > davonlaufen? > Man verbringt doch immerhin einen Großteil seins Tages in diese > Sauladen, wer tut sich diesen Scheiß denn freiwillig an? Du hast auch noch nie in einem Großkonzern gearbeitet...
Wühlhase schrieb: > Sinnvolle Vorgaben, wie ein Bauteil zu sein hat, und dann geht das. Klar. Hab ich erlebt. Hast Du mal in einer größeren Fa. gearbeitet? Du bekommst Vorgaben. Sogar ganz viele davon. Aber Andreas hat je gerade sehr plastisch beschrieben zu was diese Vorgaben dann führen. Und das ist nicht übertrieben. Genau so läuft das in vielen Konzernen und selbst bei manchem Mittelständler bei dem man glaubt der sei doch garnicht groß genug um genug Schwachköpfe für diesen Todespogo anzusammeln. Doch, es reichen zur Not eine Handvoll selbstverliebter Idioten dafür. Gut kann es nur sein wenn es in einer Führungsriege ausgebrütet wurde die nur den befördert der ihnen zu Willen ist, den fürchtet der besser ist als sie und die Einigkeit nur in der Frage erreichen wer auf dem Weg nach oben nur in vereinter Aktion zur Seite zu räumen ist. Was der Techniker sagt, ist nicht mehr als das Grunzen einen Schweines das man mästet um es zu schlachten. Dem muss man sagen was er zu tun hat, weil der ist ja kein Manager. Und so sagen einem dann andauern Menschen die die Thematik nicht verstehen was und wie man das zu tun hat. Jeder Versuch Fehler zu korrigieren wird als Meuterei und persönlicher Angriff auf den Führungsoffizier verstanden und dementsprechen sanktioniert. Wühlhase schrieb: > wer tut sich diesen Scheiß denn freiwillig an? Wer redet denn von freiwillig? Da sorgen dann schon die 'flachen Hierachien' für, das man das aushält. Flach beschreibt in dem Fall das Niveau mit dem eiskalt von ganz oben bis ganz unten durchregiert wird. Von unten nach oben ist es natürlich vollkommen undurchdringlich und bereits der Versuch kann sehr unangenehme Folgen haben. Entweder es läuft ganz genau so wie sich irgendein Sesselfurzer vom Dienst weit über dir überlegt hat, oder es steht dir frei zu gehen, gegangen zu werden oder mit so viel Scheiße übergossen zu werden das du mit dem Schlucken nicht hinterherkommst. Deswegen bin ich dann auch weg da und habe seit dem wieder viel Spaß an meiner Arbeit.
Wühlhase schrieb: > Alter, das tut ja schon beim Lesen weh. Wie hält so eine Drecksbude denn > die Leute bei der Stange, da müssen die Entwickler doch in Scharen > davonlaufen? Hatte ich erwähnt, dass dies kurz vor der Aufnahme meiner Selbstständigkeit passierte? > Man verbringt doch immerhin einen Großteil seins Tages in diese > Sauladen, wer tut sich diesen Scheiß denn freiwillig an? Sehr viele Mitarbeiter in Großunternehmen sind derart abgestumpft, dass sie sich nicht mehr daran stören. Das kann lange Zeit gutgehen. Irgendwann wird solch ein Laden ("too big to fail") mit Subventionen und politischen Aufträgen am Leben gehalten, hat aber seine Marktbedeutung verloren. Und wenn er dann final den Bach runtergeht, will niemand etwas geahnt haben. Insbesondere die vielen kleinen Rädchen behaupten dann: "Und dabei habe ich doch jahrzehntelang Dienst nach Vorschrift gemacht, ohne nach rechts oder links zu schauen!!!!eins!!!elf11!"
Max M. schrieb: > Hast Du mal in einer größeren Fa. gearbeitet? > Du bekommst Vorgaben. Sogar ganz viele davon. > Aber Andreas hat je gerade sehr plastisch beschrieben zu was diese > Vorgaben dann führen. Ich sprach ja auch von sinnvollen Vorgaben. Ich habe sowas mal für eine Firma erstellt, nicht nur bezüglich der Bauteilerstellung, sondern den ganzen Entwicklungsprozess rund um Altium. Das war zwar nur eine sehr kleine Firma, aber ich denke ich weiß ein wenig wovon ich rede. Aber sowas braucht halt Zeit, viel Zeit, man muß wissen wie die Leute arbeiten und viel mit ihnen reden, und muß es testen. Man muß nachdenken wo es Stolperfallen geben kann und könnte, und muß sich dafür eine Lösung offenhalten. Selbstverliebt irgendein Ablaufdiagramm zu erstellen, am besten noch eine halbe Stunde vor Feierabend, reicht da nicht. Dann kommt so ein Unsinn raus wie von Andreas beschrieben.
Wühlhase schrieb: > Das war zwar nur eine sehr kleine Firma, aber ich denke ich weiß ein > wenig wovon ich rede. Nein, weil Du nicht weißt wie es in einer großen Fa. abläuft. DU erstellst da garnichts an Vorgaben. Vorgaben kommen von oben und oben sitzen Leute die keine Ahnung vom Entwickleralltag haben. Denn gute Entwickler bleiben Entwickler und werden keine Chefs. Es sind die technischen Pfeifen mit Dipl. die es nach oben schaffen. Alleine die Vorstellung das jemand unter der eigenen Stufe vor irgendetwas mehr Ahnung haben könnte, ist den meisten Führungskräften unbekannt. Alles unter denen ist Viehzeug das mit harter Hand geführt werden muss. Und obwohl die ganzen Kaufleute nur einen Job haben weil die Techniker Produkte bauen, wird der ganze Laden dann so strukturiert das er die Bedürfniss der Kaufleute erfüllt, denn die Kaufleute haben die absolute Macht. Niemand von denen fasst noch einen Lötkolben an oder realisiert Schaltungen. Aber sie bestimmen über fast jedes Detail deiner Arbeit und machen dich dann dafür verantwortlich wenn aufgrund deren Inkompetenz dein Output sinkt. Versuchst du aber die Regeln deinen Bedürfnissen anzupassen ist das ein direkter Angriff auf ihre Führungskompetenz und hat härteste Gegenreaktionen zur Folge. Selbst wenn die Kündigungen aus der Technik massiv zunehmen und ganze Abteilungen aufhören zu existieren, gibt es kein Umdenken. Da wird dann von Fachkräftemangel geredet und das man ja froh sein kann diese Querulanten los zu sein. Andreas S. schrieb: > Hatte ich erwähnt, dass dies kurz vor der Aufnahme meiner > Selbstständigkeit passierte? Wie sich die Geschichten gleichen 😂
Max M. schrieb: > Nein, weil Du nicht weißt wie es in einer großen Fa. abläuft. Ich kenne große Firmen. Es geht nicht in jeder Firma so zu, wie du es beschreibst, ich habe auch weitaus bessere Beispiele erlebt.
Wühlhase schrieb: > Ich kenne große Firmen. Es geht nicht in jeder Firma so zu, wie du es > beschreibst, ich habe auch weitaus bessere Beispiele erlebt. ich kann Max's Beitrag gut nachvollziehen. Was er beschreibt, dürfte vermutlich in den meisten Firmen der Alltag sein. Das liegt einfach daran, dass die Firmenleitung selten Techniker sind sondern idR WBLer und dementsprechend haben die natürlich einen Faible für den Vertrieb. Und wenn man mal ehrlich ist: der Vertrieb bringt schlussendlich das Geld womit die Techniker bezahlt werden. Je nach Firmenkultur ist es dann halt so, dass unterschiedliche Abteilungen unterschiedliche Vorgaben haben. Das kann vom Großkonzern, wo jeder Entwickler ein Korsett aus Vorgaben hat, was ihm in einen kleinen Tunnel noch eine partielle Aufgabe erledigen lässt, eingefasst von bergeweise Papieren und Meetings bis hin zu relativ freier Hand bei wichtigen Entscheidungen gehen, wobei bei letzterem der Techniker eine hohe Variabilität zeigen muss (und ein dickes Fell braucht, da er natürlich für Misserfolge getadelt wird.). Irgendwo dazwischen werden sich die meisten Firmen widerspiegeln nach meiner Erfahrung.
Ich behaupte ja auch nicht, daß Max völlig danebeliegt. Im Gegenteil, ich kann mir gut vorstellen daß er in den meisten Fällen Recht hat. Poser und Luftpumpen heuern ungern in kleinen Firmen an...es sei denn, es ist ihre eigene Firma. Meiner Erfahrung nach hängt es aber sehr stark vom Abteilungsleiter ab, wie gut du als Angestellter in einem Konzern arbeiten kannst. Es gibt Abteilungsleiter mit Eiern, die halten den Druck von oben von ihren Leuten lieber fern, und es gibt solche, die reichen den einfach weiter um dem nicht selber standhalten zu müssen. Und dann ist es noch ein Unterschied ob die Konzernniederlassungen nur aus billig zugekauften Konkurrenten bestehen, oder ob die wirklich zusammengehören, also entweder direkt vom Mutterkonzern gegründet wurden oder anständig integriert wurden und lange reingewachsen sind. Was Andreas da beschreibt klingt wie ein bunt zusammengekaufter Haufen, und die oberste Heeresleitung ist der Meinung daß man mehr erreicht, wenn alle gegeneinander konkurrieren. Mein Punkt ist lediglich, daß es auch anders gehen kann. Nicht überall, nicht in jeder Firma, und schon gar nicht mit jedem Mitarbeiter insbesondere im administrativen Bereich. Und vor allem ging es mir darum daß es möglich ist, Designprozesse zu erstellen die weitaus besser funktionieren als daß, was Andreas da schilderte.
Christian B. schrieb: > Und wenn man mal ehrlich ist: der Vertrieb bringt schlussendlich das > Geld womit die Techniker bezahlt werden. Das ist ein oft gehörtes, aber dummes Argument. Das letztendlich aus einer Bemühung Geld generiert wird liegt an einer Wertschöpfungskette. Was hätte denn der Vertriebler zu vertreiben, wenn der Techniker nicht Geräte bauen würde? Der Vertriebler kann nix spezielles. Der kann labern und verspricht das blaue vom Himmel und wenn der mal wieder unhaltbare Versprechungen gemacht hat, weil er so viel Ahnung vom Gerät hat wie eine Kuh vom Rückenschwimmen, hat der geniale Vertriebler den Auftrag an Land gezogen und der Dumme Entwickler war zu unfähig das Gerät nach Kundenwunsch zu modifizieren. Heute verkauft der Vertriebler Kühlschränke, morgen Bauteile, übermorgen Motorroller. Bauen kann er nichts davon und der weiß kaum mehr als im PR Flyer steht. Dazu braucht es jeweils Spezialisten in ihren Gebiet, die viele Jahre Erfahrung haben. Der Vertriebler bekommt aber die Fette Kohle und ist das Schärfste neben dem Senf. Dem Entwickler wird gesagt er würde ja nur Kosten verursachen, denn das Geld würde ja schliesslich im Vertrieb verdient werden. Okay, dann können die ja Backsteine verkaufen oder Lebensversicherungen, wenn Entwickler doch nur unwertes Leben sind.
Max M. schrieb: > Das letztendlich aus einer Bemühung Geld generiert wird liegt an einer > Wertschöpfungskette. Mir ist das schon klar, aber einem BWL Firmenchef augenscheinlich oft nicht. Der zählt die Techniker zu den eh-da Kosten und das wars. und da die ja eh schon immer da sind, können die auch das entwickeln, was der Vertriebler dann verkaufen kann. Wenn der Vertriebler dann vorher gefragt wird, was er denn gut verkaufen kann und man daraufhin ein Gerät entwickelt, so kann es gut sein, dass dann, wenn das Gerät fertig ist der Spruch kommt: Das lässt sich so aber nicht verkaufen, denn da muss das, das und das anders werden. Wobei das, das und das am Ende quasi eine Neuentwicklung darstellen.
Max M. schrieb: > Selbst wenn die Kündigungen aus der Technik massiv zunehmen und ganze > Abteilungen aufhören zu existieren, gibt es kein Umdenken. > Da wird dann von Fachkräftemangel geredet und das man ja froh sein kann > diese Querulanten los zu sein. Interessiert lese ich diesen Threat. Interessant finde ich, dass Ihr von (Groß)...Konzernen redet... Hier ist es eine 30+ Mann Firma. Die Firma funktioniert genauso, wie beschrieben, aber zusätzlich werden vorhandene Fachkräfte mutwillig beliebig vergrault und dann wird so rumgejammert: keine Fachleute mehr zu kriegen. Ich kann nur sagen, daß ich Kununu damals nicht kannte... ....
Sehr interessant, ueber die verschiedenen Entwicklungskontexte und Arbeitfluesse lesen zu duerfen. Ich arbeite mit Altium, war selbstaendig bevor ich in diesen Konzern stiess. Da ich in diesem Konzern quasi eine (Infrastruktur-)Abteilung fuer mich selbst bin, kann ich alles machen wie ich mag. Meist nur Prototypen, wenig Serien. Also Schema, Layout, Einkauf, Aufbau, testen, simulieren, Software fuer den PC, Firmware auf der Hardware, Gehaeuse, alles. Ich arbeite mit getrennten Schema und Footprint Libraries, weil es immer etwas zu editieren gibt. Alle Widerstande/Kondenser heissen erst mal Res1/Cap1. OpAmps heissen Op1. Beim Schema Zeichen wird ein Footprint zugewiesen. Falls noetig ein Wert. zB ein Pullup an Logik kann Res1 bleiben. Ein Abblock Kondenser bleibt Cap1. Die nehm ich dann beim Bestuecken nach Gutduenken aus der Grabbelkiste. OpAmps sind etwas anspruchsvoller. Aber oft auch aus der Grabbelkiste, allerdings vermerke ich den Typ. Simulation brauche ich eigentlich nicht. Und falls doch, dann kann Altium die sowieso nicht. Ah, ja, ich setze ein Bauteil erst in einem Design ein, wenn ich's auf dem Tisch habe. Zu oft geschah es, dass ein neu verbautes Bauteil, vielleicht schon abgekuendt, nicht mehr lieferbar, oder grad nicht lieferbar war. Der Distributor hat's normal an Lager ausgewiesen, beim Hersteller war's schon abgekuendigt. Und als die Leiterplatte dann auf dem Tisch lag, war das Bauteil nicht mehr erhaeltlich. Solche Verzoegerungen gehen in meinem Umfeld nicht. Ah, ja. Sehr wichtig. Ich mache nicht Elektronik, ich bringe Loesungen. Ja, Elektronik ist auch dabei. Ja, die Spezifikationen mache ich auch selbst, in Absprache mit dem Anwender. Den interessiert in der Regel nichts im Detail. Die Loesung ist dabei nicht die Elektronik dem Problem anzupassen, sondern das Problem der einfachst moeglichen Elektronik. Denn es soll ja schnell gehen. Heisst ich re-spezifiziere das Problem.
Purzel H. schrieb: > Heisst ich re-spezifiziere das Problem. Ich hab morgen eine Arbeitsbesprechung. Ich nehm das mal mit.
>Purzel H. schrieb: >> Heisst ich re-spezifiziere das Problem. > >Ich hab morgen eine Arbeitsbesprechung. Ich nehm das mal mit. Aber sicher. Die Anwender haben immer seltsame Ideen. zB ueberzogene Genauigkeitsanforderungen. Muss eine Temperatur unbedingt auf 1 Grad genau sein. Geht auch auf 1 Grad stabil ? Natuerlich wollten sie 0.1 Grad ... Ich diskutiere auch was geschehen soll, wenn der Strom ausfaellt. Oder dass 3% weniger von irgendwas 20% Kosten spart. Muss die Pumpe 2 Bar bringen, gehen 1.2 Bar nicht auch ?
:
Bearbeitet durch User
Purzel H. schrieb: > Die Loesung ist dabei nicht die Elektronik dem Problem > anzupassen, sondern das Problem der einfachst moeglichen Elektronik. > Denn es soll ja schnell gehen. schnell gehen muss es immer. Allerdings gibt es halt äußere Zwänge, wie bei uns die Herstellung von Medizinprodukten, die eine derartige Arbeitsweise prinzipiell nicht zulassen. Für eine kleine Machbarkeitsstudie am Rande würde das zwar schon gehen, aber erfahrungsgemäß wird aus jeder 2. Machbarkeitsstudie recht schnell ein Serieneinsatz und das würde bei dieser Arbeitsweise bedeuten: ich muss alles doppelt machen, einmal schludrig zusammenpfeifen, ausprobieren, dann nochmal alles in schön fertig stellen. Da mach ich es lieber gleich in schön und passe dann die 2-5 Werte in Bauteilen an. Hat sich am Ende als weniger Fehleranfällig erwiesen, wenngleich es vielleicht ab und an etwas länger dauert. Aber eine Vorserie aus 20 Platinen wegen eines Schusselfehlers wie falschem Footprint wegwerfen zu müssen kostet deutlich mehr (Zeit und Geld) als ich für einen schönen, schlussendlich doch nicht weiter verfolgten Ansatz aufwenden muss. Naja, jeder muss halt seinen Workflow finden, mit dem er am besten zurecht kommt. Ich hab keine Zeit alles doppelt zu machen.
Christian B. schrieb: > bei uns die Herstellung von Medizinprodukten, die eine derartige > Arbeitsweise prinzipiell nicht zulassen. Ich entwickel für Luftfahrt und da geht das ganz hervorragend. Medizin und Automobil sind sehr ähnlich aufgestellt vom Regelwerk und beeinflussen sich gegenseitig, weil sie alle das gleiche erreichen wollen. Solange etwas in der Entwicklung ist, ist es diskutierbar. In der Entwicklung ist erstmal alles erlaubt. Erst wenn es zum Erstmuster wird und durch die Zulassung muss, gelten all die schönen Regeln die es Luftfahrtkonform machen. Es ist ein riesen Fehler bereits während der Entwicklung den vollen Rattenschwanz anzuwenden der für ein Luftfahrtgerät gilt oder eine Kundenspec undiskutiert umzusetzen. Rein rechtlich bekommen wir die Spec vom Kunden. Da steht aber drin was wir zusammen mit dem reingeschrieben haben. Der Supergau ist es wenn man den Kunden frei fantasieren läst, ggf. noch mit einem Vertriebler der bei allem nickt, weil er keinen Plan hat. da kommen dann Geräte raus die das Problem des Kunden garnicht lösen, die aber nur unter größten Schmerzen überhaupt realisierbar sind. Der kleine Ing, der alles ganz, ganz toll machen will, begierig jede Regel anwenden will und nur Papier und Fremdfirmenvergabe macht, hat von realer Schaltungsentwicklung so viel Ahnung wie ne Kuh vom Rückenschwimmen. Zumindest interessiert keine Norm ob ich erst mal alle RES1 / 10K einsetze und später die richtigen Werte reinorgel. Die interessiert sich nur für lückenlose Dokumentation, was, wann wo, verbaut wurde und das jede noch so kleine Änderung durch Papier und ggf, Tests + Rev Änderung glattgezogen ist. Und das auch erst wenn es in die freie Wildbahn entlassen werden soll. Es ist ein grober Fehler zu glauben das ganz viel Papier und starre Abläufe eine Entwicklung gut machen würden. Das Gegenteil ist der Fall. Wenn jede Änderung, jeder Versuch, jeder Prototyp einen Rattenschwanz an nutzlosen Aktionen mit sich bringt, weil irgendein Schlippsträger das für ganz toll hielt, dann bindet das Zeit, die nicht mehr in die Entwicklung geht, sondern in überflüssiges Papier. Und die allermeisten Entwickler lassen lieber einen wackeligen Stand so und hoffen auf das Beste, als das die sich wieder und wieder durch die Instanzen quälen und dafür noch angeschissen werden weil sie langsamer sind als Kollegen. Ich habe beides kennengelernt. Das kreative Chaos in dem eine Handvoll Leute ein Gerät nach dem anderen rausgehauen haben und ein System bei dem ich alleine für den Versuch eine andere Diode einzusetzen jede Menge Papier erzeugen musste, drei Mal mit dem EK reden, darauf warten das es in SAP angelegt wird, mit ALLEN Unterlagen die man sich nur vorstellen kann, dann warten bis Angebote von 3 Lieferanten kamen, einer beauftragt wurde und dann 5 Dioden für 1,20€/Stk lieferte. Parallel die Anlage des Bauteils unter Altium anfordern, warten das es dann mal irgendwann geschah, dieses Bauteil durch eine weitere Person gecheckt wurde, dann irgendwann freigegeben wurde und ich die PCB machen konnte. Die dann unter SAP angelegt werden musste, und ihr ahnt es bereits, man brauchte 3 Angebote und sehr, sehr viel Papier. Es zog sich Woche um Woche hin und es war zum Ausflippen, weil wir unter Zeitdruck standen. Aber Regeln sind Regeln und die GF war sehr stolz auf sich das sie Sonderlocken nicht zulässt weil sie richtig krass auf Qualität achten. In dem Laden vorher: Diode ausgesucht, tel bei Farnell bestellt, Footprint erstellt, PCB erstellt, im 24H Eilservice bestellt. 48Std nach Auftreten des Problems erneut im EMI Labor + bestanden. Serie bestellt, Bestücker angerufen, 2W später hatten wir die bestückte Serie im Haus. Während dessen wurde das Papier gemacht. Das geht und das ist konform. Man kann aber auch 10Leute damit beschäftigen, drei Monate vertrödeln und dann den ganzen Bereich einstampfen weil sich Kundenspezifische Entwicklung ja garnicht lohnt. Ja, wenn man das so macht kotzt der Kunde im Kreis, die Kosten laufen weg und am Ende ist es für niemanden mehr ein gutes Geschäft.
Also mir sagt die Vorgehensweise von Christian auch eher zu. Das kreative Chaos, wo ein paar Entwickler im Kreis rumfrickeln, mag zumindest bei manchen Leuten für schnelle Ergebnisse sorgen, ich selber hätte in solchem Chaos Probleme und würde öfter was verschusseln. Außerdem kommen dabei Projekte raus, die später nie wieder jemand anfassen will, weil selber neu konstruieren deutlich schneller geht als sich erst darüber klar zu werden was sich die damaligen Entwickler eigentlich gedacht haben. Und man hat während der Entwicklung bereits einen Truckfaktor von 1, ich verstehe es sehr gut daß die GF sowas nicht will.
Christian B. schrieb: > Purzel H. schrieb: >> Die Loesung ist dabei nicht die Elektronik dem Problem >> anzupassen, sondern das Problem der einfachst moeglichen Elektronik. Ich weiß, was gemeint ist. Ich fahre auch den Ansatz Keep it simple. Ist nur unglücklich ausgedrückt. Das zugrunde liegende Problem lässt sich ja nicht ändern aber die technische Lösung. Ich kenne das, da kommen nicht Techniker mit einem Problem und haben technische Spezifikationen und Ideen zur Lösung schon dabei. Im Gespräch muß man dann die mitgebrachten Ideen erstmal wegschieben, das eigentliche Problem spezifizieren und dann die beste, einfachste, schnellste technische Lösung erarbeiten. Manchmal muss man gar nicht bauen sondern es gibt schon Lösungen zu kaufen. Oben wurde das Beispiel Temperaturmessung genannt. Zu uns kommen Leute, die wollen ein Gerät gebaut haben. Im Gespräch, wenn die das Problem, ihre Anwendung erklärt haben kommt oft raus - "da gibt es doch was zu kaufen". Aber ich möchte noch eine Parallel zur Autowerkstatt schlagen. Wenn ein Automechaniker unfähig ist, lange braucht für die Fehlersuche und viele Teile wechselt hat die Werkstatt mehr verdient als wenn er einfach nur das defekte Teil gewechselt hätte. Also je schlechter der Mechaniker desto größer der Verdienst. Bedeutet für mich, das die schnelle einfache Lösung nicht so Gewinn bringend ist. Von dem Ratschlag ein fertiges Gerät zu kaufen habe ich gar nichts. Aber ich denke die Kunden sich nicht blöd, die merken das sie abgezockt werden. Auf lange Sicht setzt sich Qualität durch.
:
Bearbeitet durch User
Wühlhase schrieb: > Außerdem kommen dabei Projekte raus, die später nie wieder jemand > anfassen will, weil selber neu konstruieren deutlich schneller geht als > sich erst darüber klar zu werden was sich die damaligen Entwickler > eigentlich gedacht haben. Schnelle Arbeitsweise hat nix mit Schlamperei zu tun. Was er sich dabei gedacht hat steht im Schaltplan und den Notizen die man sich macht. Wenn ein Bauteil eine Platzhalter Kennung hat, ist es offensichtlich noch nicht exakt definiert. Und ein Entwickler der überhaupt mental dazu in der Lage ist das Projekt zu stemmen erkennt auch was im Schaltplan beabsichtigt wurde. Ansonsten müsste man ja 20S Prosa schreiben und das macht niemand. Also ist guter Code ebenso lesbar wie ein guter Schaltplan. Außerdem bringen Projekte die auf möglichst viele kleine Äffchen aufgeteilt werden eine Unmenge an Abstimmungsproblemen mit sich und je größer das Team ist und je weniger der Einzelne an Kraft und Verantwortung mitbringt, umso größer werden die Probleme. Und wo siehst Du in den von mir beschriebenen Abläufen jetzt einen Vorteil? Was macht das projekt besser, wenn ich footprints nicht selber erstellen kann oder Bauteile 3W Wochen brauchen bis ich sie bekommen, obwohl ich die bis 10Uhr am nächsten Tag hätte haben können? Außerdem ist Qualität eben auch: - Kundenbedürfniss erfüllt - Termin gehalten - Flexibel auf Herausforderungen reagieren - Am Ende was damit verdient Wenn nun aber 2 Kaufleute, zwei MA für Footprints und Freigaben, ein Projektmanager und drei Entwickler sich im Meetingraum die Falten aus dem Sack hauen Powerpointen, Protokolle schreiben, abhaken und Kaffee und Kekse vernichten, wenn EIN Entwickler das effizent tun könnten wenn man ihn nur ließe, dann verdient man eben kein Geld mehr außer man macht Großserie wo das im Rauschen untergeht. Wühlhase schrieb: > Truckfaktor von 1 Ach, den hat man doch immer und nie. Das ist wieder so eine dumme Kennzahl von BWLern. JEDER Entwickler an einem Projekt ist erstmal unersetzbar, wenn er ausfällt. Bis er dann lang genug ausfällt das es Sinn macht das sich da jemand anderes einarbeitet. Dann ist er ersetzt. Es gibt kein Projekt das nahtlos mitten im Prozess von einem anderen übernommen werden kann und auch keines das nur von diesem einen Menschen gemacht werden kann. Wenn ein Projekt scheitert weil einer ausfällt, dann meist weil man so lange sinnlos Zeit mit dummen Abläufen verblasen hat das es am Ende ungaublich knapp wird und man Verzögerungen nicht mehr auffangen kann. Aber wenn man ab der ersten Minute die Prioritäten auf schnelle Ergebnisse legt, Fehler zulässt, dann scheitert man schnell, lernt schnell, verbessert sich schnell und ist bereits beim dritten Aufbau, wenn Team 'gut Ding will Weile haben und SAP' noch bei der Planung des Einkaufes für den ersten Prototypen ist.
Taz G. schrieb: > Also je schlechter der Mechaniker desto größer der Verdienst. Als meine Mutter mal ihr Auto von der Mercedes-Niederlassung abholte, landete sie nächsten Kreisverkehr gleich auf der Verkehrsinsel, weil der grottenschlechte Mechaniker irgendetwas falsch zusammengebaut hatte. Glücklicherweise war nichts weiter passiert. Und offenbar hat er auch keine Funktionskontrolle, Probefahrt o.ä. durchgeführt, obwohl er das nach der Wartung von sicherheitskritischen Teilen hätte machen müssen. Aber das ist solchen Leuten völlig egal. Ich hoffe doch sehr, dass der seine fristlose Kündigung erhalten hat. Aber dann findet so jemand auch sofort eine Folgebeschäftigung, weil er ja seine Tätigkeit in der renommierten Werkstatt als Referenz aufführen kann. > Bedeutet für mich, das die schnelle einfache Lösung nicht so Gewinn > bringend ist. Von dem Ratschlag ein fertiges Gerät zu kaufen habe ich > gar nichts. Das hängt von der Zusammenarbeit mit den Kunden ab. Einer meiner Hauptkunden hat von Elektronik so überhaupt keine Ahnung und kommt aber manchmal mit abenteuerlichen Ideen an. In fast allen Fällen kommt schon im Laufe der ersten Projektrunde ein gänzlich anderer Aufbau heraus als von ihm anfangs gedacht. Und das ist eine Kombination aus zugekauften Standardteilen und Eigenentwicklungen. Wenn ich ihm für sämtliche Komponenten Eigenentwicklungen verkaufen wollte, würden die Kosten völlig explodieren. > Aber ich denke die Kunden sich nicht blöd, die merken das sie abgezockt > werden. Auf lange Sicht setzt sich Qualität durch. Exakt. Mit Kunden, die mir schon gleich erzählen, dass alles viel schneller und billiger gehen muss, diskutiere ich auch nicht ewig herum. Das ist die Mühe nicht wert. Mit solchen Kunden habe ich mir schon die Finger verbrannt.
Max M. schrieb: > JEDER Entwickler an einem Projekt ist erstmal unersetzbar, wenn er > ausfällt. > Bis er dann lang genug ausfällt das es Sinn macht das sich da jemand > anderes einarbeitet. Dann ist er ersetzt. > Es gibt kein Projekt das nahtlos mitten im Prozess von einem anderen > übernommen werden kann und auch keines das nur von diesem einen Menschen > gemacht werden kann. > > Wenn ein Projekt scheitert weil einer ausfällt, dann meist weil man so > lange sinnlos Zeit mit dummen Abläufen verblasen hat das es am Ende > ungaublich knapp wird und man Verzögerungen nicht mehr auffangen kann. > Aber wenn man ab der ersten Minute die Prioritäten auf schnelle > Ergebnisse legt, Fehler zulässt, dann scheitert man schnell, lernt > schnell, verbessert sich schnell und ist bereits beim dritten Aufbau, > wenn Team 'gut Ding will Weile haben und SAP' noch bei der Planung des > Einkaufes für den ersten Prototypen ist. da stimme ich dir voll zu Max M. schrieb: > Was macht das projekt besser, wenn ich footprints nicht selber erstellen > kann oder Bauteile 3W Wochen brauchen bis ich sie bekommen, obwohl ich > die bis 10Uhr am nächsten Tag hätte haben können? hier auch. Ich lebe aber in einer kleinen Blase, wo ich selbst Herr sowohl über die Datenbank als auch die zu verwendenden Bauteile bin. d.h. wenn ich für ein Projekt ein Bauteil brauche, was es noch nicht gibt, dann muss ich es anlegen. Das muss ich aber so oder so machen, egal, ob das Bauteil später immer noch verwendet wird, oder nach dem ersten Prototypen rausfliegt. Sogesehen sehe ich das etwas anders. Wenn man natürlich in einem solchen Korsett festgeklemmt ist, dann kann ich deine Arbeitsweise nachvollziehen, wenngleich man dabei deutlich mehr Streß hat, ein Entwicklungsprojekt problemlos in die Fertigung zu bringen. Die Fehlermöglichkeit ist dabei auch höher, einfach irgendwo etwas zu übersehen in den Aufzeichnungen. Wenn man immer nur ein Projekt bearbeitet, mag das noch angehen, ich hab aktuell 3 offene Neuprojekte die ich parallel bearbeiten muss. Da würde ich mit einer Platzhaltervariante permanent Wasser saufen :) Auch weil ich ja nicht allein bin, sondern nach mir die Softwareker mit dem Projekt arbeiten wollen und müssen. Die würden mir was husten, wenn ich denen einen Schaltplan vorsetzte mit Platzhaltern und einer Menge Prosa. Wobei das vielleicht auch ein Stück weit Gewöhnung ist.
:
Bearbeitet durch User
Max M. schrieb: > Schnelle Arbeitsweise hat nix mit Schlamperei zu tun. > Was er sich dabei gedacht hat steht im Schaltplan und den Notizen die > man sich macht. > Wenn ein Bauteil eine Platzhalter Kennung hat, ist es offensichtlich > noch nicht exakt definiert. > Und ein Entwickler der überhaupt mental dazu in der Lage ist das Projekt > zu stemmen erkennt auch was im Schaltplan beabsichtigt wurde. > Ansonsten müsste man ja 20S Prosa schreiben und das macht niemand. > Also ist guter Code ebenso lesbar wie ein guter Schaltplan. Da ist meine Erfahrung eine andere. Notizen, die sich jemand macht, sind erstmal irgendwo aber normalerweise nicht im Schaltplan. Außerdem sind Notizen in der Regel nie vollständig und ergeben nur zusammen mit dem, was der Entwickler noch so im Kopf hatte, einen Sinn. Viele schaffen es nur einfach nicht sich vorzustellen, wie jemand ihre Doku verstehen soll der noch nie in dem Projekt gestanden hat. Und meinen deshalb, ihr Schriebs wäre ausreichend. Ich gebe dir Recht in dem Punkt, daß ein Entwickleraustausch immer Einarbeitungsaufwand erfordert. Es gibt aber gehörige Abstufungen zwischen "muß man einfach mal durchblättern und hat dann einen Überblick" und Spaghettischaltplänen, wo der Entwickler die gesamte Schaltung in ein A0-Blatt reinhaut (und ihm selbst daß nicht selten noch zu klein ist) und eine wilde Mischung aus graphischer Netzliste und Wollknäuelrätsel. Struktur und Ordnung im Denken und Entwickeln schlagen sich auch in der Doku nieder, sowie das Fehlen derselben. Sowas ist übrigens nicht nur für BWLer gut, sondern auch für die Kollegen. Ich hab einfach keinen Bock darauf mich mit Projekten von solchen Entwicklern herumzuschlagen.
Max M. schrieb: > Wühlhase schrieb: >> Außerdem kommen dabei Projekte raus, die später nie wieder jemand >> anfassen will, weil selber neu konstruieren deutlich schneller geht als >> sich erst darüber klar zu werden was sich die damaligen Entwickler >> eigentlich gedacht haben. .... > Also ist guter Code ebenso lesbar wie ein guter Schaltplan. Ich muß der Aussagae von Wühlhase da voll und ganz zustimmen. Ich musste mich auch schon mit alten Schaltplänen meiner Kollegen rumschlagen. Ab einer gewissen Komplexität ist es einfach nicht mehr möglich sich in die Gedankenwelt einer anderen Person rein zu versetzen. Die Kollegen haben auch Fehler gemacht, haben unnötige Sachen platziert, Beschriftungen sind nicht aussage kräftig usw. Max M. schrieb: > Wenn nun aber 2 Kaufleute, zwei MA für Footprints und Freigaben, ein > Projektmanager und drei Entwickler sich im Meetingraum die Falten aus > dem Sack hauen Powerpointen, Protokolle schreiben, abhaken und Kaffee > und Kekse vernichten, wenn EIN Entwickler das effizent tun könnte... Stimmt auch nur bis zu einem bestimmten Level. Irgendwann wird das Projekt zu groß und man muß die Arbeiten aufteilen. Der Eine macht den Analogteil, der Andere den digitalen Teil, und wieder ein Anderer macht den HF Kram. Vermessen zu sagen, das eine Person alle elektrotechnischen Bereiche voll und ganz beherrschert. Aber ich tendiere auch zu möglichst wenigen Leuten. Max M. schrieb: > Wühlhase schrieb: >> Truckfaktor von 1 > Ach, den hat man doch immer und nie. > Das ist wieder so eine dumme Kennzahl von BWLern. Oh, oh ganz und gar nicht blöd. Da habe ich mit zu tun. Das bedeutet wenn eine Person ausfällt scheiert das Projekt, das kann eine Existensbedrohung für das Unternehmen darstellen. Trackfaktor 1 ist natürlich simpel ausgedrückt, man macht eine richtige Risikoanalyse. Was bedeutet das für deine Arbeit, dein Projekt, für dein Unternehmen, wenn Du 14 Tage krank bist und was ist mit 6 Wochen (Arm Bruch) oder Tod ? Man sollte nie den Erfolg eines Projektes in die Hände einer einzelnen Person legen. Vielleicht ist ein Truckfaktor von 0.8 ja OK.
Christian B. schrieb: > Sogesehen sehe ich das etwas anders. Ich bin ja lange raus aus dem Verein und habe das nun auch alles in eigener Hand. Ich halte eben nur FP und Symbole getrennt. Vollständig definiert wird das meist Bauteil nicht in der Lib sondern erst durch die Kombination Symbol + Footprint + Lagerposition (z.B. RSMD-0603-1k-1%) Im Schaltplan ist es mir erstmal egal ob es bereits einen FP dazu gibt. Ich trage ein was ich habe, wenn ich es habe. Z.B den FP ohne Lagernummer mit Wert 'tbd' oder bereits eine Lagernummer aber noch keinen FP weil ich den erst noch machen muss. Haben ich bereits alles, definiere ich das auch gleich beim Einsetzen. Fehlt mir aber noch was unterbreche ich den kreativen Prozess nicht dadurch das mir noch der FP fehlt oder ich den Wert exakt berechnen muss. Oft ändern sich Schaltpläne beim Abstimmungprozess mit dem Kunden mehrfach. Formfaktor und Funktionen sind noch nicht abschliessend geklärt, Stecker nicht definiert. Da macht es oft keinen Sinn mehr als den Schaltplan als Diskussiongrundlage zu erstellen. Geräte entstehen zu einem gewissen Maß in einem Ping Pong Prozess in einem komplexen Geflecht aus verschachtelten Kundenbeziehungen. Das macht die Stärke aus, erfordert aber sehr flexible Arbeitsweisen. Ich finde z.B. die Listenansicht bei Kicad die Wucht. In einer Tabelle habe ich alle meine Felder und kann per Copy / Paste Footprints, Werte, Lagernummern, einfach alles ändern. Ich sehe sofort welches Bauteil durchdefiniert ist und welches nicht. Ich bin zeitlich von allem entkoppelt. Keine endgültige Lagernummer, Teil ersetzt durch ein anderes, allen Bauteilen global Felder hinzufügen die ich ggf, mit einem pyton Script auswerte, einzeln oder ganze Gruppen, ist alles nur ein Handgriff. Unglaublich mächtig das Werkzeug.
Max M. schrieb: > Ich finde z.B. die Listenansicht bei Kicad die Wucht. Bei Altium ist das der Parameter Manager.
Taz G. schrieb: > Man sollte nie den Erfolg eines Projektes in die Hände einer einzelnen > Person legen. Ich habe bestimmt bereits ein dutzend Projekte übernommen, die an die Wand gefahren waren. Teilweise über Nacht, während bereits über Konventionalstrafen geredet wurde. Ob durch Überforderung, Krankheit, Tod, Kündigung ist doch egal. JEDES Projekt lässt sich von einem anderen übernehmen. Man braucht eben nur genug Leute die sowas auch können und die flexibel genug dafür sind. Wenn ich aber Leute nur einen klitzekleinen Teilbereich der Elektronik machen lassen und das jeden Tag und in einem ganz eng geschnürtem Regelwerk, dann verlieren die jede Flexibilität und ich bin am Arxxx wenn mir Leute ausfallen und ich zwar den Laden voll mit Entwickler habe aber alle verkriechen sich hinter ihrem Schreibtisch. Wenn ich den SNT Teil mache, mein Kollege die Logig, inwiefern nützt es dem das wir am gleichen Projekt arbeiten wenn ich ausfalle? Er kann keine Schaltnetzteile, ich kann kein VHDL. Oder setze ich dann zwei an das gleiche SNT und zwei an die Logig, zwei an die mech und zwei an die Programmierung der MCU, damit immer zwei da sind die alles wissen? Wer hat denn eine derart generöse Ausstattung mit fähigen Entwicklern? Zwei schlechte machen ja keinen Guten. Die sind gemeinsam nur doppelt so schlecht.
Max M. schrieb: > Taz G. schrieb: >> Man sollte nie den Erfolg eines Projektes in die Hände einer einzelnen >> Person legen. > Ich habe bestimmt bereits ein dutzend Projekte übernommen, die an die > Wand gefahren waren. Genau das gilt es zu vermeiden. Durch eine Riskoanalyse. Jeder ist ersetzbar, das sehe ich auch so aber ob das am Ende noch retabel bleibt ist mehr als fraglich. Max M. schrieb: > dann verlieren die jede Flexibilität und ich bin am Arxxx > wenn mir Leute ausfallen da bin ich voll bei Dir. Die Arbeit so zu zerstückeln das keiner mehr mit Freude arbeitet und auch keine Verantwortung mehr hat, ist für mich eine grusselige Vorstellung. Arbeiten nach Vorlieben und Kompetenzen der Mitarbeiter aufteilen ja aber nur so weit wie nötig. Max M. schrieb: > inwiefern nützt es > dem das wir am gleichen Projekt arbeiten wenn ich ausfalle? Das ist die richtige Frage. Ich kann sie nicht für Dich beantworten. Aber Du musst Dir überlegen wie es mit deiner Arbeitet weiter geht wenn Du in den Urlaub fahren möchtest oder dein Kollege krank wird. Wenn die Konsequenzen fatal wären wirst Du oder deine Firma vielleicht doch mehrere Leute einstellen die sich mit VHDL auskennen, damit der Eine im Ernstfall übernehmen kann (Spoiler: das geht nie Reibungslos).
:
Bearbeitet durch User
Taz G. schrieb: > Wenn die > Konsequenzen fatal wären wirst Du oder deine Firma vielleicht doch > mehrere Leute einstellen die sich mit VHDL auskennen, damit der Eine im > Ernstfall übernehmen kann (Spoiler: das geht nie Reibungslos). Das ist allein schon deshalb sinnvoll, um mal mit jemandem über ein Fachthema quatschen zu können. Das gibt Ideen und Inspiration, und wenn man die Wahl zwischen verschiedenen Lösungswegen hat ist es auch immer mal gut, eine Meinung zu hören die nicht die eigene ist.
Taz G. schrieb: > vielleicht doch > mehrere Leute einstellen die sich mit 'xyz' auskennen. Und genau das ist der Punkt. Ich brauche eigentlich 'nur' mehr als einen der gut genug ist das Projekt ebenfalls machen zu können. Ein Team aus Leuten und die beste Planung hilft alles nicht, wenn ich den der es auch kann nicht habe. Man braucht nicht viele Leute. Man braucht ein paar Gute und ein paar andere für das drumherum. Und die Guten sollte man arbeiten lassen und nicht mit Papier, Regeln, Abläufen und täglichen ineffizienten Meetings blockieren.
>Wuehlhase schrieb : >Das kreative Chaos, wo ein paar Entwickler im Kreis rumfrickeln, mag zumindest bei manchen Leuten für schnelle Ergebnisse sorgen, ich selber hätte in solchem Chaos Probleme und würde öfter was verschusseln. Außerdem kommen dabei Projekte raus, die später nie wieder jemand anfassen will, weil selber neu konstruieren deutlich schneller geht als sich erst darüber klar zu werden was sich die damaligen Entwickler eigentlich gedacht haben. Und man hat während der Entwicklung bereits einen Truckfaktor von 1, ich verstehe es sehr gut daß die GF sowas nicht will. Es gibt eben andere Setups, die mit einer duennen Personaldecke das machen, was drinliegt. Und wenn man die Mitarbeiter nicht hat, laesst man's eben vorerst sein. Das koennen auch international erfolgreiche Firmen sein. Ich kenne viele Firmen, bei welchen manche Funktionalitaeten nur einfach besetzt ist. Allenfalls schon mehrere Entwickler, die koennen sich aber nicht ersetzen, weil auf fast ewig mit eigenen Projekten ausgebucht, und auf andere Gesichtspunkte spezialisiert. Entwicklung bedeutet Probleme zu loesen und zu Lernen. Wenn man's in einigen Jahren nochmals neu anschaut, kann man's anders machen, besser machen. Bei Null zu beginnen ist die schlechteste aller Moeglichkeiten. Allenfalls sollte eine Firma die Leute so bezahlen, dass sie lange bleiben, und nicht am Minimum halten. Auch vom Drumherum her. Das kann dann auch so weit gehen, dass der Chefentwickler den Parkplatz des Chefs gleich neben dem Eingang belegt, welchen er sowieso als Trottel betrachtet.
:
Bearbeitet durch User
Purzel H. schrieb: > Ich kenne viele Firmen, bei welchen manche Funktionalitaeten nur einfach > besetzt ist. Ich kenne überwiegend Firmen bei denen lange nicht jede Funktionalität besetzt ist. Das Team klein, der Bereich weit gesteckt, der Markt höchst speziell, die Stückzahlen klein, der Einzelpreis hoch. Know einzukaufen ist teuer, nicht beliebig frei verfügbar und man kann es nicht halten, weil der Markt für das kleine Team reicht, aber nicht für die 20 köpfige Entw. Abt. Schnell begreifen, schnell Fehler machen, schnell aus den Fehlern lernen und etwas bauen das funzt, bevor Budget und Abgabetermin davonlaufen. Dabei entsteht auch mal Wildwuchs und das erfordert mehr Disziplin. Aber das einzige was wirklich zählt ist das richtige Gerät zum richtigen Zeitpunkt. Außerdem gehen die meisten Entwicklungen nicht wegen fehlender Fachkompetenz der Entwickler in die Wicken, sondern weil die Vorgaben schzeiße waren, die Chemie im Team nicht stimmt, Teams zu groß sind und hierachisch durchregiert werden, so das jeder nur noch Dienst nach Vorschrift macht. Die ersten 70% der Zeit wird im Meeting rumgepimmelt, mit Flipcharts und tollen Ideen statt die Ärmel hochzukrempeln und Striche zu machen. Wenn dann endlich der Master of Desaster, der jede Eigeninitiative als persönlichen Angriff auf seine Männlichkeit sieht, auch mal begreift was die Uhr geschlagen hat, fängt der Druck an, das doch alle Entwickler nur Idioten sind und man doch wohlk erwarten könne, bla bla bla. Dabei gilt seit jeher: Man braucht für 80% der Funktion 20% der Zeit. Die restlichen 20% schafft man in den restlichen 80% und Entwicklungsprojekte dauern immer drei mal länger als man sich in seinen wildesten Träumen ausgemalt hat. Große Teams = viele Gehälter, viel Abstimmung, viel Zwist, viele widerspüchliche Meinungen = viel doppelte Arbeit, langsame Arbeit, frustrierend lähmende Abläufe, permanente Aktualisierung von Plänen, Besprechungsprotokollen, Zeitstrahlen. = Sowas verschlingt sehr schnell, sehr viel Geld, sehr viel Zeit und an beidem scheitern Projekte und Kundenbeziehungen. Und jede Minute die ich im Meeting verbringe, bin ich nicht am Gerät. Meetings sind wichtig, einmal die Woche, kurz, knackig, fertig, zurück ans Projekt.
Max M. schrieb: > Große Teams = viele Gehälter, viel Abstimmung, viel Zwist, viele > widerspüchliche Meinungen = viel doppelte Arbeit, langsame Arbeit, > frustrierend lähmende Abläufe, permanente Aktualisierung von Plänen, > Besprechungsprotokollen, Zeitstrahlen. > = Sowas verschlingt sehr schnell, sehr viel Geld, sehr viel Zeit und an > beidem scheitern Projekte und Kundenbeziehungen. > Und jede Minute die ich im Meeting verbringe, bin ich nicht am Gerät. > Meetings sind wichtig, einmal die Woche, kurz, knackig, fertig, zurück > ans Projekt. Naja, der Umkehrschluss ist aber der gleiche: Kleine Teams = permanent zu 100% ausgelastet und am Ende bleiben Dinge liegen, das fängt bei Papieren an, die man erst zu einem viel späteren Meilenstein braucht und geht bis hin zu eigentlich wichtigen Komplettests, wenn man eine Änderung an der Baugruppe gemacht hat. Oft beschränkt man sich dann, aus Zeitgründen, auf einen spezifischen Test nur die Änderung betreffend und übersieht dabei einen Effekt, der dann einen anderen Teil der schon vorhanden Baugruppe beeinflusst. Hab ich oft genug erlebt, immer wieder sagt man sich: das passiert uns nicht nochmal, das nächste mal machen wir den Kompletttest samt der nötigen Papiere und was passiert: Da kommt ein MA aus dem Service, 2 aus der Fertigung und der tag ist rum bevor man auch nur ein Wort in eines der, eigentlich für den Tag geplanten, Papiere tippt. Ergo bleibt es wieder liegen bis es gar nicht anders geht, mit allen Seiteneffekten, die damit einher gehen. Das Ziel müsste also sein, ein Entwicklungsteam zu haben, was von der Größe her so ist, dass sich Entwickler auch mal langweilen, dafür aber eben normalerweise in annehmbarer Zeit ihre Arbeit fertig bekommen, ohne von irgendwelchen seitlich eingestreuten Katastrophenmeldungen (die es immer geben wird) derartig aus dem Zeitplan zu fallen, dass Aufgaben zu weit vom eigentlichen Zieldatum verschoben werden (müssen).
Christian B. schrieb: > Umkehrschluss Full Ack! So ist das dann. Jedes Ding hat zwei Seiten. Christian B. schrieb: > sich Entwickler auch mal langweilen Haben Entwickler wenig Zeit, brauchen sie wenig Zeit und am Ende wird es eng. Haben Entwickler viel Zeit, brauchen sie viel Zeit und am Ende wird es eng. Wir versuchen in DE immer weniger oft zu scheitern. Das gelingt aber nur wenn man einen starren Prozess etabliert der keine Umwege mehr zulässt und immer das gleiche tut mit möglichst keinen Variantionen. Z.B. Meanwell. Schaltnetzteile. Große, kleine, lange, schmale, hohe, vergossen, offen, für LED, Konstantspannung, Konstantstrom, Medizinisch, Industriel, Consumer, Mil. Aber immer Schaltnetzteile. Und die machen auch Kundenspezifisch. Mindestmenge, lange Vorlaufzeit, im wesentliche Bestückungsvariationen existierender Designs und das gigantsiche Team das weltweit entwickelt, baut, testet, verkauft, verwaltet, finanziert sich aus gigantischen Stückzahlen. Kann man machen aber wir machen Dinge für Kunden die weit extremere Ansprüche haben, wenig Zeit und 10Stk ist oft schon eine große Menge. Also müssen wir nicht weniger scheitern sondern schneller scheitern und daran wachsen, denn wenn man ständig andere Sachen macht, passen starre Prozesse nicht. Und am Ende ist das Papier immer 100% fertig und das um Welten extremer als im Consumer Bereich, weil das unser Markt mit sich bringt.
Max M. schrieb: > Also müssen wir nicht weniger scheitern sondern schneller scheitern und > daran wachsen, denn wenn man ständig andere Sachen macht, passen starre > Prozesse nicht. Max M. schrieb: > Und jede Minute die ich im Meeting verbringe, bin ich nicht am Gerät. > Meetings sind wichtig, einmal die Woche, kurz, knackig, fertig, zurück > ans Projekt. Nun, diese Dinge sehe ich exakt genauso. Auch wenn ich von Prozessen wahrscheinlich eine andere Vorstellung habe als Max.
Wühlhase schrieb: > Max M. schrieb: >> Und jede Minute die ich im Meeting verbringe, bin ich nicht am Gerät. >> Meetings sind wichtig, einmal die Woche, kurz, knackig, fertig, zurück >> ans Projekt. da möchte ich noch anfügen: zur richtigen Zeit. Letzte Woche hab ich z.B. ein Meeting gehabt, Schaltplan fertig, Papiere auch schon zu 2/3 als es plötzlich im Meeting von den Physikern heisst: Das Gerät bekommt eine Kompressorkühlung. Der Projektleiter stimmt ein und sagt: ja, das ist gesetzt. Dann kommt eine Marketingmitarbeiterin und sagt: ihr könnt alles einbauen, solange es unter 10k Herstellkosten bleibt. Und was mache ich? Ich lasse die Arbeit liegen, bis sich die 3 im klaren darüber sind, ob sie eine Luft- oder eine Kompressorkühlung wollen und mir das mit einem geänderten Vorgabedokument mitteilen. Zum Glück habe ich ja noch 3 andere Baustellen, die alle genauso dringend sind. Ich meine, im Schaltplan etwas zu ändern ist kein Problem, wenn das Layout fertig gewesen oder gar die Prototypen bestellt währen, sähe das anders aus, dann hätte man die gleich vom Wareneingang zur Verschrottung bringen können. Nicht, dass das nicht auch schon vorgekommen wäre, weil vormals Notwendige Änderungen plötzlich doch auf keinen fall gemacht werden durften. Unterm Strich kochen halt alle nur mit Wasser aber jeder Koch bevorzugt andere Gewürze :) so würde ich das mal zusammenfassen.
Christian B. schrieb: > Der Projektleiter stimmt ein und sagt: ja, das > ist gesetzt. Was für ein Held! Was wäre denn die Alternative gewesen? Da hätten sich besser Entwickler und Physiker direkt unterhalten und gemeinsam die beste Lösung gefunden. Im Endeffekt hat das Projekt gerade die Vollbremsung hingelegt, weil sich Anforderungen im Projektverlauf ändern. Viele Arbeiten werden nun doppelt gemacht werden und das wird nicht die letzte Änderung sein. Genau sowas treibt Projekte aus Budget und Termin. Der Entwickler der die ganze Show dann baut, ist an den Entscheidungen nicht beteiligt, wird nicht gefragt und erfährt die Dinge zuletzt. Er muss aber der Erste sein der fertig ist.
Max M. schrieb: > Im Endeffekt hat das Projekt gerade die Vollbremsung hingelegt, weil > sich Anforderungen im Projektverlauf ändern. was vollkommen normal ist. Man sagt am Anfang: Man will ein gerät, was so und so arbeiten soll. Dann laufen parallel die Designer und die Physiker los um ihrerseits auf dem Reissbrett, bzw. an der Optischen Bank zu tüfteln. Am Ende kommt nun heraus, dass eine, ursprünglich angedachte, Luft-Wasser Kühlung eben einen Effizienzverlust von 30% zur Folge hat. Ergo ist die Kompressorkühlung unumgänglich. Natürlich habe ich, als Verantwortlicher für die Elektronik auch schon angefangen, aber es ist jetzt nicht so problematisch. Das Projekt wird jetzt wohl 1-2 Wochen pausieren, was mir Zeit gibt, ein anderes zu beenden. Dann geht es damit wieder weiter. Schlimm sind so Wendungen im Projekt erst, wenn sie kurz vorm Produktionsstart auftauchen, denn dann hat man tatsächlich keine Zeit mehr sinnvoll zu reagieren und muss irgendwas zusammenfrickeln, damit das Ding die erste Vorstellung bei Kunden übersteht.
Max M. schrieb: > Im Endeffekt hat das Projekt gerade die Vollbremsung hingelegt, weil > sich Anforderungen im Projektverlauf ändern. So wie ich das verstanden habe ist das doch aber genau das, was du wolltest: Schnelles Scheitern einer Lösung, damit man umso früher auf der Spur ist auf der man eigentlich sein will.
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.