Neue Development Firmware (RF.01.21)

[RF1000]

Hallo,


wir haben heute die neue Version der Development Firmware auf GitHub hochgeladen. Diese meldet sich als "RF.01.21" und kann sowohl für den RF1000 als auch für den RF2000 kompiliert werden.

Das Change Log dazu lautet:

V RF.01.21 (2016-05-18)
- The last column and row of the heat bed/work part scan did not find their way into the heat bed/work part compensation matrix.
- Improved rounding of the x/y positions within the first row/column of the compensation matrix.
- In case both extruders were heated up before the heat bed scan, only the first extruder was turned off at the end of the scan.
- Adding of support for M3117.
- This command can be used in order to set a status text which is not overwritten by M117.
- M3117 makes M3110 obsolete, thus M3110 is not supported anymore.
- In case the Z-compensation is active, "Cmp" is displayed at the status display right to the current z-value.
- Adding of support for an alternative mode for the displayed z-value.
- In operating mode "print", the menu entry "Configuration" - "General" - "Z Scale" can be used in order to determine whether the displayed z-value shall be counted from z-min or from the surface of the heat bed.
- In operating mode "mill", the menu entry "Configuration" - "General" - "Z Scale" can be used in order to determine whether the displayed z-value shall be counted from the determined z-origin or from the surface of the work part.
- In case an error or a warning is detected by the firmware, an according error/warning information can be displayed directly at the display.
- The status information is displayed until it is acknowledged via a button (or until it is overwritten by a following status information).
- An eventually ongoing print/mill operation is not interrupted/delayed through a displayed status information.
- Additional information can be provided via the log of the connected PC application (Repetier-Host).
- In case FEATURE_EMERGENCY_Z_STOP is active, the strain gauge values are not examined anymore while the print/mill operation is paused.
- During this pause, someone might want to clean the extruder or to exchange the used tool of the miller. Such operations can bring high forces onto the strain gauge, in which case an emergency z block was possible.
- In case the z-origin at the beginning of a mill operation was not searched at the x/y start position of the work part scan, the determined z offset could be wrong.
- In case the firmware processes a long-lasting operation, it can notify an attached PC application via "busy:" packets. As a result, the PC application knows that the firmware is still alive and can avoid unnecessary timeouts.
- Adding of support for multiple (up to 9) heat bed z-compensation matrices.
- Possible use cases are different heat bed z-compensation matrices for different beds and/or different heat bed z-compensation matrices for different filaments/temperatures.
- The active heat bed z-compensation matrix can be chosen via M3009.
- Adding of support for a more precise heat bed scan.
- This more precise mode waits longer after heating up of the heating bed and extruders and it determines the static offset in z-direction which is caused by the changing length of the extruder at the printing temperature.
- The menu entries "Configuration" - "Z Calibration" - "Scan PLA/ABS" perform the scan with predefined temperature profiles for PLA/ABS.
- M3010 can be called with the S1 (PLA) or S2 (ABS) parameters now in order to start the scan with predefined temperature profiles for PLA/ABS.
- The G-codes M3030, M3031, M3032, M3033, M3040, M3041, M3042, M3050, M3051, M3052, M3053, M3054 and M3055 are available also in operating mode "mill" now.
- G0/G1 commands are allowed to overdrive Z-min now.
- The overdrive is limited through Z_OVERRIDE_MAX and allows G0/G1 to decrease the height of the first layer even in case Z-min is active already.
- An example use case can appear in case the calibration line is printed with a bigger height (e.g. 0.35 mm) than the first layer (e.g. 0.1 mm) - in such a scenario, the active z-compensation could drive the heat bed upwards so that Z-min is active already.
- The mode of the movement via the "Position X/Y/Z" menus can be configured now.
- Within these menus, the right menu button can be pressed in order to switch the mode between "Single Steps", "Single Move", "1 mm", "10 mm" and "50 mm".
- The mode which is chosen within the "Position Z" menu is applied also to the "Heat Bed up" and "Heat Bed down" hardware buttons.
- The speed of the PWM for the fans has been changed from ~15 to ~122 Hz.
- The maximal length in x direction has been changed to 230 mm for the milling mode.
- M3006 and M3146 support the Z parameter now which allows to configure the static z-offset in [mm].
- M3007 and M3008 support the Z parameter now which allows to configure the z-compensation scope in [mm].
- The codepage of all .cpp and .h files has been changed so that also characters like ° and µ can be used without warnings from the Arduino IDE.
- Improved description of all RF-specific M-codes within RF.h.
- M3013 P1 and M3153 P1 can be used now in order to output the z-offsets from the current z-compensation matrix in [mm] (instead of the default unit [steps]).
- The firmware has sent "Start" via USB instead of "start" after its startup, which could cause problems with applications like OctoPrint.
- Single moves into z-direction via the hardware buttons could continue although the button was released already.
- Minor clean-ups.

Die neue Firmware ist wie immer hier zu finden: https://github.com/rf1000/repetier-firm ... evelopment
Die Anleitung zum Aktualisieren der Firmware hier im Forum ist hier zu finden: http://www.rf1000.de/wiki/index.php/Firmware_Update


mfG
RF1000

[Wessix]

Klasse, das ließt sich ja nicht schlecht1 Bitte am Ball bleiben und weiter optimieren, sollte es jemals einen RF 3000 geben wird der mit Sicherheit davon profitieren.

[rf1k_mjh11]

RF1000,

..."RF.01.21"...Das Change Log dazu lautet:
....
- Improved description of all RF-specific M-codes within RF.h.
...

Einen Dank an das Entwicklerteam. Das ist wirklich gut, zumindest das, was ich beim schnellen Überfliegen gesehen habe. Zur Klarstellung immer ein Beispiel!

mjh11

[RF1000]

Hallo,


in der RF.01.21 hat der PLA/ABS-Modus vom Heizbettscan nicht so lange auf das Aufheizen gewartet, wie von uns geplant. Wir haben das mit der RF.01.23 korrigiert und diese auch auf GitHub hochgeladen.


mfG
RF1000

[mt-checker]

Guten Morgen,

der Change-Log hört sich ja vielversprechend an! Sogar der erst kürzlich gemeldete Fehler mit 'Start' wurde schon behoben
Allerdings bekomme ich es nicht hin die neue Firmware mit Arduino zu kompilieren...
Welche Version habt ihr verwendet um die Firmware zu kompilieren und zu übertragen?

Gruß Marco

[RF1000]

Hallo,


die Firmware ist mit Arduino V 1.6.5 zu kompilieren.


mfG
RF1000

[mt-checker]

Hallo RF1000,

mit der Arduino Version V 1.6.5 hat es geklappt

Bei ersten Test sind mir im Vergleich zur alten .48 Version allerdings ein paar Dinge aufgefallen:

1. Case Fan: Der Case Fan funtioniert nicht mehr. Laut Source-Code gibt es aber eine Case Fan Temp. Wann wird der Case Fan eingeschaltet und was für eine Temperatur ist gemeint bzw. wie wird dise gemessen?
2. Hotend Config: In der Konfiguration kann man das Hotend zwischen V1 und V2 umstellen. (Welche Auswirkungen hat das?) Jedenfalls wird diese Einstellung nicht gespeichert und ist nach einem Neustart wieder umgestellt (Von V1 zu standardmäßigem V2)
3. Filament entladen: Die Vorgehensweise bei dem Filamententladen ist nun anders. Bei meiner Version wurde zuerst langsam etwas Filament extruiert und danach der Filamentfaden schnell herausgezogen. Bei dieser Version wird das Filament gleich herausgezogen, was zur Folge hat, dass immer noch etwas Filament im Extruder verbleibt und heraustropft. Warum wurde dies geändert?
4. Keine Extruderbewegungen nach Entladen möglich: Schon bei der alten Version war es nicht möglich nach dem Entladevorgang das Ritzel mittels Tasten zu bewegen, obwohl der Extruder geheizt ist.
5. Heatbedscan PLA: Bei dem Heatbedscan für PLA wird der Extruder auf 100°C und das Bett auf 60°C aufgeheizt ("Aufheizen"). Danach wird noch etwas gewartet, bis die Wärme gliechmäßig auf dem Bett verteilt ist ("Heizen"). Ist diese Zeit verstrichen, so beginnt der Heatbedscan wie gewohnt. Soweit so gut. Jetzt kommt aber ein für mich unverständliches vorgehen, welches ein Loch in meine DDP gebrannt hat! Und zwar fährt der Extruder eine Position auf dem Bett an (vll soll das die Mitte sein?), sodass die Spitze auf dem Bett aufliegt, und heizt auf 230°C auf! Dort verharrt er dann einige Minuten in der Phase "Heizen" und danach ist der Scan beendet. Dadurch hab ich nun ein Loch in meiner Dauerdruckplatte...
   Beim ersten Heatbedscan war ich leider nicht anwesend um das Bett gleich nach unten zu bewegen. Jedenfalls ist dieser "Fehler" (wenn es denn einer ist) reproduzierbar. Warum wird das gemacht??
   Ich kann nur allen mit einer DDP empfehlen keinen Heatbedscan PLA zu machen, da dieser die DDP zerstört!

Gruß Marco

[rf1k_mjh11]

Marco/mt-checker,

...

2. Hotend Config: In der Konfiguration kann man das Hotend zwischen V1 und V2 umstellen. (Welche Auswirkungen hat das?) Jedenfalls wird diese Einstellung nicht gespeichert und ist nach einem Neustart wieder umgestellt (Von V1 zu standardmäßigem V2)

....

Was ich in der RF1000.h-Datei gesehen habe, könnte es es sich dabei einfach um die PID-Werte handeln. Die PID-Werte werden üblicherweise im EEPROM gespeichert. Diese Hot End-spezifischen Werte werden vermutlich beim erstmaligen flashen ins EEPROM gestellt, danach ist es egal welche Konfiguration aktiv ist, die Werte sind schon gespeichert.

Außerdem kann man die Werte jederzeit neu ermitteln lassen und/oder direkt ins EEPROM speichern (M204 zum expliziten festlegen ohne speichern, M303 zum ermitteln und speichern, oder M206 zum expliziten schreiben der Werte).

Ich bin gerade dabei, meine paar Änderungen in die RF.01.23 einzupflegen. Dann lasse ich einen HBS laufen und beobachte. Melde mich dann wieder (habe keine DDP - ich hoffe, es brennt dabei kein Loch in die Keramikplatte).

mjh11

[rf1k_mjh11]

Ich habe meine Änderungen in die RF.01.23 eingepflegt zu flashen versucht. Na ja, der erste Fehlschlag.

Ich musste eine neuere Arduino Version verwenden, die 1.01 war zu alt. Also die allerletzte Arduinoversion heruntergespielt (1.6.9), installiert und frohen Mutes LOS!
Denkste - massenhaft Fehlermeldungen. Der zweite Fehlschlag.

Gut, laut diesem Post sollte ich die 1.6.5 nehmen. Also die 1.6.9 deinstallieren, und die 1.6.5 installieren.

Jetzt hat es geklappt. Schade, dass man oft auf GENAU EINE Arduino Version beschränkt ist...
Morgen geht es mit dem HBS weiter. Dann melde ich das Ergebnis.

mjh11

[rf1k_mjh11]

Eines habe ich schon bemerkt. Die PID-Werte für mein Pico Hot End wurden überschrieben (das könnte evtl. eine Bestätigung meines Verdachts in diesem Post sein). Auch die PID-Werte des Betts wurden geändert.

Und die Kalibrierung der X- und Y-Achse blieb nicht gleich: hier änderte sich der Wert von jeweils 152.0000 Schritte/mm auf 152.3800 Schritte/mm. Das muss ich überschlafen und morgen ausrechnen. Ich glaube, irgendwo im Forum kam diese Diskrepanz schon einmal auf...

mjh11