Community Mod RFx000 Firmware :: Neue Stable (Stand 1.37x7 / 26.11.2017)

[Nibbels]

Genau 1060 sind frei.
Wie ich nachweisen konnte müssen mindestens 870 frei bleiben. Oder mehr.

[Nibbels]

Ich hatte eben mit dieser Ram-Reduzierten 1.38.34.Mod beim OutputObject M3079 einen Crash. (Genau nachdem mein Stepper gebrochen war und ich den Druck abbrechen wollte.)
Muss mal schauen ob ich es auf den Ram die neue StopPrint-OutputObject-Funktion oder den Watchdog zurückführen kann.

LG

[Nibbels]

Uns sind vorher beim Stammtisch wieder ein paar Details aufgefallen:
Ich habe diese Fehler/Verbesserungen schon auf meinen Account auf Github geschoben, muss sie aber morgen erst noch selbst testen!
Bis dahin ohne Gewähr.

• Unter anderem ist mir dabei ein Fehler ins Auge gestochen, der nicht so schön ist: Ich hatte ein Array mit Index [E_AXIS] genullt, was ich nicht tun hätte dürfen, weil das Array nicht so lang ist, dass E_AXIS dazugehört. ... Overflow
• Der HBS Scan bekommt am Ende Vollbild-Meldungen, die man wegklicken muss.
• Beim RF1000 habe ich ein paar Menütexte entdeckt, die unnötig lang sind. Wir hatten 2 RF1000 beim Treffen da, darum habe ich endlich mal live nachschauen können Daheim am Rechner muss ich immer auf die 16 Display-Zeichen abzählen. Da geht schnell was unter.
• Der Z-Offset-Scan muss natürlich ausgeführt werden können(!), wenn der Drucker denkt er ist am Drucken. Bisher hatte die Prüfung ob der Drucker gerade druckt nicht gut funktioniert. Ich habe in den letzten Versionen die Prüfung auf "Printing..." verbessert und das hat dann zu einem blöden Fehler geführt, dass in manchen Startcodes der Z-Offset-Scan nicht mehr funktioniert hatte.
  Fehler erkannt und gebannt

Es fehlt noch ein Patch zum Hinweis von rf1k_mhj11 bezüglich dem M109, wenn man die Temperatur ausschaltet. (Dann wird der Befehl unter manchen Umständen ignoriert was nicht sein sollte.) Das kommt morgen noch zum Patch dazu, bevor ich diese neue Version in die Community-Development überführen kann.

LG

[Nibbels]

Ok....

Ich bräuchte nun möglichst viel Rückmeldung, ob noch jemand besondere Bugs, die es mal gab in der aktuellen Mod findet.
Wir haben wirklich irre viel repariert, geändert und "besser angepasst".

V RF.01.39+.Mod (2018-03-05)
- fixing rf1k-mhj11's bug that M109 cannot shut down temperature in some situations.
- fixing rf1k-mhj11's bug that M190 cannot shut down temperature.
- removed some code for more than 2 extruders because of cleanup
(and it can be reimplemented https://github.com/Nibbels/Repetier-Fir ... 87cedb2dba )
and it was not fully supported everywhere.
and we have no chance to drive a RFx000 with 3+ Extruders and the known type of electronics
- small fix for waitForTargetTemperature
- small fix for wrong display information (UI_TEXT_HEATING_UP instead of UI_TEXT_COOLING_DOWN) when waiting for temperature while processing a heat bed scan.
- we now use MAX_ROOM_TEMPERATURE at synonymous positions (hbs scan wait for temperatures)
- Feature RETRACT_DURING_HEATUP now only makes a retract when the temperature destination is > 40°C away from starting temperature.
- increased standard acceleration to 1500 for x/y. Accerleration for Z stays at 100.
- set standard Jerk to XY=13 and Z=0.3

V RF.01.38.39.Mod (2018-03-05)
- maybe improved HBS scan tolerance for uneven ceramic beds.
- always show full screen messages when finishing the HBS scan (in case of ok and fail) which the user has to dismiss with the ok button.
- improved menu text lengths for RF1000 16-char-display
- fix that a HBS-Scan after another HBS-Scan still has g_nLastZScanZPosition as a scan limit. That makes the second HBS impossible with some chance.
- cleanup some messages and g_uStartOfIdle around the HBS-Scan, ZOffsetScan, WorkpartScan and AlignExtruders

V RF.01.38.38.Mod (2018-03-03)
- some commenting
- removed check that z-offset-scan to really allow the scan while the printer thinks it is printing.
- removed self introduced overflow on queuePositionCurrentSteps[E_AXIS]. queuePositionCurrentSteps is size 3.

V RF.01.38.37.Mod (2018-02-26)
- dont allow any fan speed change to empty move cache. if this is needed fan speed has to be set in queue (TODO), not empty it.
- some commenting because i checked some things
- fix for easygo25's tilt-bug at the end of an SD-Print. http://www.rf1000.de/viewtopic.php?f=7&t=2199
- removed home-only-z when commanding home-all by menu and unknown z-endstops. homing should always do what the user demands and G28 as gcode does not have this limit. It seemd totally unnecessary and counterintuitive.

V RF.01.38.36.Mod (2018-02-22)
- via menu the homing feedrate and maximum feedrate can now be adjusted better:
- Z increments 1, not 5.
- Maximum is MAX_FEEDRATE_X _Y _Z not 1000.
(For Z-Axis 12mm/s is fast! That is because we use 2560steps/mm. XY on the other hand only uses 152 Steps/mm. That is a factor of 16.84!
So 200mm/s at X/Y-Axis fits 12mm/s in Z-Axis when it comes to interrupt amounts and calculation time.)

V RF.01.38.35.Mod (2018-02-21)
- https://github.com/foosel/OctoPrint/iss ... -357554341 changed upstream command "disconnect" to "stop" when canceling a print. The new octoprint will support this.
- added octostep as an 8x double/quad-stepping. I saw that moving Z fast still caused lags.
- decreased MAX_FEEDRATE_X _Y _Z in RF1000.h and RF2000.h to avoid way to fast speeds.

V RF.01.38.34.Mod (2018-02-10)
- RAMP_ACCELERATION is the set standard and cannot be switched off. Nobody would want that, thatwhy I removed the setting and some tiny pieces of alternative code.
- saved 4 bytes of Ram per Printline.

V RF.01.38.33.Mod (2018-02-08)
- AlignExtruders: Remove Z-Home over bed / unnecessary error handling.
- replaced RF.cpp's tab chars with spaces
- cleaned up copied code

V RF.01.38.32.Mod (2018-02-08)
- HBS: additional maximum delta for moving back very slow
- HBS: If testIdlePressure() fails while scanning then g_scanRetries are used up (homing, driving Y, retry ...) instead of canceling the scan.

V RF.01.38.31.Mod (2018-02-08)
- big Heat Bed Scan Update. If an error occurs the HBS is not allowed to home Z over heated bed anymore. (Wanted this for a long time now.)
The HBS Scan now has to move the bed down, home Y, home Z, Move the bed down again and then move back to the right Y position.
We should avoid crashing the heated bed several (3x?) times if the HBS wants to retry homing on to high beds.
These faulty Z-homings have been happening whenever the measurement goes out of range. Typically this is wrong z screw or a bed which is not aligned within the PEEK holders correctly.
- removed all MAX_FEEDRATE settings within moves and replaced them with "homingFeedrate" which might be some more moderate.
- made all MAX_FEEDRATE feedrates adjustable due to the fact that "homingFeedrate" is adjustable. Removed the Constants. (HBS, ...)

V RF.01.38.30.Mod (2018-02-07)
- cleaned up "StopPrint" to make one single function responsible for SD and USB prints which stop or get aborted.
- faster "StopPrint" if you abort via menu Quicksettings -> Stop Print (I now reset the line buffer and block new codes after you told the printer to stop)
- removed isPositionAllowed instead of patching it to repetiers state. Because we have constrain-functions for queue and direct. Therefore this function was not necessary anymore and never had any effect at all.
- always reset E-Axis before executing output object retract.
- Extruder::setTemperatureForAllExtruders() now replaced a dozen of places where all extruders have been deactivated by multiple Extruder::setTemperatureForExtruder().
- Fix: if you switch to milling mode all extruders are set to 0°C, not only the first.
- Fix: Printer::kill() does not iterate too high anymore when turning off heaters.

V RF.01.38.29.Mod (2018-02-07)
- insert decrease of flow (with high digits) to M3912 auto start line. Ninjaflex likes that alot. PETG might like that too. (prevent overpressure because of startline)

V RF.01.38.27.Mod (2018-02-06)
- hypothetical patch for being able to crash the z-min-endstop when you are homed + lower than Z=0 and driving moveZ into minus-Z. This prevention is only suitable for "z-homed" use and only for printing mode. Maybe it helps some day.
- removed senseless dir change delay XYZ_DIRECTION_CHANGE_DELAY which was only used in one point and did not make much sense there.
- New M3912 auto start line got a new switch: Y23 which would make the start line starting at y = 23mm. (Some beds dont start at Y=23 but Y=20 or else.)

V RF.01.38.26.Mod (2018-02-05)
- FEATURE_Z_MIN_OVERRIDE_VIA_GCODE cannot be switched off anymore. This feature is mandatory for safe printing.
- added z-check for driving down Z against bottom. "Printer::currentZSteps > Printer::maxSteps[Z_AXIS] + 2x length of Z_OVERRIDE_MAX" is now a softlimit for moves which check endstop.

V RF.01.38.25.Mod (2018-02-05)
- only adjust print speed according to Digit-Flow-CMP setting if the move is for Gcode queue
- clean up acceleration/deceleration code
- clean up new menu with ecmp
- ecmp value now got factor *100 (in display) to show up as fill-up % while compensating z. Formerly the number was a plain add_steps_per_step and looked like 0.0234, now it is displayed as 2.34%
- show printing speed beneath layer height in ecmp-menu
- g_maxZCompensationSteps got one more space in display
- limit start line speed decrease to minimum 10% (-90%) instead of 5%
- removed ALLOW_QUADSTEPPING from RFx000.h because it is just there to be used.
- cleanup Printer::unmarkAllSteppersDisabled(); into "stepper.enable"
- removed one allow-interrupt because it was double.

V RF.01.38.24.Mod (2018-02-01)
- GCODE-Pause: automatically wait for queue position of "pause" and block further Gcodes until continue was pressed.
- Tweaking setOrigin (Origin of gcode coordinates / G92 XYZ) so that it can origin axes that are homed without the need of having everything homed.
- removed M3071 because it doesnt seem to be needed anymore. (-> integrated into M3070)

V RF.01.38.23.Mod (2018-01-31)
- Strange behaviour of ZOS Scan: Debugging and one idea for a fix: Limit going up to retry if digits drive away on cold printers with filament warming up.
(2018-02-05: at least until now we did not see the bug anymore, means that we still dont know if we fixed the bug with 01.38.23 but it looks good.)

V RF.01.38.22.Mod (2018-01-29)
- Extruder pause delay changed from 30 to 60 s
- some cleanup
- some security measures for M3912 and tweaks for M3001 Gcode (removed M400)

V RF.01.38.21.Mod (2018-01-28)
- New M3912 to automatically draw a start line to clean nozzle within start code.
Example: M3912 I2 E20 F18
I2 -> 2 Lines
E20 -> Extrusion width value
F18 -> 18mm/s
The nice feature is that high digits slow down the speed automatically. This startline adopts to your type of filaments/nozzle.
- DMS-Features: Digit-Flow-CMP -> dFeed now has an instant effect on your printers speed. The problem that the speed was set with the path cache is now gone.
- Enabling SenseOffset now happens in move cache queue (, not instantly as it was). Thatwhy we can drop some M400 in our startcodes.

V RF.01.38.20.Mod (2018-01-27) (Alpha!)
- Test: Better Z-Naht? (due to changed slow speed constraint at E<->YXZAxis transitions and E-direction transitions)
- Test: do we need "direct.start"? -> removed it. Added it again for safer upload. -> Pause is way faster with "started". So it stays for now.
- Test: changed #define EXT1_MAX_START_FEEDRATE 18 to #define EXT1_MAX_START_FEEDRATE 12 (Repetier uses 10 or 12 as standard within his configuration.h. If you wanna test this values against 18 then change it in your eeprom as well!)
- Added Printer::updateAdvanceFlags(); to Advance menu function
- removed old advanceL and advanceK menu hooks
- some more tiny cleanup and sync of syntax to repetier 1.0.1

V RF.01.38.18.Mod (2018-01-20)
- some checks and comments
- FEATURE_CHECK_HOME and FEATURE_SEE_DISPLAY are now in configuration.h instead of RF1000.h / RF2000.h
- FEATURE_SEE_DISPLAY is not beta anymore, it seems to work so far. (More tests will follow.)

V RF.01.38.17.Mod (2018-01-20)
- fixed typo in text
- changed homing functions to use one central home-directions-function
- removed logic to set global homing flag which was not used anymore -> simplifying code
- removed var "formaterrors" from gcode parsing because it was not used anywhere.

V RF.01.38.16.Mod (2018-01-15)
- fixed some extruder inits
- removed all heat managers except PID because they work for all RFx000.

V RF.01.38.15.Mod (2018-01-15)
- New Startscreen

V RF.01.38.14.Mod (2018-01-15)
- Testing FEATURE_SEE_DISPLAY which can steer the printers button via GCODE and show whats display in the menu.
- improved display cache for output as serial string.

V RF.01.38.13.Mod (2018-01-15)
- Fix Fix Tyreus Lyben was never used but No Overshoot was.

V RF.01.38.12.Mod (2018-01-13)
- read repetier 1.0.1 and synced some code (mostly gcode parsing)
- send better readable log message if Heat Bed Scan fails because of endstop limit Z_ENDSTOP_DRIVE_OVER
- removed while in highest commands loop
- tiny fix for 01.38.11 @ two extruders

V RF.01.38.11.Mod (2018-01-07)
- Testcleanup on stepperdirections
- Cleanup (maybe to discuss) on Do-Step-Functions like startZStep / ...
- standardization of functions to prepare z-direction (prepareBedUp / prepareBedDown vs. setZdirection)
- pinned moveZ to real z direction / pinned performMove to real z direction / pinned directSteps to real z direction -> A test!
- Tweak for zCMP to dismiss steps in Z when zCMP would do otherwise. We just ignore steps in special cases when queue and zCMP are contra-rotating. I have to think about if this is great or to harsh in some situations.
- some standardization on port Writes
- removed minMM[Z_AXIS] because it might be malicious.
- disabled M42 because it might be dangerous somehow and is not really usefull except you really need it and you are not able to edit the firmware
- removed blockall where it was bogus.
- compensatedPositionPushE moved to a private static inside queuemove function

V RF.01.38.10.Mod (2018-01-06)
- FEATURE_CHECK_HOME, first beta.

V RF.01.38.09.Mod (2018-01-04)
- clean up disable / enable steppers
- disable feature define "disableAllowedStepper()"
- force zCMP to respect Z_ENDSTOP_DRIVE_OVER / Z_OVERRIDE_MAX as a limit so no further movement into the z-endstop is made by zCMP
- increased Z Current to 105 to avoid lost step problems on some printers with mod firmware whose spindles need heavy torque.
- force zCMP to add an extra offset and move the bed down if the loaded zMatrix is positive while homed(Z). This might avoid crashes when we are homed, not using zCMP, and move X-Y.

V RF.01.38.08.Mod (2018-01-03)
- addFloat overlow bugfix for 4+ digits.

V RF.01.38.07.Mod (2018-01-03)
- Better Init
- ZOS now uses matrix interpolation instead of matrix node
- homing safely shuts off zcmp and waits for it
- disable z stepper z shuts off zcmp before shutting off stepper and cleaning up coordinates - seems to be safer??
- removed disable CMP where it is not needed anymore because of zhome-cmp-off
- for now if( PrintLine::linesCount > 2 ) is marking "printing" instead of 5. Had some trouble at startmade.
- Commands::waitUntilEndOfAllMoves() waits for zcomp to reach target too.

V RF.01.38.05.Mod (2018-01-02)
- div 0 fix for ECMP
- strategy change for activating and disabling zCMP

V RF.01.38.05.Mod (2018-01-02)
- changed fan speed to display float
- added auto adjust function for g_minZCompensationSteps to set it to first layer height
- added auto adjust function for g_maxZCompensationSteps to set it to g_minZCompensationSteps + max 5% comp pro layer.
- added minimum matrix value to Matrix output M3013
- changed some functions to return "void", because they did not return anything of value.

V RF.01.38.03.Mod (2018-01-01)
- added E-Compensation improvement for fist and last stretching-layer within ZCMP.
- removed one Milling-Bug by unifying the search for interpolated matrix depths. (directPosition was added twice in getworkpartoffset??)
- added a new menu to level 0 status menus.
- added layer height detection to the firmware - it is shown in the new menu.

V RF.01.38.02.Mod (2017-12-30)
- added E-Compensation for Z-Compensation layer expansion.

V RF.01.38.01.Mod (2017-12-29)
- added renkforce feature FEATURE_ALIGN_EXTRUDERS
- fixed details in FEATURE_ALIGN_EXTRUDERS
- added menu support: Configuration -> Z-Compensation -> Align Extruders
- added autoresolving errors by homing -> align extruders will then move to old hbs align position if you dont set manual x and y (which is possible if you dont move z out of 0!)
- added display countdown from renkforce 1.39 to "PLA Scan" and "ABS Scan" heating process.
Milling:
- M3071 now shows "Start Miller"
- M3070 now shows "Paused" and switches to menu mode paused and sends "RequestPause:" ...
- M3130 now has a wait-for-continue added.
- cleaned up possible tempering with Printer::feedrate if you plan paths by other functions than gcode.
- added DEFAULT_PAUSE_STEPS_X_MILL to 0, DEFAULT_PAUSE_STEPS_Y_MILL and DEFAULT_PAUSE_STEPS_Z_MILL
- DEFAULT_PAUSE_STEPS_Z_MILL increased to 20mm because you might crash into clamps with 2mm. I preset 2mm for printing once. Because I didnt know endstopbehaviour for pausing @RF1000. Still dont know but it seems safer now (not to crash holding clamps)

V RF.01.38.Mod (2017-12-28)
- improved ZOS handling
- testimprovement for HBS (take back push in force by driving back in very tiny steps)
- Temps for Scan PLA are now 210 / 60 instead of 230 / 60
- Temps for Scan ABS are now 240 / 100 instead of 260 / 130 (Bed 100 is a better limit for DDPs, 240 is enough for most ABS)
- Temps for preheating ABS are now 210 / 100 instead of 240 / 110 to prevent filament degradation in heatzone.
- version bump to meet renkforce stable (no change between 1.37 and 1.38 except calling it stable)
- testing and minor tweaks (UI_PRINT_AUTORETURN_TO_MENU_AFTER 120000 instead of 60000 / ..)
- removed Temptable 14 and put Temptable 15 to that place. 15 looked better in excel than 14 but is quite similar.

V RF.01.37z2.Mod (2017-12-27)
- Tweaks for ZOS precision
- tempered and cleared up things with z compensation - G1 Z0 is now surface + 5um, only minus z is forbidden. testers have been distracted too often by this stupid "Z0 = no real CMD" rule.

V RF.01.37z.Mod (2017-12-26)
- small corrections

V RF.01.37z.Mod (2017-12-23)
To move towards Renkforces 1.39 I already pulled the following changes from 1.39:
- Added V3 Hotend (possible wrong pid values!)
- Added definitions for RF2000v2 and PIN mapping (final??)
- Replaced PT100 with V3 Hotends 3950 100k type, because Renkforce chose that number. PT100 is not really usable with RFx000 (not without soldering), removing that table might be ok.
- some more ifdef Feature_Pause_Printing marks.
- moved menu sensor type from 14 to 13 to have V3 support by menu
- some minor code cleanup
- added RF1000s M3076 and description
- added checks for deleting zmatrix while CMP
- added RF1000s PRINTER_FLAG2_RESET_FILAMENT_USAGE-fix
- RF1000s fix for loadCompensationMatrix without milling mode
TODO: Pull Feature Allign Extruders
We will not pull changes for "FEATURE_CONFIGURABLE_HOTEND_TYPE" because we have another way to do this: menu configuration. This feature has been abandoned with RF.01.37r5.Mod.
Other changes are not needed because we already fixed this stuff in earlier releases.
TODO: We should grab the sensor tables for 13, 14, 15 and compare them. If they are somehow similar remove the clones. (One is from Renkforce, two from the Internet. hliebscher previously used type 14 for Ultimaker Hotends, but not anymore)

V RF.01.37y.Mod (2017-12-18)
- changes in matrix heat bed scan
- changes in Z-Offset-Scan
- changes according active and ongoing discussion with PeterKA about precision

V RF.01.37x9.Mod (2017-12-05)
- Scan Z-Offset-Scan on slightly random Point around Matrix-Point: See SEARCH_HEAT_BED_OFFSET_SCAN_POSITION_RAND_MM
- Some ROM-Text savings for this feature

V RF.01.37x8.Mod (2017-11-28)
- Bugfix: RF1000 with one Extruder should as well heat up in distance Z=10mm before reaching final Temperature for Matrix Scan ABS/PLA Scan because someone might use a DDP. Thx. and Sorry @dabr0013

Ich will eigentlich diese Version zur neuen Master-Mod machen. Aber davor bräuchte ich ein paar Rückmeldungen, die detailiert nachschauen, wo es noch klemmt, oder ob noch irgendwas unschön gelöst ist.

LG

[easygo25]

RF1000.h:

RF1000.h: Z895 #define LOW_TICKS_PER_MOVE 4000000 von 2500000 auf 4000000
RF1000.h: Z890 #define MOVE_CACHE_LOW 14 von 10 auf 14
RF1000.h: Z884 #define MOVE_CACHE_SIZE 20 von 16 auf 20
LG AtlonXP

Bei mir ist der Wert von LOW_TICKS_PER_MOVE in der Version RF.01.38.37.Mod
auf 300.000 und nicht 2.500.000! Ist das richtig ? Kann ich den Wert einfach auf
4.000.000 erhöhen, wie du es beschrieben hast ?

Hab einen RF1000!

[AtlonXP]

RF1000.h:

RF1000.h: Z895 #define LOW_TICKS_PER_MOVE 4000000 von 2500000 auf 4000000
RF1000.h: Z890 #define MOVE_CACHE_LOW 14 von 10 auf 14
RF1000.h: Z884 #define MOVE_CACHE_SIZE 20 von 16 auf 20
LG AtlonXP

Bei mir ist der Wert von LOW_TICKS_PER_MOVE in der Version RF.01.38.37.Mod
auf 300.000 und nicht 2.500.000! Ist das richtig ? Kann ich den Wert einfach auf
4.000.000 erhöhen, wie du es beschrieben hast ?

Hab einen RF1000!

Schau was ich später geschrieben habe.
Man sollte wirklich einen Punkt zwischen den vielen Nulle setzen.

Ja wohl, ich bestätige eine Null zu viel!
Na bei so vielen Nullen….

Ich bin froh das dass Ding jetzt so läuft.

Meines Wissens hat Nibbels diesen Wert, wieder etwas nach oben korrigiert.

LG AtlonXP

[Nibbels]

Ich habe damals meine bisherigen Werte angeschaut, dann AtlonXPs Werte und dann bin ich etwas mitgegangen.

LOW_TICKS_PER_MOVE kann man setzen, wie man will, glaube ich. (?Nur nicht zu klein?.) Zu groß könnte den Drucker bremsen(?).
(Sollte man diesen Wert im Menü einstellbar machen? Ganz ehrlich, wenn nur einer von euch mit irgendwelchen krassen Teilegeometrien an diesem Schalter live während des Drucks spielen und ein Optimum für alle finden will, baue ich das ins Menü ein. Sonst macht das nie einer und wir bleiben unwissend ^^. Alternativ kann ich auch einen GCODE erfinden, mit dem man das umschalten kann.)

---

Bei

#define MOVE_CACHE_LOW 14 von 10 auf 14
#define MOVE_CACHE_SIZE 20 von 16 auf 20

bin ich auf

/** \brief Number of moves we can cache in advance.
This number of moves can be cached in advance. If you wan't to cache more, increase this. Especially on
many very short moves the cache may go empty. The minimum value is 5. */
#define MOVE_CACHE_SIZE 18

/** \brief Low filled cache size.
If the cache contains less then MOVE_CACHE_LOW segments, the time per segment is limited to LOW_TICKS_PER_MOVE clock cycles.
If a move would be shorter, the feedrate will be reduced. This should prevent buffer underflows. Set this to 0 if you
don't care about empty buffers during print. */
#define MOVE_CACHE_LOW 14

hochgegangen, was noch unter AtlonXPs werten liegt. Ich hab gesehen dass es möglich sein müsste, wollte aber nicht zu weit vorpreschen.
(Diese zwei Werte könnte ich im Menü nicht einstellbar machen.)

Dazu muss ich anmerken, dass seither 2 wichtige Bugs raus sind, die tatsächlich zu komischen Effekten hätten führen können. Das gibt mir etwas mehr Sicherheit.
Und ihr könnt (ohne Gewähr) mit der MOVE_CACHE_SIZE solange hochgehen, bis der Arduino-Compiler für euren Drucker sagt, er hat nur noch grob 1kbyte freien Ram. Das ist leider je nach Drucker/Hotends etwas unterschiedlich.

Screenshot_2.jpg

(Laut Screenshot könnte ich mit RF2000/Dual auf 19 erhöhen.)

LG

[AtlonXP]

Die FW RF.01.39+.Mod scheint nun fertig zu sein.
Heute werde ich sie mir ziehen und am WE aufspielen.
Ich hoffe mir vereist es nicht gleich die Kiste.

Danke Nibbels.

LG AtlonXP

[Nibbels]

Zu den Versionen 1.39.01+ (und 1.41.03+)

Es haben sich inzwischen im Hintergrund ein paar Themen entwickelt.

• Wenn man Load Filament oder Unload Filament ausführt. (Danke @easygo25) Damit meine ich im Menü->Extruder->Load Filament/Unload FIlament, dann steht am Anfang dieser internen GCode-Scripte ein G92 E0 zum Abnullen der Extruder aber nicht am Ende. Also konnte es sein, dass wenn man anschließend ohne ein manuelles G92 E0 einen Absolutkoordinaten-Extrudierbefehl versendet hatte dieses Load/Unload rückgängig machen konnte. (Krrrrrrrrx..) Ich habe das in der 1.39.01 geändert.
  Weiter drüber nachgedacht waren mir diese Befehle schlicht zu doof. Ich habe in meiner alpha-development 1.41.xx auf https://github.com/Nibbels/Repetier-Firmware/ 2 neue GCodes eingeführt: M3913 https://github.com/Nibbels/Repetier-Fir ... cpp#L10765 und M3914 https://github.com/Nibbels/Repetier-Fir ... cpp#L10796.
  Diese Befehle ent-/laden das Filament unter Beachtung der produzierten Digits. Sie sind evtl. noch nicht perfekt eingestellt, aber funktionieren in meinem RF2000. Beim Load-Filament wird auf 210°C aufgeheizt und anschließend das Filament eingezogen bis die Digits eine Grenze erreichen. Dann ist das Laden beendet! Es wird nicht mehr wie bisher eine definierte Strecke eingezogen. Unter Umständen kann dieser GCode einmal die Startmade ersetzen oder sehr stark verkürzen, denn danach müsste das Hotend schon gefüllt sein. Die Startmade müsste nur noch letzte Luftblasen austoßen.
  Im Fall von manchen Filamenten müsste man aber dennoch das alte Filament komplett ausstoßen, da bringt dass unter Umständen nichts (z.B. mein Billig-ABS das mit der Zeit im Hotend zu Kaugummi wurde und Krusten bildet).
  
  Unload Filament ist so eine Sache. Ich baue einfach ~-5000 Digits Spannung auf und erhöhe langsam die Temperatur. Lässt die Spannung nach wird wieder aufgebaut. Irgendwann sollte sich das Filament gelöst haben und es wird komplett rausgezogen.
  Funktioniert! Aber in meinem Fall nicht immer, weil manchmal einfach das Filament nicht durch meinen Extruder aus meinem speziellen Hotend gezogen werden kann. Das müssten mir irgendwann mal Nutzer mit V2 oder anderen Hotends zurückmelden. Diese -5000 Digits sollten in jedem Fall so gewählt werden, dass der Extruder keine Steps verliert. Ansonsten eben so hoch wie möglich. -> Optimierungsproblem je nach Extruder.
• AtlonXP hat mir zurückgemeldet dass OutputObject nun zu schnell sei. Oder schneller als bisher. Das habe ich nicht geändert, aber durch die Möglichkeit von Octa-Stepping (Vgl. Double-Quad-Stepping) kann Z nun mit etwas weniger Rechenleistung bewegt werden. Also hat sich ein gegebenes Limit erweitert. -> Ich habe https://github.com/RF1000community/Repe ... da6a939856 die kommandierten Geschwindigkeiten in OUTPUT_OBJECT_SCRIPT_PRINT / -MILL auf Werte gesenkt die tastsächlich sinn machen. Z mit F5000 = 83mm/s verfahren zu wollen ist nicht machbar
• Ich habe herausgefunden, warum mein optionaler Temperatursensor für den Bauraum nichts mehr angezeigt hatte. Das war durch die Änderung in den Temperatur-Sensor-Tabellen von 15 auf 14 bedingt. Nun habe ich wieder meinen Bauraum-Sensor.
• Ebenfalls in meiner alpha-development 1.41.xx auf https://github.com/Nibbels/Repetier-Firmware/ habe ich die Konfiguration so umgeschrieben, dass alle Werte die dort in Steps notiert sind rausgefallen sind und nun per Millimeter konfiguriert wird.
  Dann habe ich die Konfiguration unserer Stepper-Treiber für die XY, Z und E0/E1 getrennt. Man kann nun im Menü unter Configuration->Stepper->MicrostepsXY / MicrostepsZ / MicrostepsE die Microsteps für die einzelnen Achsen getrennt von einander umschalten. Man kann nun wie mit einer Gangschaltung die Verhältnisse der Steps/mm anpassen.
  Ich habe gute Erfahrungen gemacht wenn ich in XY mit 64 Microsteps drucke und Z bei 32 oder sogar runter auf 16 betreibe.
  RF1000 hatte schon früher mal die Z-Kompensation so eingerichtet, dass theoretisch ein Betrieb bei anderen Microsteps möglich war. Aber geänderte Microsteps != 32 war bisher leider nicht überall in der Firmware so vorgesehen. Jetzt ist das möglich und ich kann während dem Betrieb umschalten, aber nicht während dem Druck. Ich deaktiviere zur Sicherheit die Stepper und verliere auch das Homing, wenn ich die Microsteps im Menü ändere.
  Alle wichigen Variablen, die ich kenne werden automatisch eingestellt und im EEPROM geändert, wenn man die Microsteps ändert: z-kompensationsgrenzen, steps/mm, z-offset, hotendabstand, hotend-offset, currentZSteps.
  Aber nicht: diverse Miling-Origins, Achsenwerte, aktuelle Koordinaten -> Ich werfe die durch das Homing weg, man anschließend muss neu homen. Z-Origins bleiben aber so wie sie sind. Man muss, wenn man Z-Origins nutzt bis ich mir absolut sicher bin wo ich umschalten muss und das patchen kann den Drucker neu starten oder diese Origins manuell nachstellen.
  Der Drucker klingt mit geänderten Microsteps anders. Bei 256 Microsteps klang das fürchterlich, ich habe den Extruder auf maximal 128MS limitiert,
  XY auf maximal 64MS und Z auf maximal 32MS.

Aktuell in der Diskussion stehen:

• mhier hat ein Problem mit dem Homing in Verbindung mit einem anschließenden G92 für X, Y, Z gemeldet.
• wir diskutieren wieder (oder immernoch) über den Z-Offset-Scan und sein ideales Verhalten.
• Vermutlich in Verbindung mit Punkt 1 hat das SenseOffset ein Problem.
• Ein zur Laufzeit änderbares https://github.com/Nibbels/Repetier-Fir ... 000.h#L863

  Code: Alles auswählen

  #define LOW_TICKS_PER_MOVE                  300000

• Eine kleine Statistikfunktion für den Füllstand des MOVE_CACHE. https://github.com/Nibbels/Repetier-Fir ... 000.h#L852 -> Damit sollte es möglich sein, die Cache-Schwankungen während dem Druck zu erfassen und LOW_TICKS_PER_MOVE zu optimieren, sodass wir irgendwann den Wert kennen, der in der Configuration jeder Firmware als LOW_TICKS_PER_MOVE stehen sollte.

LG

[Nibbels]

Bezüglich der Diskussion um den Movecache und die LOW_TICKS_PER_MOVE:

Screenshot_4.jpg

Screenshot_3.jpg

Das Teil habe ich 5x gedruckt. Immer mit anderen LOW_TICKS_PER_MOVE.
Ich habe die Anzahl der unterschiedlichen Füllstände zu dem Zeitpunkt wenn ich eine neue Bewegung in die Warteschleife legen will mitgeloggt.

Screenshot_5.jpg

Ich sehe, dass ich fast nichts ausrichte. Zumindest nicht bei diesem Slice und über meinen Raspberry.
Der Wert 200000 ist schon etwas schlechter!
Die Anzahl der Vorkommen eines quasi leeren Cache ist damit höher. Aber wenn ich mal bei 300000 oder 400000 angekommen bin sehe ich bei diesem langsam gedruckten PLA-Test-Slice keine gravierenden Probleme.

Der MCode zu diesem Test heißt M3993. Damit liest man die kleine Tabelle aus und löscht sie intern. Mit M3993 P500000 stelle ich den LowTicksWert auf 500000 usw.
Wenn jemand tatsächlich noch Probleme mit unerklärlichem Stocken hat und nicht weiter weiß. Viel Spass damit

VORSICHT: Man senkt mit diesem Feature den freien RAM um ca. 84 byte. Das könnte schon fast eine Move-Cache-Printline ausmachen! Bleibt der Drucker z.B. bei OutputObject oder Load Filament stehen, wars zuviel des Guten

LG