Neue Firmware für RF1000 und RF2000 (RF.01.10)

[mhier]

GitHub ist im Moment eine reine Veröffentlichlungs-Platform für die Sourcen.

Ok das verstehe ich und so sieht es auch aus. Aber dafür würde es auch ein ZIP-Download auf einer Webseite tun.

Ich möchte gerne die Möglichkeit haben, an der Firmware zumindest Kleinigkeiten zu verändern (z.B. die Anzeige der z-Position wie in einem anderen Thread besprochen). Diese Änderungen möchte ich gerne auch mit anderen teilen. Wenn das eine oder andere davon in die offizielle Firmware übernommen wird, wäre mir das eine Ehre. Wenn nicht, ist es auch gut. Aktuell sehe ich aber die Problematik, dass ihr anscheinend per SVN eine Arbeits-Kopie (in welcher Form auch immer) der zugrunde liegenden Repetier-Firmware in eurem Team angelegt habt und es für einen Community-Entwickler wie mich (oder vielleicht auch auch riu ) keine Möglichkeit gibt, vom eigentlichen RFx000-Repository einen Fork anzulegen. Solange die Verzeichnisstruktur identisch bleibt zwischen GitHub und dem eigentlichen Repository wäre das alles kein Problem...

In jedem Fall stimme ich zu, dass es für den Durschnitts-Anwender einfacher sein sollte, die Firmware zu installieren. Dafür ist GitHub der falsche Ansatz, da stimmen wir glaube ich alle überein. Mein Vorschlag wäre deshalb, das GitHub-Repository in der von mir beschriebenen Weise umzubauen. Dadurch wird für den normalen Anwender nichts komplizierter. Er muss sich weiterhin nicht um Branches oder Forks kümmern, er klickt einfach wie bisher auf den Link (der ist eben nur etwas anders) und bekommt den Download als ZIP. Es wird eher noch einfacher, weil er nicht mehr unnötigerweise immer beide Verzeichnisse bekommt, sondern nur das was er braucht. Gleichzeitig gibt es für fortgeschrittene Anwender mit Entwickler-Hintergrund die Möglichkeit selbst aktiv zu werden.

Bitte blockiert das nicht. Der riesen Vorteil eines offenen Systems ist, dass sich eine aktive Community bilden kann, die ein Produkt extrem weiter bringt. Es wäre schade, wenn mehr oder weniger aus Bequemlichkeit die Entwicklung hier gleich im Keim erstickt wird...

EDIT: Um nochmal zu demonstrieren, was ihr mit der Verzeichnisstruktur kaputt gemacht habt, schaut euch mal bitte die History-Informationen zu beliebigen Souce-Code-Dateien im GitHub an. Die sind alle quasi leer, die Verbindung zum Original Repetier ist gebrochen. Das ist ein riesen Problem!

[riu]

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 ).

Das habe ich verstanden. Jetzt ist es eine reine Veröffentlichung, nachdem ihr von repetier/Firmware geforkt habt. Mir ist es völlig egal was ihr da treibt, aber im Sinne des Erfinders ist das nicht.

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

Das hast du vielleicht missverstanden. Es geht nicht um Recht machen sondern um Sinn und Zweck. Wenn Ihr von der Community keine Hilfe braucht oder wollt, dann macht ein Tarball und packt den auf die Shopseiten unter die Downloads.

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.

Wenn Ihr die Hilfe und die Manpower der Community nutzen wollt, dann macht doch einen eigenen public SVN Server oder nutzt Sourceforge. Da könnt Ihr euch austoben seid in eurem Universum, habt aber die Möglichkeit von den Entwicklern, die nicht weniger genial sind als andere auch, zu profitieren. Nochmal mir ist es völlig egal da mein Drucker das macht was er soll. Ich werde, wenn überhaupt meine Needs selbst reincoden. Das bekomme ich gerade noch so hin

Ich und ich denke auch mhier sehen das ganze Bild und auch die Zukunft des RF1000 die sich so ein wenig von den Mitbewerbern abheben könnte - und zwar im Sinne des "Anwenders".

Lieben Gruß,
Udo

[Zaldo]

keine Hilfe [...] wollt

Brauchen würden Sie sie eigentlich. Aber, ja. Ich nehme an da läufts drauf raus. Es ist wohl anscheinend nicht erwünscht.

[mhier]

Achtung, die neue Firmware hat gerade meinen Endschalter zerschossen:
http://www.rf1000.de/viewtopic.php?f=7&t=1025

[Zaldo]

Ich habe die 01.10 nun auch mal draufgespielt und das erste was mir auffällt sind reihenweise Übertragungsfehler zwischen Repetier Server auf RPI und dem Drucker, zu sehen in der Konsole.

111.jpg

Noch führe ich das mal darauf zurück, dass die Baudrate von 250000 auf 115200 geändert wurde. Jedenfalls werde ich sie mal wieder auf 250000 setzen und beobachten.

Zweitens, Ja. In bestimmten Stellungen machen die Motoren Höllengeräusche. Irgendwas wurde an den Motoralgorithmen gedreht, und so wie es sich anhört, nicht zum guten.

Und dass die Fahrtastem am Drucker nun keine Einzelschritte mehr machen, sondern direkt losfahren ist ja mal völliger Kappes. WIE BITTE JA WIE soll ich denn jetzt das Bett nach oben fahren bis der F-Wert steigt, um den Offset Wert zu ermitteln? Denn mit G1 geht das ja bekanntermaßen nicht, das muss man an den Hardwareknöpfen machen.

[Zaldo]

Also die Übertragungsproble - woher Sie jetzt auch kommen - haben nichts damit zu tun. Weder das rücksetzen der Baudrate auf 250000 noch der Wechsel zurück auf die .59 hat da jetzt etwas dran geändert.

[tron]

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.

Bei git ist es ja nicht so der Akt, bestimmte Branches nur intern laufen zu lassen und einen Branch extern auf github um etwaige Pull Requests auch einfach annehmen zu können - ich bin da ganz bei Udo - eine kleine aber feine externe Entwicklergemeinde kann so ein Hard/Softwareprojekt schon gewaltig unterstützen - neben der Tatsache, dass ein angenommener Pull Request eine Kundenbindung und Produktbindung schafft, die man mit keiner Werbung hinbekommen kann ...)

Bsp: https://www.braintreepayments.com/blog/ ... -workflow/