Community Mod RFx000 Firmware :: Neue Stable (Stand 1.37v8 / 18.10.2017)

[Nibbels]

Wir haben die alte Community Stable-Mod Firmware (Stand 1.37j / 24.04.2017 + wichtige Patches) durch eine neue Version ersetzt, die der development Revision 1.37v8 entspricht.

Link: https://github.com/RF1000community/Repetier-Firmware

Im Grunde war dieser Schritt schon lange überfällig - die Überlegenheit der Entwicklungsversion war schon Monate völlig klar, doch wir wollten sicherstellen, dass die neue Stable maximal rund läuft und ziemlich 'vollständig' ist.
mhier hatte bereits vor über einem Jahr mit der Entwicklungsarbeit begonnen, ich hab schnell Blut geleckt und bin auch seit knapp einem Jahr dran richtig aufzuräumen. Wir sind ziemlich pingelig, aber unter Umständen ohne Community-Tipps im Detail möglicherweise ein wenig betriebsblind. Einige der schlimmsten Bugs wurden durch eure Adleraugen-Tipps gefunden und behoben.

Frägt man Github, dann zählt es im Vergleich zur Conrad 1.37 nun schon über 984 Commits.

Die meisten dieser Commits hatten folgenden Zweck:

• Einen Fehler beheben.
• Code vereinheitlichen. / Die Ordnung im Code zu verbessern, um Fehler später leichter zu finden.
• Einen Patch von Repetier übernehmen, sodass die Mod Firmware mehr auf dem technischen Stand von 2017 (als Anfang 2014) ist.
• Ein bis dato 'geheimes/unsichtbares/undokumentiertes/halbdokumentiertes' Feature auf den heutigen Stand reparieren und im Menü+EEPROM zur Verfügung zu stellen.
• Ein neues nützliches Feature einzubauen. (Oder ein unsinniges Feature wieder auszubauen.)
• Die Drucker-Präzision, Lautstärke und Performance im Detail zu verbessern.
• Die Sicherheit bei der Bedienung des Druckers zu erhöhen.

Komplette Changelog:
https://github.com/RF1000community/Repe ... ngelog.txt
Alle Commits:
https://github.com/RF1000community/Repe ... ity_stable
Bug-Tracker im Forum:
http://www.rf1000.de/wiki/index.php/Rep ... ug_Tracker

Wichtig

• Wenn ihr den Mod aufgespielt hattet: Vergesst bitte die ganzen 84 alten Mod-Versionen diverser Nummerierung, schmeißt die neue 1.37v8+ drauf. Sonst nutzt ihr eine Firmware, bei welcher irgendwas nicht völlig zuverlässig funktioniert .
  Ganz neu: Materialextrusion ohne Rundungsfehler
  
• Meldet uns bitte jeden Fehler, jedes nicht funktionierende oder unsaubere Detail in der neuen Firmware (oder höher), die euch auffällt. Egal wie pedantisch das zu sein scheint. Meist sind eure Tipps nur die Spitze des Eisbergs

LG



PS: Natürlich gilt trotz unsere Sorgfalt, dass der Community-Mod keine offizielle Hersteller-Firmware ist. Und:
"Für etwaige Schäden, die an Ihrem Gerät entstehen könnten, kann keine Verantwortung übernommen werden. BENUTZUNG AUF EIGENE GEFAHR."

[Cofru]

Moin,
beim Versuch die 1.37v8 mit Arduino 1.65 zu kompiliren bricht der Vorgang mit folgenden Fehlern ab:
---------------------schnipp---------------------------
Der Sketch verwendet 256.556 Bytes (101%) des Programmspeicherplatzes. Das Maximum sind 253.952 Bytes.
Globale Variablen verwenden 6.743 Bytes (82%) des dynamischen Speichers, 1.449 Bytes für lokale Variablen verbleiben. Das Maximum sind 8.192 Bytes.
processing.app.debug.RunnerException: Der Sketch ist zu groß; unter http://www.arduino.cc/en/Guide/Troubleshooting#size finden sich Hinweise, um die Größe zu verringern.
at processing.app.debug.Compiler.size(Compiler.java:340)
at processing.app.debug.Compiler.build(Compiler.java:123)
at processing.app.Sketch.build(Sketch.java:1109)
at processing.app.Sketch.build(Sketch.java:1084)
at processing.app.Editor$BuildHandler.run(Editor.java:1955)
at java.lang.Thread.run(Thread.java:745)
Der Sketch ist zu groß; unter http://www.arduino.cc/en/Guide/Troubleshooting#size finden sich Hinweise, um die Größe zu verringern.
----------------------schnapp---------------------

Was kann jetzt getan werden um die neue stable installieren zu können?

Viele Grüße

[AtlonXP]

Hallo Cofru,

wart noch ein bisschen mit der neuen FW.
Der Speicherfehler sieht nicht gut aus, ich werde das jetzt gleich testen.

Nippels ist gerade dran, noch ein paar Kleinigkeiten einzupflegen.
Wenn dies getan ist bekommt die FW auch von mir eine Empfehlung.

LG AtlonXP

[Cofru]

Hallo AtlonXP,
ich warte noch. Und vielen Dank für eure Mühe !
Gruß, cofru

[Nibbels]

Danke für die Rückmeldung

Ich lade mir später nochmal die alte Arduino 1.6.5 runter und teste. Mit der 1.8.4 / 1.8.5 gings bei mir.
Evtl. optimiert der nicht so stark? Oder anders?

Der Sketch verwendet 256.556 Bytes (101%) des Programmspeicherplatzes.

Diese Zahl: 256.556 muss umgerechnet in Hex unter 3C000 bleiben. (Dahinter beginnt der Bootloader, der aber nicht überschrieben werden kann und soll.) Für die Kenner: Der Arduino sollte mit -0s optimieren.
‭245760‬ ist das Maximum, was rauskommen darf. Das sind irgendwo um 95% des EEPROM-Bereichs.

Ich check das nachher gleich!
Hast du in der Configuration.h was spezielles eingestellt?

LG

[AtlonXP]

FW 1.37 V8

Kompiler Verifizieren = OK
Hochladen auf den RF 1000 = OK


Der Sketch verwendet 244.392 Bytes (96%) des Programmspeicherplatzes. Das Maximum sind 253.952 Bytes.
Globale Variablen verwenden 6.591 Bytes (80%) des dynamischen Speichers, 1.601 Bytes für lokale Variablen verbleiben. Das Maximum sind 8.192 Bytes.
Wenig Speicher verfügbar, es können Stabilitätsprobleme auftreten.



FW 1.37 V9 (Test Version)

Kompiler Verifizieren = OK
Hochladen auf den RF 1000 = OK


Der Sketch verwendet 244.516 Bytes (96%) des Programmspeicherplatzes. Das Maximum sind 253.952 Bytes.
Globale Variablen verwenden 6.600 Bytes (80%) des dynamischen Speichers, 1.592 Bytes für lokale Variablen verbleiben. Das Maximum sind 8.192 Bytes.
Wenig Speicher verfügbar, es können Stabilitätsprobleme auftreten.

Es scheint alles normal zu sein.

LG AtlonXP

[AtlonXP]

Meine Kompilerversion ist die V1.6.5.

[Maggo-3]

Bei mir lief das Hochladen übrigens gestern auch problemlos.

[Nibbels]

Ok, also bei mir gehts in jedem Fall, bei AtlonXP auch.
Wir haben grad noch telefoniert.
Ich weiß, dass manche Compiler Probleme damit hatten, die Firmware so klein zu bekommen, wie sie normalerweise ist. Normal ist das aber nicht.

mhier hatte letztens noch was gepatched, sodass auch cmake diese "link time optimization" durchführt und nicht vergisst.
https://github.com/Nibbels/Repetier-Fir ... 9fd35733b4
Eben sind mir auch einige ältere Features unter die Augen gekommen, die ich nun wenn benötigt von euch über die configuration.h optional aktivieren lasse.
Das spart ein paar Bytes, aber ich vermute, dass bei Cofru der Hund woanders begraben liegt.
Evtl. hilft es schon, wenn Arduino deinstalliert und neu installiert wird?
(Es gibt ja auch mehrere Arduino Patch-Revisionen einer 1.6.5 und neuerdings die 1.8.5 https://www.arduino.cc/en/Main/Software , die auch funktionieren sollte.)
Da ich gerade dran war, habe ich die oben genannte 1.37v9-Testversion nochmal mit 1.37w überpatched und damit die Details, die wir gestern beim 3D-Druck-Treffen in Neuenstadt angesprochen hatten umgesetzt.)

Notfalls eine Version größer 1.37w ziehen und den Millingmode in der rf2000.h rausnehmen:

Code: Alles auswählen

/** \brief Allows to use the device for milling */
#define FEATURE_MILLING_MODE                1                                                   // 1 = on, 0 = off

->

Code: Alles auswählen

/** \brief Allows to use the device for milling */
#define FEATURE_MILLING_MODE                0                                                   // 1 = on, 0 = off

V RF.01.37w.Mod (2017-10-21)
- make #define FEATURE_MILLING_MODE 0 work again to save eeprom space / possibility to exclude millingmode from firmware
- set standard emergency-block back to 10000. this is configurable within menu and eeprom afterwards

V RF.01.37v9.Mod (2017-10-20)
- added more temperature tolerance when unpausing print to start faster.
- #define MIN_EXTRUDER_TEMP 80 as discussed in Neuenstadt
- fit adjustment of offset within mod-menu to up-down-rule outside of mod-menu. Switch of direction for RF-Z-UP and RF-Z-DOWN within mod-menu. (Thx AtlonXP)
- Implemented new G-Code M3911 S[F-Min] P[F-Max] E[extrusion decrease -99..0 / increase 0..99] to have unwanted high digits influencing extrusion percentage.
This is AtlonXPs "linear digit flow compensation"
which might get handy having slight overextrusion on solid parts
or to secure flex-prints. (It will not work within long straight lines, because move-cache will delay its effect)
- Test for very deep z-matrices: when z-compensation has to do more work than 0.5mm wait!
- tell repetier and octoprint to stop the print in case of temperature sensor error
- FEATURE_READ_STEPPER_STATUS has now to be enabled in configuration.h to safe eeprom space. Normal users dont need it.
- Removed leftovers (depreached text message) from SilentMode M3920 to save EEPROM space

Die 1.37w ist noch nicht auf dem Community-Stable-Branch!
Aktuell hier: https://github.com/Nibbels/Repetier-Firmware
AtlonXP muss mir erst noch ein paar Details bestätigen, die er aber heute nicht mehr testen kann. Es sollte schon jetzt alles korrekt funktionieren, aber er hat dafür das bessere Testgerät um abschließend das OK zu geben
(Darum gehts: Mein Z-Endschalter ist nicht so weit überfahrbar, ich meine die Z-Kompensation pausiert nun den Druck, wenn sie völlig falsch steht, bis sie richtig steht. -> Das betrifft eigentlich niemanden ausser AtlonXP ..)

LG

[Cofru]

Moin!
Ich habe hier den RF2000 für den ich compiliere. Ich habe ledigich in der configuraion.h
den Eintrag
#define MOTHERBOARD DEVICE_TYPE_RF2000
vom Kommentar befreit.
Ich lade mal die 1.84 herunter.
Viele Grüße,
cofru