Hallo zusammen,

ich habe dazu komischer Weise nichts im Forum gefunden,
aber es hat doch bestimmt schon mal diese Warnung in Octoprint gesehen, oder?
RF2000: offizielle Firmware

https://discourse.octoprint.org/t/octop ... s-mean/350

Ich habe auf Github mal die Versionsstände verglichen. Repetier kann das mittlerweile, aber nicht der Stand von dem die Renkfore Firmware geforkt wurde.
Daher erklärt sich die Warnung.

Es gab aber schon lange keine Update mehr.
Die letzte Version ist von 2017-12-19.
Arbeitet bei Conrad/Renkforce wer an einer neuen Versionen, oder ist das nun tot?
Wäre schon schräg bei dem Preis.

Dann müsste ich mich doch mal an die Community Firmware wagen, was ich mich bis jetzt nicht getraut habe,
da ich nicht weis was das für Probleme mit sich bringen kann.
Gibt es dort das fehlende Feature bereits?
Funktioniert der Drucker wie bisher, nur mit neuen Features,
oder ist dann vieles anders? Muss man neu kalibrieren oder was an den Slicer Profilen anpassen?

Die Ursache für die Warnmeldung ist, glaube ich, reiner Zufall:

Man kann sich ja die Source von Octoprint hier anschauen: https://github.com/foosel/OctoPrint/blo ... _init__.py
Da wird nach Repetier_%VERSION% gesucht. Ist das < 0.92 kommt diese Warnung.
Mich hat eben gewundert, warum wir mit einer Version 1.38 / 1.39 / 1.42 gewarnt werden.
https://github.com/RF1000/Repetier-Firm ... onstants.h In dem Fall vermute ich, dass das Pyphon-Script die Zeichen RF. nicht korrekt in eine Zahl übersetzen kann.
("from octoprint.util.version import get_comparable_version" https://github.com/foosel/OctoPrint/blo ... on.py#L120 )

Ohne das jetzt genau zu verstehen wird die get_comparable_version("Repetier_RF.01.39") zu 0 oder false und damit kleiner wie 0.92. Kann mich hier aber irren, hab das nur überflogen.
Es ist also nicht so, dass Gina Häußge absichtlich wissentlich Conrad abstraft, sondern vermutlich wäre das fehlende Feature ohne die eigenwillige RF.-Versionierung nie aufgefallen

-> Für mich heißt das, ich muss die Versionsnummer ändern, denn sonst hat auch der Mod die Warn-Meldung drin, obwohl er es ziemlich sicher nicht (mehr) verdient hat.

foosel hat geschrieben:"All Repetier firmware versions prior to 0.92 as thermal runaway/decoupling detection was only added in 0.92."

Ab 1.42.22.Mod funktioniert das Safety-Feature, so wie ich informiert bin.

Ich werde mich mal schlau machen, wie ich auf die zweite Mini-SD-Card Octoprint installieren kann, um das genauer zu testen. Wenn es auch beim Mod anschlägt, ändere ich die Version-Nummer der Firmware so, dass das RF. rausfällt.

LG

Den Python Code habe ich mir noch nicht angeschaut. Trotz Fehler hatte sie aber zufällig recht. Schon lustig
Du kannst aber für deine Version sicherlich einen Patch für Octoprint erstellen oder Gina lieb darum bitten das zu fixen.
Dafür musst du nicht gleich deine Versionierung ändern.

Wie ist das nun mit dem Umstieg auf die Community Firmware. Einspielen und geht oder muss man da noch mehr machen?

Gruß,
Gerhard.

Du brauchst Arduino 1.8.x (Das uralte Arduino 1.6.5 o.ä. wird nicht funktionieren)
https://github.com/RF1000community/Repe ... evelopment
Dann Mainboard-Konstante in der configuration.h auf deinen Druckertyp (RF1000/2000/2000v2) ändern und aufspielen.

Mach anschließend einen PID-Autotune übers Druckermenü und dann dürfte eigentlich alles laufen. (Siehe auch Readme.md)

Für mich wäre zudem sehr interessant, was die EEPROM-Settings direkt nach einem Upgrade von 1.3x auf den Mod machen. Könntest du mir das EEPROM-Listing schicken, wenn du zum Mod wechselst?

Die Version würde zukünftig dann eben 1.43.20 statt RF.01.43.19 heißen, diese Änderung ist zu verschmerzen

LG

Ja, also die Änderung von RF.xx.xx.xx auf xx.xx.xx entfernt die Warnung.

Ich habe zudem gesehen, dass man in Octoprint die SD-Karte verwalten kann. Das funktioniert aber glaube ich nicht ganz sauber* und wird wohl mein nächstes Hobby werden

LG

* Zu testen

ich werd das eeprom auf jedenfall sichern vor dem Upgrade, damit ich wieder zurück kann falls notwendig.
Du meintest aber das eeprom nach dem update wenn ich dich richtig verstanden habe, oder?
Migrierts du wohl die Daten? Vorbildlich.

ich werde aber nicht vor dem WE dazu kommen.

Das mit der SD Karte verwende ich nie mit Octoprint. Wird ja direkt als Druckserver verwendet, wobei es dann auf dem Raspi gespeichert wird.
Ist in Slic3r super integriert, für Cura gibt es ein Plugin, bei S3d muss man da etwas mit curl tricksen, aber geht zumindest.

Die SD-Karte verwende ich nur als Notfall wenn der Raspi gerade mal nicht laufen sollte. Ist aber so gut wie nie der Fall.
Da muss man ja hin laufen...

Ja genau, ich migriere die Daten - aber mit einer Bedingung:

Nur für den Fall, dass die Zahl in der Configuration.h ~ Zeile 69
#define EEPROM_MODE 121
gleich deiner bisherigen im EEPROM gespeicherten EEPROM_MODE ist.
(Ist die aktuell gespeicherte EEPROM_MODE aufgrund einer uralten Firmware oder sehr neuen Firmware nicht mehr 121, dann verwirft auch die Mod-Firmware deine Settings.)

Generell gilt: manche EEPROM-Settings, die wir einem Fehler zuordnen konnten, werden automatisch korrigiert.
Ich frage, weil es manchmal Fälle gibt, bei denen ich mich über die Fehlerbeschreibungen stark wundere. Mit einer ganz kleinen Chance hilft uns zukünftig so ein Auszug "nach" dem Upgrade aus der Log.
Sollte ich darin extrem komische Werte entdecken, wäre natürlich auch deine Sicherung vor dem Upgrade interessant. Aber das alles nur, wenn es dir keinen Aufwand macht!

Hol dir dann am WE auch die development-Version des Mods. Also 1.43.20 oder höher.

LG