Danke Udo,
schön das jemand aus der "oberen Etage" hier im Forum mal das Kind beim Namen nennt:
im deutschsprachigem Raum ist nun mal Deutsch die Muttersprache, also spricht sie jeder.
Englisch ist nach wie vor eine Fremdsprache - auch wenn weitgehend verbreitet, was auch gut so ist, - aber es beherrschen sie eben nicht alle und nicht gleich gut. Darauf Rücksicht zu nehmen ist - glaube ich - nicht falsch...
(Auch wenn das nur Nebensache in der aktuellen Diskussion ist)
LG
Robert

riu hat geschrieben: Ich verstehe das nicht mit dem "Firmwareupdater". Wozu eine neue Baustelle aufmachen?

Das ist keine Baustelle sondern eine Anwendung, die ein COM-Port öffnet, eine .hex-Datei bekommt und das Update der Firmware über avrdude durchführt. Das Programm kann auch erkennen ob du versuchst, die RF1000 Firmware auf den RF2000 zu übertragen (oder umgekehrt) und kann dich davor warnen. Das kann Arduino nicht. Der Anwender muss Arduino nicht einmal selbst installiert haben.

riu hat geschrieben: Was ich ebenfalls sehr bescheiden finde ist, das die Headerdateien die ein User anfassen muss NUR englische Kommentare haben. Warum setzt ich nicht mal einer hin und schreibt die deutschen Kommentare drüber? Ich finde das so eher halbgar. Nicht jeder in DE/AT/CH kann Englisch geschweige denn technisches Englisch.

Well. Typischerweise muss ein User (= Englisch für Anwender ) die Sourcen doch gar nicht anfassen, oder?


mfG
RF1000

RF1000 hat geschrieben:

riu hat geschrieben: Ich verstehe das nicht mit dem "Firmwareupdater". Wozu eine neue Baustelle aufmachen?

Das ist keine Baustelle sondern eine Anwendung, die ein COM-Port öffnet, eine .hex-Datei bekommt und das Update der Firmware über avrdude durchführt. Das Programm kann auch erkennen ob du versuchst, die RF1000 Firmware auf den RF2000 zu übertragen (oder umgekehrt) und kann dich davor warnen. Das kann Arduino nicht. Der Anwender muss Arduino nicht einmal selbst installiert haben.

Hmm neue Anwendung=Baustelle. Wenn es ein Jahr braucht um die zu schreiben erst recht. Aber ich gebe auf.

RF1000 hat geschrieben:

riu hat geschrieben: Was ich ebenfalls sehr bescheiden finde ist, das die Headerdateien die ein User anfassen muss NUR englische Kommentare haben. Warum setzt ich nicht mal einer hin und schreibt die deutschen Kommentare drüber? Ich finde das so eher halbgar. Nicht jeder in DE/AT/CH kann Englisch geschweige denn technisches Englisch.

Well. Typischerweise muss ein User (= Englisch für Anwender ) die Sourcen doch gar nicht anfassen, oder?

Was mussten/müssen denn die Anwender machen die eine RF1000 haben und sich im Shop die Fräserweiterung kaufen? Blind aufspielen und hoffen das alles fukntioniert?

Naja ich bin vielleicht zu pessimistisch.

Liebe Grüße,
Udo

So eine "Anwendung" schreibe ich in 10 Minuten auf Basis von avrdude... Das ist nen 1-Zeiler als Shell-Script für Linux bzw. als .BAT-Datei für Windows. avrdude ist open-source, kann also problemlos als Binary dazugegeben werden.

Tatsächlich sollte der End-Anwender nicht die Firmware selbst bauen müssen, sondern ein Binary bekommen. Idealerweise sollte die Firmware alle offiziellen Erweiterungen unterstützen und notwendigen Optionen im Menü anbieten.

Wer ein bisschen basteln möchte und spezielle Einstellungen selbst anpassen, dem kann man wohl das Installieren von Arduino zumuten. Der kann dann aber eigentlich auch die eine Zeile für RF1000/RF2000 anpassen...

PS: Es gibt einige Grundregeln bei der Software-Entwicklung über die man nicht diskutieren muss. Eine davon ist, dass Code kopieren, um ihn etwas zu modifizieren, ein absolutes no-go ist, unabhängig vom Zusammenhang und Hintergedanken. Deshalb bitte so schnell wie möglich die beiden Unterverzeichnisse für RF1000 und RF2000 wieder vereinen. Das fliegt euch früher oder später um die Ohren und kostet dann *richtig* viel Zeit.

mhier hat geschrieben:So eine "Anwendung" schreibe ich in 10 Minuten auf Basis von avrdude... Das ist nen 1-Zeiler als Shell-Script für Linux bzw. als .BAT-Datei für Windows. avrdude ist open-source, kann also problemlos als Binary dazugegeben werden.
...

Das ist auch mein Gedanke gewesen, deswegen (Baustelle).

mhier hat geschrieben: Wer ein bisschen basteln möchte und spezielle Einstellungen selbst anpassen, dem kann man wohl das Installieren von Arduino zumuten. Der kann dann aber eigentlich auch die eine Zeile für RF1000/RF2000 anpassen...

Richtig. Der kommt auch an den Source und weiss wie man damit umgeht.

mhier hat geschrieben: PS: Es gibt einige Grundregeln bei der Software-Entwicklung über die man nicht diskutieren muss. Eine davon ist, dass Code kopieren, um ihn etwas zu modifizieren, ein absolutes no-go ist, unabhängig vom Zusammenhang und Hintergedanken. Deshalb bitte so schnell wie möglich die beiden Unterverzeichnisse für RF1000 und RF2000 wieder vereinen. Das fliegt euch früher oder später um die Ohren und kostet dann *richtig* viel Zeit.

Wieder ins schwarze.
Das nannte man zu meiner Zeit generic. Eine Funktion die nur halb das kann was ich brauche, wird erweitert ohne die Grundfunktionalität zu verlieren. Mit dem Einzug von OOP waren es dann Klassen und Vererbung. Also Jungs seit nicht zu Stolz um Fehler zu korrigieren die euch später dazu verleiten es zu bereuen. Ich denke mhier und ich zusammen sind schon einige Jahrzente Softwareentwicklungserfahrung

Lieben Gruß,
Udo

PS: Da fällt mir ein gewisser Herr Ruben ein. Der hat in den 90ern Datenbank Libs geschrieben. Der hatte eine Aversion gegen Parameter. Der hat für jede noch so triviale Aufgabe eine eigene Funktion geschrieben, in dem er eine vorherige kopiert hat und daraus die neue gemacht hat. Diesen Code durfte ich damals 2 Monate lang "Entrubeln" Von knapp 600.000 LOC blieben etwas über 100.000 über. 2 Monate Arbei für NIX.

Udo/riu,

Ich verstehe den Ansatz von Conrad/RF1000 gut. Die Eingeweihten hier werfen da mit "Github", "fork", "branch", "Development Version" und was weiß ich herum. Vor zwei-einhalb Jahren wäre das auch für mich alles spanische Dörfer gewesen.
Und es gibt sicherlich einige hier im Forum, für denen es das noch immer ist. Und, noch wichtiger!, es nicht unbedingt anders wissen wollen.
Wenn einer, wie beim Einkaufen über die Bucht oder bei Amats-ohne, einfach auf der Conrad Seite auf einen Knopf klicken kann (und der Drucker per USB angesteckt ist), und die Firmware wird automatisch upgedatet, ohne sich um Github, Arduino, usw. kümmern zu müssen, ist das doch toll. Besonders für die Kenner der spanischen Dörfer, oder?

Die, die an der Configuration.h was ändern, die müssen ja zu den spanischen Dörfern reisen, und lernen, worum es da geht.
Klar, der 3D Druck steckt noch in den Kinderschuhen, aber irgendwann wird es doch Plug & Play. Das ist ein Schritt in die richtige Richtung.
Irgendwann, in ein paar Jahren, steigt dann der Drucker (übers USB Kabel) selbst in das Internet und macht selbst das Update (wie Windows und 90% aller Software).

mjh11

Hallo mjh,

Ja der Drucker ist ein Drucker. Plug and Play wird das 3D Drucken aber genausowenig wie Kuchenbacken. Es gibt maximal in ein paar Jahren ein Gesamtsystem das sich selbst parametrisiert. Ob das aber offen sein wird ist hier die Frage. Standards gibt es keine. Den Gedanke will ich auch garnicht weiterspinnen.

Ich möchte auch dass es für Einsteiger in den 3D Druck einfacher wird. Im Moment brechen sich aber eingefleischte Maschinenbau Ingenieure einen ab den ersten Layer zum haften zu bringen und der gleichen mehr. Von daher sehe ich noch keinen Ansatz, das es besser wird. Im Hintergrund kann man aber imt ein wenig Erfahrung erkennen das es nicht rund läuft und manche Sachen grundlegend falsch angegangen werden. Da muss man berechtigte Kritik üben dürfen. Dabei bleibt es bei mhier und mir aber nciht. Wir haben auch vorschläge wie es besser geht. Diese Vorschläge einfach zu ignorieren und nicht darauf einzugehen ist unprofessionell - sorry.

Obiges ist meine Wahrnehmung und Meinung, die ich keinem Aufzwinge.

Lieben Gruß,
Udo

Udo/riu,

Ich sage gar nicht, dass du unrecht hast. Ich bin sogar deiner Meinung. Nur verstehe ich auch die, die nicht wie

mhier hat geschrieben:Wer ein bisschen basteln möchte und spezielle Einstellungen selbst anpassen, dem kann man wohl das Installieren von Arduino zumuten. Der kann dann aber eigentlich auch die eine Zeile für RF1000/RF2000 anpassen...

basteln wollen, oder es sich nicht zutrauen. Daher kommt wahrscheinlich die Richtung, in die der große C mit dem "Firmwareupdater" gehen will.
Das heißt aber nicht, dass die, die doch basteln wollen, mit einem verpfuschten System arbeiten müssen oder sollen.

mjh11

Hallo mhj,

Ich wollte auch nciht sagen dass wr uneins sind. Der Firmwareupdater gehört schon sein langem auf den PC eines jeden RF1000 Besitzers. Das schlimmer ist dass es ihn schon lange gibt (AVRDude). Es fehlt einfach an offiziellen Binaries. Das schöne ist das alle RF1000 gleich sind. Man kann also das Binary einmal erzeugen und es frisst jeder RF1/2000 (bis auf die Hardware erweiterten Versionen).

Seit der ersten Version mein RF1000 ist von 09/2014 hatte einige Macken so dass er garnicht sorecht wollte. Es gab bugs und diverse Einstellungen die angepasst werden mussten. Nun ist sichteres Fahrwasser angesagt als noch vor 7-9 Monaten. Schau dir dir Changelogs seit der .34 mal an.

Es geht um konfektionierte Firmware für den jeweiligen Bedürfnissstand für Anfänger. Im Moment sind folgende Setups möglich.

Single
Single Dual
Single Dual Fräse
Dual
Fräse
Fräse Dual
Fräse Single

Um DIESE konfiguration geht es um die der User sich im Moment noch selbst kümmern muss (so wie ich das verstanden habe in der neuen Firmware nicht mehr).

Die weitere Unzulänglichkeit die langfristig kompliziert ist, ist die Verwaltung der Sourcen. Das ziehlt aber in Richtung Entwickler/Geeks

Lieben Gruß,
Udo

GitHub ist im Moment eine reine Veröffentlichlungs-Platform für die Sourcen. Bei unserem internen Entwicklungssystem gibt es natürlich keine kopierte Zeile Source Code sondern nur einen Stand, den wir wahlweise für den RF1000 oder RF2000 verwenden können (unglaublich, dass ich das überhaupt schreiben muss ).

Wie bereits beschrieben wird die Zukunft zeigen, wie genau die Entwicklung über GitHub weitergehen wird und davon abgeleitet wird sich ergeben, wie die Struktur der "Master" und "Development" Zweige aussieht. So wie ich die aktuelle Diskussion sehe werden wir es aber nicht allen Recht machen können

GitHub wird unser internes Entwicklungssystem nicht ersetzen, weil wir intern ja a) Dinge ausprobieren die dann doch nicht veröffentlicht werden und b) an zukünftigen Funktionen arbeiten, die nicht vorab veröffentlicht werden können.


mfG
RF1000