Seite 1 von 15

Community Mod RFx000 Firmware :: Neue Stable (Stand 1.42.03 / 28.07.2018)

Verfasst: Sa 28. Jul 2018, 17:38
von Nibbels
Servus :)

Ich habe in der letzten Zeit fast nur noch Details angepasst oder Code aufgeräumt. Darum habe ich wieder alle Github-Repositorys und Branches gleichgezogen. Alle neuen Features/Änderungen der original Conrad RF.1.42 sind im Mod integriert.
Screenshot_2.jpg
Erwähnenswert ist evtl. noch Die aktuelle Version, die Stand jetzt Github liegt heißt 1.42.03.Mod

Quellcode und Hex-Files
Stable Branch: https://github.com/RF1000community/Repetier-Firmware
Development Branch: https://github.com/RF1000community/Repe ... evelopment
Jenkins-Server von mhier: https://jenkins.beta-centauri.de/
Arduino: https://www.arduino.cc/en/Main/Software
Firmware Update: https://www.youtube.com/watch?v=XxwUC6o-Dbw&t=4s

Dokumentation
Wiki: http://www.rf1000.de/wiki/index.php/Kat ... d_Firmware
Mod-Gcodes: http://www.rf1000.de/wiki/index.php/Gcodes
Youtube: https://www.youtube.com/user/TheNibbels/videos

Perma-Link zur Changelog bis 1.42.03
https://github.com/Nibbels/Repetier-Fir ... log.txt#L4

Code: Alles auswählen

V RF.01.42.03.Mod (2018-07-10)
- some cleanup and merging of mandatory features

V RF.01.42.02.Mod (2018-07-10)
- corrected the RF2000v2 SensorType to 13 (It had been released as Type 3 in RF.V01.42)
- skip AlignExtruders at the end of a Heat-Bed-Scan if no user interaction is recognized within one hour.
- abort AlignExtruders (solo function) if no user interaction is recognized wihin one hour (and shut down temperatures in that case).

V RF.01.42.01.Mod (2018-06-27)
- added int-casting to function changeFlowrateMultiply output to avoid weird behaviour of repetier-host. Thx @guido!

V RF.01.42.00.Mod (2018-06-25)
- full rework on configurable pwm fan frequencies to 15.3hz or lower.
  we now have the full fan resolution on all configurable frequencies.
  0% => OFF, 1%..99% => Scaled PWM, 100% => 24V always on.
- the code/variables for fans are now divided into "coolers" for hotend etc. and "part fan"
- some work on configuration options
- some code got cleaned up
- the eeprom value for fan-frequency moved to a fresh location for reinitialisation with the new system.

V RF.01.42.Mod (2018-06-24)
- scaled down fan-pwm-frequencys by factor 4 -> 3.8Hz .. 62Hz.
  (secondary fans and heater pwm stay like they were)
- implemented min-pwm and max-pwm setting for part fan
- implemented eeprom and menu support for part fan min-pwm/max-pwm settings
- possible secondary fan speeds (hotend cooler, other pins) will now only listen to hardcoded configuration: COOLER_PWM_STEP COOLER_PWM_MASK and secondary fan speeds are not scaled.
- removed old MAX_FAN_PWM setting because it is now depreached
- removed too high heater_pwm_speeds for safety reasons because we dont need them and the pwm resolution of the original code is bad on those high frequencys.
- shifted fanKickstart time to a resolution of 10ms (instead of 100ms). (But the config values and default behaviour did not change.)

- set default fan config to:
    RF1000: 15Hz 1..254 (should be the config we already knew for the RF1000)
    RF2000: 15Hz 1..254 (the formerly better config for my printer, instead of former 62Hz)
    RF2000v2: 3.8Hz 90..193 (Conrad: 3.0Hz 90..193 which might be better but I cannot test it!)
   -> These values will change after the first tests are done.

V RF.01.41.51.Mod (2018-06-23)
- Merged changes from RF1.42 except this new fanspeed 3Hz feature
- experimental support for RF2000v2

V RF.01.41.28.Mod (2018-06-16)
- We dont draw a T1 startline over a T0 startline anymore. M3912 T1 startlines are now shifted in y a bit.

V RF.01.41.27.Mod (2018-06-15)
- additional automatic checks for zeroes within extruder eeprom
- autocheck that eeprom value extruder start speed is not bigger than extruder max speed
- prevent the menu to switch some settings to 0
- added "if FEATURE_AUTOMATIC_EEPROM_UPDATE" on some more locations

V RF.01.41.26.Mod (2018-06-07)
- not yet available temp measurements have been blocking the printer to show which sensor is defect after a restart.
- some refactoring and cleanup of code

V RF.01.41.25.Mod (2018-05-23)
- FEATURE_Kurt67_WOBBLE_FIX: switched direction of phase from - to +. That means that a +Phase will move some synthetic wobble downwards in +Z
- FEATURE_Kurt67_WOBBLE_FIX: x direction now has a cosinus and y direction has a sinus.
- Extruder->"Load Filament" and "Unload Filament" now have two presents and a submenu (thx. @Zaldo)
- unload filament can now rise up to 240°C to try to pull ABS loosened (thx. @Zaldo)
- load filament now has a second present that ignores digits. you can abort this via key press (thx. @Zaldo)

V RF.01.41.24.Mod (2018-05-20)
- fixes for two things that jenkins complained

V RF.01.41.23.Mod (2018-05-19)
- First version of kurt67 wobblefix. This feature allows you to simulate wobble and therefore experts in measurement might be able to compensate z-wobble on RFx000 printers.
  Z-wobble is here defined as a shaking in the x-y-plane. this shaking is caused by the faulty rotation of the z-spindles.
- disabling steppers now reactivates the movement-lock (if FEATURE_UNLOCK_MOVEMENT == 1). See http://www.rf1000.de/viewtopic.php?f=70&t=2282#p23501 .

V RF.01.41.22.Mod (2018-05-12)
- SenseOffset EEPROM-Values can now be adjusted in Menu -> Configuration -> DMS-Features.
- SenseOffset now has an "Auto-Start" within Menu->Configuration->DMS-Features->SenseOffset. This means that if you home and activate M3001 Z-Compensation then SenseOffset will automatically start. It then uses the last chosen values within EEPROM. (As Example: 3300 digits and 150um max. drivedown). Using that "Auto-Start" in your startcode M3909 is not necessary anymore.

V RF.01.41.21.Mod (2018-05-10)
- We now use the sdfat library with SD_FAT_VERSION "1.0.5" instead of the old "20130629". This new library has long filename support. https://github.com/greiman/SdFat/tree/master/src
- The navigation down at the most bottom of a folder now leads to the top of the folder and otherwise around.
- This special bug with the automount loop on failed mount attempts is now gone.
- We now have plausible error messages when SD-Cards do not work.
- Now all my SD-Cards work if they are formatted with FAT16 or FAT32. If you need FAT12_SUPPORT activate it in SdFatConfig.h (and pay some rom and ram). (Because Fat12/16/32 is examined by cluster count small cards <=16MB are identified as FAT12 -> They are not working.)
# Deleting SD-files within menu is disabled for now. There was too much code confusion to make it right (using long filename support). [-> Who does really need this?]
- Rightnow the RF2000 hides the static menu folder called "SD CARD" because we already have the automounted "Print File". And "Delete File" is not visible anymore.

V RF.01.41.20.Mod (2018-04-14)
- fix that the printer forgot to load eeprom saved stepper currents since ~1.41.13

V RF.01.41.19.Mod (2018-04-10)
- fix tilt when stopping USB sourced print in paused state. (thx @ easygo25)
- fix Temperatures do not show when starting print within 500ms after boottime.

V RF.01.41.18.Mod (2018-04-08)
- removed INCLUDE_DEBUG_COMMUNICATION
- FEATURE_ABORT_PRINT_AFTER_TEMPERATURE_ERROR is mandatory and removed from configuration.h
- removed INCLUDE_DEBUG_NO_MOVE
- removed DEBUG_FORCE_COM_ERROR
- removed DEBUG_SPLIT
- removed DEBUG_PRINT
- removed ANALYZER defines
- removed DEBUG_REMEMBER_SCAN_PRESSURE
- removed DEBUG_HEAT_BED_TEMP_COMPENSATION

V RF.01.41.17.Mod (2018-04-02)
- if any sensor fails/disconnects show the specific sensor which failed within the display message.

V RF.01.41.16.Mod (2018-04-01)
- Hid the menu for "Right hotend tipdown support". This menu only makes sense for very special hotends and shouldnt distract the user on 99% of all printers.

V RF.01.41.15.Mod (2018-03-29)
- added Menusupport and EEPROM Support for HEAT_BED_SCAN_Z_START_MM which sets the z-lift for moving onto the bed at every start of zscans like Z-Offset-Scan or Heat-Bed-Scan. This value needs to be high, if someone wants to work with positive matrix (/ to low zscrew). That is not recommended but helps if you have interchangeable heated beds with different heights.

V RF.01.41.14.Mod (2018-03-29)
- removed "PID autotune some overshoot" from menu
- gave the PID autotune submenus a description for what autotune methods are good
- reordered PID autotune methods to start with pessen, then classic then noovershoot and finally tyreus lyben.
- added "heated bed off" to Extruder Menu. (At least I use this alot for testing)

V RF.01.41.13.Mod beta (2018-03-28)
- We can now skip the rest of the M3912 startline by pressing play while printing the start line. (Might save some tiny amounts of plastic from time to time.)
- the eeproms max feedrates are dropped and overwritten if they are bigger than configuration max values.
- the eeproms homing feedrates are dropped and overwritten if they are higher than configuration max values.
- extruder steps/mm are corrected to default if they are set > 5540steps/mm
- if we press the 3 keys "Back", "OK" and "Play" while boot time the eeprom values are reset to defaults before being loaded.
- some reordering in boot time configuration to prevent to early use of things.
- compiling without SDSUPPORT is possible again. (~+1kb ram frei -> ~+8 MOVE_CACHE möglich)

V RF.01.41.12.Mod alpha (2018-03-26)
- cleaned up the thermistor functions
- depreached the use of int16_t targetTemperature and crushed void TemperatureController::setTargetTemperature(float target, float offset) to very few lines.
- added PT100 support on temperature sensor number 53 again. (This PT100 sensor board is sensortype no. 13 in original repetier but conrad dropped their V3 hotends sensor to this number.)
- inserted MAX_ROOM_TEMPERATURE as the default low constraint in some locations where a temperature has to wait for the target temperature.
- heater off now means targetTemperature=0 (not <15 or whatever in some locations).
- added sensortype 0 as 25°C dummy (like repetier did)

V RF.01.41.11.Mod alpha (2018-03-16)
- added a microsteps reset to the function that resets the configuration to defaults (Werksreset)
- fixed that EEPROM::initializeAllOperatingModes() did not update checksum. (Had been forgotten when using M502 and UI_ACTION_RESTORE_DEFAULTS )
- fixed EEPROM::updatePrinterUsage() to 1.39 version when not using FEATURE_MILLING_MODE
- cleaned up all the double coded code for "#else //FEATURE_MILLING_MODE" to one version.

V RF.01.41.10.Mod alpha (2018-03-16)
- tweaks and fixes for the case that M190 / M109 is running(/waiting for temperature) and meanwhile the user changes temperatures using Menu->Extruder-> at the printers display.

V RF.01.41.09.Mod alpha (2018-03-15)
- making the Z-Offset-Scan faster.
- small fix for M3913 / M3914 abort.
- implemented digit homing for M3913 / M3914

V RF.01.41.08.Mod alpha (2018-03-15)
- abort M3913 / M3914 (when moving) by ok-Button and back-Button
- commented all g_uStartOfIdle to find bugs -> adjusted some idle-times for better usability
- some more tweaks around checks if zCMP is blocked
- removed matrix-version check within calculateZScrewCorrection. the reason for this was an overflow we already corrected months ago.
- checked all uid.lock / unlocks
- cleaned up uid. object references within the UIDisplay itself. (but it didn't change rom size)

V RF.01.41.07.Mod alpha (2018-03-14)
- Support for REPETIER_PROTOCOL:3
- MoveZ now releases Z correctly. Printer::stepperDirection[Z_AXIS] = 0; (It was possible that the printer hung with the wrong combination of moveZ directions + waitUntilEndOfAllMoves)
- Stability: Commands::waitUntilEndOfAllMoves() now checks if zCMP is blocked by stepper direction and ignores wait in that case.
- cleanup of HomeY und HomeX
- ENDSTOP_X_RETEST_REDUCTION_FACTOR is not used at homeY anymore. -> ENDSTOP_Y_RETEST_REDUCTION_FACTOR instead.
- tuned Z_ENDSTOP_MAX_HYSTERESIS to 0.35f
- The rule that the bed tunes down by zCMP if homed and matrix>0 is bad if you want to scan anything. -> REMOVED!
- Preheat PLA/ABS does not block status line in display anymore.

V RF.01.41.06.Mod alpha (2018-03-13)
- more testing on serial -> Fletcher error correction really seems to work flawless.
- re-/implemented some debugging gode for serial errors
- fixed formats in GCode::printCommand()
- fixed sending Com::tWrongChecksum when using parseBinary (I once forgot newline)
- we temporarily set Z_ENDSTOP_MAX_HYSTERESIS 0.5f for mhiers tests

V RF.01.41.05.Mod alpha (2018-03-12)
- corrected unit calculation in void Printer::MemoryPosition()
- rise of LOW_TICKS_PER_MOVE to 500k (It might not have a big effect but maybe on some parts)
- removed some old TODOs on which I am now absolut sure how to handle them.
- dont show "setTemperatureForExtruder(): cant set Temp for Extr." when it is set to 0°C.
- switched MOVE_CACHE back to 17 for testing reasons.
- update void Printer::MemoryPosition() close towards repetier
- fix missing PSTR -> https://github.com/repetier/Repetier-Firmware/issues/763
- deleted UI_ANIMATION and some unused functions

V RF.01.41.04.Mod alpha (2018-03-12)
- added FEATURE_DEBUG_MOVE_CACHE_TIMING to debug movecache fill while printing.
    if you want to adjust LOW_TICKS_PER_MOVE to default: M3993 P300000 (LOW_TICKS_PER_MOVE is 300000)
    if you want to read and drop statistics:             M3993

V RF.01.41.03.Mod alpha (2018-03-10)
- some tiny tweaks
- cleanup of homeZ for better reading. Inserted a lot of casts.
- removed some functions which are not needed anymore because their purpose already got removed.

V RF.01.41.02.Mod alpha (2018-03-10)
This is the "intelligent filament load update"
- new M3913 P[digits] which mounts/extrudes filament until Pxxxx digits are reached then stops.
- new M3914 P[digits] which unmounts the extruder by slowly heating and checking force. It is/was quite hard to test out good settings for unmount. This might be updated in future, but I like it.
- inserted M3913 and M3914 into MOUNT_FILAMENT_SCRIPT_... and UNMOUNT_FILAMENT_SCRIPT_... to vastly improve "Menu->Extruder->(Un)Load Filament"
- compressed functions for MOUNT_FILAMENT_SCRIPT_WITH_HEATING and MOUNT_FILAMENT_SCRIPT_WITHOUT_HEATING functions to one, because they where quite identical.

V RF.01.41.01.Mod alpha (2018-03-10)
- output object speeds are now limited to normal homing speeds. OctaStepping made that too fast. Thx@ AtlonXP
- MOUNT and UNMOUNT Scripts got an extra G92 E0 to in some cases prevent undo afterwards. Thx@ easygo25
- sync of UNMOUNT_FILAMENT_SCRIPTs and MOUNT_FILAMENT_SCRIPTs for both devices (RF2000/RF1000)

V RF.01.41.00.Mod alpha (2018-03-09)
- deleted M3002 and M3003 because they are not needed anymore. (We use M3007 and M3008 for this functionality. Not using M3007/M3008 it is even better because this mod has an automatic mode for placing those two values right :D)
- deleted M3100 because we have a smart menu point (Menu->Position->Z-Step: XXX um) for that and this functionality is only used in menu.
- deleted M3101 because there is no real need for this adjustment. Normal extrusion is not "directsteps over button"
- deleted M3102 because we have M3105 to configure Pause-Position in [mm]
- made the automatic startline a bit shorter when having dual hotend (i always forget to change x-axis-length when testswitching)
- the automatic startline only shifts in y when having a dual hotend, not on single anymore.
- split RF_MICRO_STEPS to {RF_MICRO_STEPS_XY, RF_MICRO_STEPS_Z, RF_MICRO_STEPS_E}
- added menu for changing Micro Steps:
    XY is unlocked for 16,32,64 Microsteps
    Z is unlocked for 16,32 Microsteps
    E is unlocked for 16,32,64,128 Microsteps.
  (High Microsteps are only usefull if you have low steps/mm. Otherwise you just get a slow printer. My testprint worked fine on E=64, Z=32, XY=64.
   Using 128+ Microsteps on XY sounds horrible and is slower than 128=65mm/s or 256=32mm/s -> not a good choice!
   I think E shouldnt have more Steps/mm than ~1200 max. that corresponds to a speed < 25mm/s for retracts.)
- changed some minor details to unhook RF_MICRO_STEPS from (some) places of use without inheritance.
- Z_OVERRIDE_MAX is now Printer::ZOverrideMax.
- reduced automatic startline spacing (for multiple lines) to 1.5mm instead of 2.0mm.
- removed and replaced some configuration with STEPS inside, because they are not good for configurable Micro_Steps and bad for EEPROM-configurable steps/mm. This totally cleaned up HBS-Scan configuration. :)
- removed static XAXIS_STEPS_PER_MM, YAXIS_STEPS_PER_MM, ZAXIS_STEPS_PER_MM from places which are no pre-initialisers.
- removed some configuration lines which had no effect anywhere
- disabled FEATURE_VISCOSITY_TEST by default to save rom space.
- included mhiers push https://github.com/Nibbels/Repetier-Firmware/commit/8c4a33112d4323a205822558c1870ae9309ab808 of changing WORK_PART_SCAN_X_STEP_SIZE_MIN_MM 5 (etc.) into Nibbels branch too.
- g_nManualSteps[E_AXIS] and g_nPauseSteps[E_AXIS] are now updated according to active steps/mm when choosing an extruder. Extruder Button speed should now stay the same when changing steps/mm.
- investigating g_nManualSteps[E_AXIS] and PrintLine::performDirectSteps();
    1) i found a second reason for the E_Axis to have a time lag using PrintLine::performDirectSteps() -> Hal.cpp OCR1A = too high at the end of the function.
    2) i found a third reason for the E_Axis to have a time lag using 128 Microsteps / 0.9° Stepper = 2560Steps/s: Advance might just fill up working too slow. -> Stay beneath 1280 Steps/mm
- fixed RF2000 optional temperature sensor. We removed Temptable 15 and renamed it to 14. I forgot to change this default Tempsensor as well. (See V RF.01.38.Mod (2017-12-28))

V RF.01.39+.Mod (2018-03-05)
[...]
Bitte nutzt diesen Thread ab jetzt, um Probleme/Verbesserungen bezüglich dem Mod zu diskutieren. Ältere Versionen will ich persönlich nicht mehr diskutieren, es sei denn es war da was besser, das wir zurückbauen sollten.
Erklärungen zum Mod gibts inzwischen einige im Wikipedia und auf Youtube, ich habe erst gestern ein paar Bilder vom Druckerdisplay hinzugefügt, sodass man die Funktionen besser zuordnen kann. Viel besser sind aber Youtube-Videos, die etwas erklären. Das weiß ich, aber es bleibt eben arbeit. Ich versuche auch, wenn mich Fragen erreichen, diese Artikel im Wiki zu verbessern und zu ergänzen.

Zaldo meinte in einem vorhergehenden Thread, er hat bei seinem Drucker noch einen Restart-Bug beim Z-Offset-Scan, den ich selbst aber nicht nachvollziehen kann (auch nicht bei den mir bekannten Druckern) und ich habe bisher von ihm keine weiteren Informationen erhalten. Abgesehen davon ist die Weiterentwicklung gerade ziemlich langweilig geworden, weil ich keine echten Bugs mehr kenne. :prost:

LG

Re: Community Mod RFx000 Firmware :: Neue Stable (Stand 1.42.03 / 28.07.2018)

Verfasst: Sa 28. Jul 2018, 18:50
von Digibike
Nibbels hat geschrieben:...Bitte nutzt diesen Thread ab jetzt, um Probleme/Verbesserungen bezüglich dem Mod zu diskutieren. Ältere Versionen will ich persönlich nicht mehr diskutieren, es sei denn es war da was besser, das wir zurückbauen sollten.
Erklärungen zum Mod gibts inzwischen einige im Wikipedia und auf Youtube, ich habe erst gestern ein paar Bilder vom Druckerdisplay hinzugefügt, sodass man die Funktionen besser zuordnen kann. Viel besser sind aber Youtube-Videos, die etwas erklären. Das weiß ich, aber es bleibt eben arbeit. Ich versuche auch, wenn mich Fragen erreichen, diese Artikel im Wiki zu verbessern und zu ergänzen.

Zaldo meinte in einem vorhergehenden Thread, er hat bei seinem Drucker noch einen Restart-Bug beim Z-Offset-Scan, den ich selbst aber nicht nachvollziehen kann (auch nicht bei den mir bekannten Druckern) und ich habe bisher von ihm keine weiteren Informationen erhalten. Abgesehen davon ist die Weiterentwicklung gerade ziemlich langweilig geworden, weil ich keine echten Bugs mehr kenne. :prost:

LG
… Würde dann empfehlen, eventuelle Anfragen bezüglich Rückbau von älteren Versionen dies nicht zu posten, sondern erstmal eine Anfrage als PN - nur allzu gern wird ansonsten wieder eine Heillose Diskussion angestoßen und dann wird's schnell wieder unübersichtlich...
Nur als Denkanstoß eventuell. Wenn´s interessant ist, kann man´s nach Klärung ja immer noch hier rein setzen, aber so bleibt der Thread beim akutellen Mod und wird nicht wieder zerredet (einfach übersichtlicher).

… Dir wird langweilig? Wow! Da muß doch was zu arrangieren sein... :lol: :zwinkern:
Das hat Conrad vorher die Jahre nicht geschafft, dass keine großen Bug-Meldungen mehr
rein kamen... :good:

Gruß, Christian

Re: Community Mod RFx000 Firmware :: Neue Stable (Stand 1.42.03 / 28.07.2018)

Verfasst: Sa 28. Jul 2018, 22:49
von AtlonXP
Danke Nibbels,
ich habe eben deine Hausaufgaben im WIKI nachgeschaut.
Eine einfache Bedienungsanleitung zum Schreiben und lesen sollte ausreichen.
Diese kann besser Aktualisiert und Archiviert werden.
Ich denke es sollte so gut sein.
Leider ist die Anleitung noch nicht vollständig.

Da ich schon einige Zeit als Betatester und Kritiker ausfalle
(mein Drucker ist zwangsweise eingemottet), sollte auch alles Funktionieren. ;-)

Zwei Dinge waren noch offen bevor ich meinen Drucker stilllegen musste:

1.) Leichtes Stocken bei engen Radien und drucken über SD Karte.
Ich sehe das nicht als FW Problem sondern ein Schwachpunkt unserer Hardware.
Als Gegenmaßnahme kann hier eine Veränderung der Pufferparameter helfen.
Die optimalen Parameter konnte ich nicht mehr ermitteln.
Vielleicht hat auch das Einfügen der neuen SD-Fat Library, etwas gebracht?

2.) Das Benchy Problem.
Da gab es eine leichte Oberflächen Störung.
Ich glaube das ist noch offen.
Kann das sein?

LG AtlonXP

Re: Community Mod RFx000 Firmware :: Neue Stable (Stand 1.42.03 / 28.07.2018)

Verfasst: So 29. Jul 2018, 22:30
von Nibbels
Digibike hat geschrieben: … Dir wird langweilig? Wow! Da muß doch was zu arrangieren sein... :lol: :zwinkern:
Das hat Conrad vorher die Jahre nicht geschafft, dass keine großen Bug-Meldungen mehr
rein kamen... :good:

Gruß, Christian
Hehe, langweilig in dem Sinn, dass für mich persönlich meine eigene Firmware so passt wie sie nun ist.
Das mit dem "langweilig wurde nun oft erwähnt" :D
Mir persönlich ist ja nicht echt langweilig. Ich kann nun 3D-Drucken und beginnen Knowhow fürs Fräsen einzusammeln. Ich meinte damit natürlich, dass es immer unspannender wird, weitere Features und Bugs in der Firmware zu recherchieren.
Wir haben einfach schon zu viele Themen durch.

Achja, was wir noch nicht gemacht haben: Das Upgrade von Firmware und Hardware (Platine) auf 32bit :P
AtlonXP hat geschrieben: Leider ist die Anleitung noch nicht vollständig.
Das stimmt natürlich :)
AtlonXP hat geschrieben: Zwei Dinge waren noch offen bevor ich meinen Drucker stilllegen musste:

1.) Leichtes Stocken bei engen Radien und drucken über SD Karte.
Ich sehe das nicht als FW Problem sondern ein Schwachpunkt unserer Hardware.
Als Gegenmaßnahme kann hier eine Veränderung der Pufferparameter helfen.
Die optimalen Parameter konnte ich nicht mehr ermitteln.
Vielleicht hat auch das Einfügen der neuen SD-Fat Library, etwas gebracht?

2.) Das Benchy Problem.
Da gab es eine leichte Oberflächen Störung.
Ich glaube das ist noch offen.
Kann das sein?

LG AtlonXP
Punkt 1: Ich weiß nicht genau was ich dagegen tun sollte. Es ist ja auch irgendwie ein Grenzfall, der noch mit GCode etc. zu tun hat. Ich sehe das Problem bei mir bisher quasi nicht. Hab halt rumgesucht, Puffer optimiert, Ram gespart und dieses Benchmark-Feature eingebaut - doch ich sehe da nichts!
Punkt 2: Wir hatten darüber geschrieben und ich glaube rf1k_mhj11 hatte mal Testdrucke gemacht. Mein Erinnerungsvermögen hat mich diesbezüglich aber verlassen. Hatten wir das sauber getestet oder fehlen mir abschließende Informationen?

Mit sauber getestet meine ich:
- Tritt dieses Muster nachweisbar nur beim Mod auf und nicht in der original Firmware?
- Tritt es bei manchen Slicern nicht auf? / Hat das mit dem schrägen Winkel zu tun, in dem gedruckt wird?
- Wenn es nur beim Mod aufträte, muss jemand (ich vermutlich) testen, ab welcher Version es auftritt, dann würden wir die Änderungen sehen und ich kann rausfinden, wie es dazu kommen konnte.

LG

Re: Community Mod RFx000 Firmware :: Neue Stable (Stand 1.42.03 / 28.07.2018)

Verfasst: So 29. Jul 2018, 23:26
von AtlonXP
Hallo Nibbels,
zu Punkt 1:
Es wird wohl Optimierung in den Pufferparameter sein.
Das sollte ich hin bekommen wenn ich wieder Drucken kann.
Man sollte es soweit hin bekommen, dass der Drucker noch langsamer wird bevor der Puffer vollends leer ist.
Kurzum, der Drucker darf sehr langsam fahren, aber bloß nicht kurzzeitig stehen bleiben.
Nibbels hat geschrieben: Punkt 2: Wir hatten darüber geschrieben und ich glaube rf1k_mhj11 hatte mal Testdrucke gemacht. Mein Erinnerungsvermögen hat mich diesbezüglich aber verlassen. Hatten wir das sauber getestet oder fehlen mir abschließende Informationen?

Mit sauber getestet meine ich:
- Tritt dieses Muster nachweisbar nur beim Mod auf und nicht in der original Firmware?
- Tritt es bei manchen Slicern nicht auf? / Hat das mit dem schrägen Winkel zu tun, in dem gedruckt wird?
- Wenn es nur beim Mod aufträte, muss jemand (ich vermutlich) testen, ab welcher Version es auftritt, dann würden wir die Änderungen sehen und ich kann rausfinden, wie es dazu kommen konnte.
Meine Erinnerung ist da noch scharf!
rf1k_mhj11 hatte für uns einen Testdruck gemacht.
rf1k_mhj11 arbeitet mit org. FW Ver.? und mit Slic3r.
Leider hatte rf1k_mhj11 das Benchy etwas eingedreht, somit ist das nicht Fehler behaftete Benchy nicht aussagekräftig genug.
Er hatte die STL Datei von mir bekommen und bei mir war der Fehler zu sehen wie bei dir.

Hier ist das Problem identisch, wie bei mir an deinem goldenen Benchy:
http://www.rf1000.de/viewtopic.php?p=22825#p22825

Es geht hier nicht um das Gosthing, es sind die schrägen Wellen (von oben nach unten) an der Seitenwand und der Dachkannte.

Wenn jemand als Betatester mit einem RFX000 einspringen möchte, dem sende ich gerne per PN die STL Datei zum Testen.
Nibbels und ich drucken mir S3D.

LG AtlonXP

Re: Community Mod RFx000 Firmware :: Neue Stable (Stand 1.42.03 / 28.07.2018)

Verfasst: Di 31. Jul 2018, 11:34
von Digibike
AtlonXP hat geschrieben:Hallo Nibbels,
zu Punkt 1:
Es wird wohl Optimierung in den Pufferparameter sein.
Das sollte ich hin bekommen wenn ich wieder Drucken kann.
Man sollte es soweit hin bekommen, dass der Drucker noch langsamer wird bevor der Puffer vollends leer ist.
Kurzum, der Drucker darf sehr langsam fahren, aber bloß nicht kurzzeitig stehen bleiben.
...LG AtlonXP
Sorry, das ich mich einmische, aber wäre nicht sinnvoll/möglich, das der Drucker bei unterschreitung eines bestimmten
Volumens 10 % langsamer Druckt und gleichzeitig die Temperatur um 3 % absenkt?
Hintergrund, ist der, dass es wohl bei sehr engen Radien usw. zu so einem Underrun kommen könnte bzw. wenn die Datei
so gut wie fertig gedruckt ist. In beiden Fällen ist eine Absenkung der Temperatur dadurh, dass der Druckkopf sehr schnell
und oft über dem selben Bereich fährt schonmal von Vorteil - zumal bei reduzierung der Geschwindigkeit ja eigentlich auch
die Temperatur reduziert werden sollte. Gleichzeitig bekmmt man als Anwender gleich eine Rückmeldung, da Plötzlich die
Temperatur abfällt und der Drucker merklich langsamer fährt....
Eine Portierung auf ei geeignetes 32 Bit Board hört sich gut an.... Da wären wohl manche Probleme vom Tisch...1
Habt Ihr da schon was im Auge, was geeignet wäre?

Gruß, Christian

Re: Community Mod RFx000 Firmware :: Neue Stable (Stand 1.42.03 / 28.07.2018)

Verfasst: Di 31. Jul 2018, 16:07
von Oo
Hi all,
Digibike hat geschrieben:..
Eine Portierung auf ei geeignetes 32 Bit Board hört sich gut an.... Da wären wohl manche Probleme vom Tisch...1
Habt Ihr da schon was im Auge, was geeignet wäre?
32-Bit und Arduino Kompatible ist z.b. der ESP32.

https://de.wikipedia.org/wiki/ESP32

Das ist der große Bruder vom ESP8266 keine 32-Bit aber hat mehr Power wie ein "normal" Arduino.

https://de.wikipedia.org/wiki/ESP8266

Der ESP8266 wird bis jetzt so weit ich weiß besser von Arduino unterstützt, da der ESP32 "neuer" ist.

Fehlt halt nur der Rest wie Treiber usw...
Die ESP´s gibt es auch ohne Board also "nackt" damit wäre es sogar möglich sich sein eigenes 3D Drucker Board zu gestalten.

Oo

Re: Community Mod RFx000 Firmware :: Neue Stable (Stand 1.42.03 / 28.07.2018)

Verfasst: Di 31. Jul 2018, 20:16
von Nibbels
Hmm, wenn man sowas machen würde, mit welchem PCB-Programm müsste man anfangen zu malen?

Bzw. hat das von uns einer gelernt und als Hobby?
:)

Ich hab bisher beim ESP32 nur mit Micropython experimentiert. Eigentlich nur kaum, Wessix war da tiefer drin.

Warum gibt's damit keine mir bisher bekannten Druckboards? Oder ist der zu neu und ich hab nicht recherchiert? Viele setzen meiner Information nach auf den DUE.

LG

Re: Community Mod RFx000 Firmware :: Neue Stable (Stand 1.42.03 / 28.07.2018)

Verfasst: Di 31. Jul 2018, 21:02
von Oo
Das Maß aller Dinge ist so weit ich weiß Eagle.
https://de.wikipedia.org/wiki/Eagle_(Software)
Kostet halt auch.

Man müsste ja nicht unbedingt das Ganze Board Designen.
Die Dinger gibt es ja schon fertig. Ich mein was braucht es den noch groß?
Die Treiber und vielleicht ein bisschen Hühnerfutter(Kleinkram)?
Keine Ahnung wie weit ihr in der Materie drin seid.
Ich hab da nur halbwissen.
Aber sollte mit ein bisschen Elektroerfahrung schon möglich sein,
RAMPS mit dem ESP zu verbinden.

DUE hat halt weniger Power.
Der DUE sieht aber interessant aus.
Ist der Baugleich zum MEGA?
Den, wenn ja da RAMPS drauf und schon ist die Sache fast fertig?!

Der Code wird da bestimmt interessanter :).

Kommt halt auch darauf an, ob ihr euch der Aufgabe stellen wollt...
Hört sich schon nach Arbeit an.


Oo

Re: Community Mod RFx000 Firmware :: Neue Stable (Stand 1.42.03 / 28.07.2018)

Verfasst: Mi 1. Aug 2018, 01:37
von AtlonXP
Oo hat geschrieben: DUE hat halt weniger Power.
Der DUE sieht aber interessant aus.
Ist der Baugleich zum MEGA?
Den, wenn ja da RAMPS drauf und schon ist die Sache fast fertig?!

Der Code wird da bestimmt interessanter :).
Oo wie weise. :-)
Hier ein Blick hinter die Kulissen!
https://www.3d-druck-community.de/thread-20844.html

Hier noch die Erweiterung für das EEPROM.
Scheinbar kann die FW nur 32KB von den 256 KB adressieren.
Das wäre schon die erste Herausforderung für Nibbels. ;-)
https://www.3d-druck-community.de/thread-22938.html

Die FW ist unserer ähnlich (Marlin) und sollte funzen.
Natürlich gibt es noch einiges zu tun bis diese Steuerung so weit ist wie unsere Mod. FW
Ich persönlich möchte auf keines unserer Features verzichten.
DMS usw...

@Nibbels,
so einen Mainbordchip selber zu verbauen halte ich für schwierig.
Ich habe Zweifel, dass wir so ein feines Layout fräsen können, geschweige es zu verlöten.
Gut man könnte eine Adapterplatine ätzen, aber das feine Ding mit Lötpaste von Hand auflöten?

An meinem China Fräsle war ein Programm zur PCB Erstellung dabei.
Habe allerdings noch keine Ahnung, ob das was taugt.

LG AtlonXP