Neue Development Firmware (RF.01.35 - Weihnachts-Update)

[Nibbels]

Board: 000206-02 RF2000
Atmel: 1519

Screenshot_2.jpg

Screenshot_1.jpg

atmel.jpg

Windows 10 x64
Arduino 1.6.5 von .cc läuft. Druck über RaspberryPI3. Bisher ist mein Drucker genau 1x stehengeblieben. Weiß aber nicht warum. Als ich zurückkam waren die Temperaturen am Fallen. Fehler war nicht wiederholbar. Lief sonst stabil.
Arduino 1.8.0 mit dem Fix für Pins.h -> Firmware Instabil wie bei Speedbug (bei OutputObject während dem Warten auf Output-Bewegung.)

LG

[rf_42]

Hallo!

Bei sind es folgende Daten:
Board: 000063-51 Jahr 2015
Atmel: 1519

Das Flashen lief über Linux (Tumbleweed x64 Version) und der Arduino Entwicklungsumgebung 1.8.0.
Bis jetzt habe ich keinerlei Probleme feststellen können (habe aber auch noch nicht viel damit gedruckt.

Allerdings habe ich nach der Info, daß sich identische Firmware Images auf unterschiedlichen Rechnern (sporadisch?) unterschiedlich verhalten, mal die Firmware noch einmal mit dem höchsten möglichen Warning Level compiliert (in arduino/avr/platform.txt : Verwendung von compiler.warning_flags.all). Dabei ist mir aufgefallen, daß der Compiler da einige 'uninitialized ...' Warnungen ausspuckte wie z.B.

Code: Alles auswählen

/tmp/arduino_build_949562/sketch/Extruder.cpp:1063:30: warning: 'newraw' may be used uninitialized in this function [-Wmaybe-uninitialized]
/tmp/arduino_build_949562/sketch/Extruder.cpp:1587:1: warning: missing initializer for member 'Extruder::enabled' [-Wmissing-field-initializers]
/tmp/arduino_build_949562/sketch/SdFat.cpp:1135:3: warning: 'p' may be used uninitialized in this function [-Wmaybe-uninitialized]

Diese habe ich einmal testweise mit 0 / nullptr initialisiert (die Stellen befinden sich alle in den cpp Files)

changed_sourcefiles.zip

. An dem Flashen der Firmware hat sich nichts geändert. Es funktionierte weiterhin einwandfrei. Interessant wäre es aber zu wissen, ob damit diese Merkwürdigkeiten bei den Druckern mit den Problemen dann immer noch auftreten, oder ob diese nicht initialisierten Speicherbereiche keine Auswirkungen haben.

Allerdings sollten diese Änderungen NUR der / die Firmware-Entwickler erst einmal begutachten und testen, da ich dafür keinerlei Garantie übernehmen kann (@Marcometaner: Könntest Du diese Files an die Entwickler weiterleiten? Das wäre echt nett). Ich bin leider noch nicht dazu gekommen, dies selber zu testen. Geplant ist das für nächstes Wochenende.

Viele Grüße


P.S.:
- Die Liste mit den herausgefilterten relevanten und um Duplikate bereinigte Warnings-Liste befindet sich hier:

warning_locations.orig.txt

- Die geänderten Headerfiles in

changed_sourcefiles.zip

enthalten nur die korrekt aufgesplitteten C Line Comments welche vorher unglücklicherweise am Ende von '#define ...' Lines enthalten waren und seit 1.6.6 von der Arduino Entwicklungsumgebung öfters nicht mehr so gern gemocht werden .

P.P.S.: In Github besteht die Möglichkeit Pull Requests einzustellen (siehe https://github.com/RF1000/Repetier-Firmware/pulls)
FRAGE: Ist das ok, wenn man diese Funktionalität benutzt oder ist das eher nicht so gern gesehen?

[Nibbels]

Genau dasselbe habe ich die letzten 2 Tage gemacht. Ich werde mir deine Logs genau ansehen, wie du die Stellen geändert hast.
Ich habe Compilerwarnungen = Alle

und beim Mod alle Warnungen ausgeräumt bis auf:

restewarnings.txt

Beim untern Block sehe ich noch Chancen, das wie alles andere mit Stackoverflow.net etc. auszuknobeln, aber bei den Pointern oben .. eher nicht ^^. Solltest du, rf_42, die Ursache aus dem Stand sehen, schick mir ne PN.

LG

PS: Ganz interessant finde ich das hier: (RF2000, Mod)
Arduino 1.8.0: "Globale Variablen verwenden 6257 Bytes (76%) des dynamischen Speichers, 1935 Bytes für lokale Variablen verbleiben. Das Maximum sind 8192 Bytes."
Arduino 1.6.5: "Globale Variablen verwenden 6265 Bytes (76%) des dynamischen Speichers, 1927 Bytes für lokale Variablen verbleiben. Das Maximum sind 8192 Bytes."

[rf_42]

Ich habe nur die Stellen angepaßt, welche der Compiler explizit angemahnt hat, erweitert. Das Einzige, was komplizierter war, ist die Initialisierung des 'extruder::enabled' Flags der Extruder-Klasse in den Universal Initializer Lists, da die Stelle schwer zu finden ist.

Code: Alles auswählen

#if STEPPER_ON_DELAY
        , '\x0' // Extruder::enabled
#endif // STEPPER_ON_DELAY

[Nibbels]

ich hatte da bisher einfach 0 eingetragen. Und diese Stelle auch fast genau so bearbeitet. Auch für die restlichen Extruder, so muss das also 5x rein.
Ist '\x0' hier besser als eine normale 0 ?

LG

[Nibbels]

Hier: gibts die Funktionen memcopy2 und memcopy4
https://github.com/repetier/Repetier-Fi ... Repetier.h

das Fixed folgend in Zeile 192ff (usw.):
https://github.com/repetier/Repetier-Fi ... d.cpp#L192
alle "warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]"
in den Zeilen 279ff der RF.1.35

Ich teste das die Tage dann über den Repetier-Host ob das Hochladen und schrieben auf SD-Karte damit problemlos möglich ist.

LG

[R3D3]

Hi Nibbels, rf_42,

Große Güte, das mit den letzten Posts geht ja sehr tief ins Detail übers Kompilieren, davon habe ich (und viele Forummitglieder/-leser mit mir, vermute ich), sagen wir mal, nur sehr wenig Ahnung

Da ich jedoch auch Interesse an eine RF.01.35 (oder stabiler(er) Nachfolger) habe - was genau bedeutet dies alles für den nicht-ganz-DAU, der demnächst (eventuell nach Umschreibung für ein Dual setup des RF1000 ) upgraden möchte? Dabei habe ich bereits aus anderen Posts verstanden, das Kompilieren geht mit Arduino 1.6.5 am einfachsten, korrekt?

Danke für allgemeinverständliche Hinweise

[Nibbels]

Stimmt, das "Was und Warum" ist evtl. ein bischen untergegangen.
Weil ich grad wieder mal kurz da bin, greife ich rf_42 etwas vor
Er hatte das im Grunde initiiert, ich hab mich dann eingemischt, weil ich das was rf_42 rausgefunden hatte gelesen hatte und gebrauchen konnte.

1)
Es gibt mehrere Versionen von Arduino Compiler (immer neue Updates) und anscheinend hat sich da in der Versionsreihe beim Arduino Compiler etwas geändert, sodass die RFx000-Firmware auf der Arduino Version 1.6.5 compiliert werden kann, aber auf der 1.8.0 nicht mehr. (Nicht mehr ohne Anpassung kleiner Details in der Firmware.) Das war schon länger bekannt und es steht auch im Forum. (http://www.rf1000.de/viewtopic.php?f=7&t=68)
2)
Der Arduino Compiler (nur 1.8.0) spuckt neben den Fehlern zusätzlich eine ganze Menge Warnungen (1.6.5 wie auch 1.8.0) aus, wenn man die Firmware kompilieren will. Die Warnungen sieht man normalerweise aber nur, wenn man sie im Arduino Compiler scharf stellt.

Screenshot_2.jpg

Screenshot_1.jpg

Einstellen + Restart des Arduino

Was wurde mit den Infos tatsächlich gemacht? Timeline:
- Ich habe (auf Github) in mhiers z-Offset-Mod Version der Firmware, die Änderungen von Firmware 1.33 auf 1.35 übernommen, indem ich alle Änderungen, die RF1000 gemacht habe, auch dort umgesetzt habe.

- Als rf_42 hier gemeldet hatte, dass es möglich ist, die Fehler, die der Arduino Compiler 1.8.0 ausspuckt zu beheben, habe ich auch seine Änderungen in "meiner ebenfalls auf Github liegenden" Kopie von mhiers Firmware übernommen.
- Danach konnte ich mit dem Arduino Compiler 1.8.0 die Firmware kompilieren und auf den Drucker spielen.
- Der Drucker lief super, aber mir ist der Drucker abgestürzt, wenn ich OutputObject ausgeführt habe. Warum ist mir zur Zeit noch unklar. Mit 1.6.5 gings aber.
Also blieb ich beim Arduino Compiler 1.6.5.
- Das hat mich doch irgendwie gewurmt. Ich hab mich also vor ein paar Tagen drangemacht und jede einzelne Warnung "behoben", sodass ich sehen konnte wo sich diese "einfach sichtbaren" kritischen Stellen in der Firmware befinden könnten.

Warum?
Die Aktion ist tatsächlich ohne tatsächlichen Nutzen, ich habe das nur gemacht, weil ich sehen wollte, ob mir dadurch zufällig irgendwas klar wird, was das komische Verhalten von 1.8.0 erklärt.
Vermerk an dieser Stelle: Der Drucker läuft auch mit den Warnungen! Nur konnte ich vor lauter Detailwarnungen das evtl. Wichtige nicht sehen und mich hats gestört.

Inzwischen sind fast alle (bis auf zwei) Warnungen beim z-Mod raus und ich habe dadurch einiges gelernt. Der Code wurde also aus Compiler-Sicht etwas sauberer. Ich habe Details vereinheitlicht und ein paar Kleinigkeiten korrigiert. Das kam gestern Abend wieder dem z-Offset-Mod zugute, denn nun wusste ich, wie ich den zMod (vermutlich-) sinnvoll umbauen konnte.
LG

[R3D3]

Hallo Nibbels,

Danke! Das beruhigt ein Wenig fürs spätere

Dies ist wohl die angesprochene Modifikation: http://www.rf1000.de/viewtopic.php?f=7&t=1504#p14882

Hört sich an sich ganz vernünftig/nützlich an... mal schauen, ob ich die auch übernehme wenn ich die "35+er" eh' umschreiben muss (allerdings habe ich bisher nur sehr begrenzt Haftungsprobleme, zumindest teilweise DDP sei Dank).

[Nibbels]

Dies ist wohl die angesprochene Modifikation: http://www.rf1000.de/viewtopic.php?f=7&t=1504#p14882

Genau!

Die Firmwares:
https://github.com/RF1000/Repetier-Firm ... evelopment Original 1.35
https://github.com/RF1000/Repetier-Firm ... a4661fe25d Original 1.33
https://github.com/mhier/Repetier-Firmw ... ffset_scan mhiers Z-Offset-Scan 1.33
https://github.com/Nibbels/Repetier-Firmware/ meine RF2000-Version, die vermutlich auch auf dem RF1000 gut läuft. 1.35
Ich habe noch keine Rückmeldung bekommen, ob meine Version jemals absolut korrekt auf einem RF1000 gelaufen ist. Es sollte funktionieren, aber ich kann das nicht testen. Wer nicht den vollen Überblick hat, sollte zum Original greifen ^^.

LG