Hallo zusammen,

habe aktuell die 1.45.01 drauf. Wenn ich versuche im Menü die Steps für XY auf 16 zu stellen, stürz der Drucker ab und bei einem Neustart werden die default Einstellungen geladen.
Diesen Fehler hatte ich bei einer älteren Version auch schon.

Kann man den RF auf 16 steps stellen? Wenn nicht sollte aber trotzdem nicht der Drucker abstürzen oder?


Grüße Ricardo

Hallo Ricardo

Es hat sicher einen Grund, dass Parameter nur in einem bestimmten Bereich geändert werden können - mal bei Nibbels anklopfen.

Meine Befürchtung ist, Du Verwechselst die Microsteps aus der Configuration.h

/**
* \brief Define the to-be-used micro steps.
* Note that high MICRO_STEPS limit your speed because of the limit in 8bit-CPU calculation power.
* See "configuration of the speed vs. cpu usage" within RF1000.h / RF2000.h
*
* Your way to high microsteps is dual-stepping, quadstepping, octostepping. On high speeds that packs steps together to save CPU. Read rf1000.de for the downside. Menu->Stepper->DblFQ: is the setting for the shifting speed.
* High microstepping make your speed low. Dont use 256, avoid 128.
* 256 Microsteps sound very bad and is slower 30mm/s in X and Y. Avoid it! 128 is not much better. 64 might be ok for XY.
* Better dont rise Z because it is already slow with 2560steps/mm @32 Microsteps.
* Change your EEPROMs Steps/mm accordingly if you change RF_MICRO_STEPS_ in this configuration. Steps/mm are autoadjusted if you use FEATURE_ADJUSTABLE_MICROSTEPSs Menu!
*/

#define RF_MICRO_STEPS_Z 16 // standard/best 32 or 16
#define RF_MICRO_STEPS_XY 32 // standard/best 32 or 64
#define RF_MICRO_STEPS_E 32 // standard/best 32 or 64 (or 128?? --> untested!)

mit den Schritten pro Millimeter, aus der rf1000.h ...

/** \brief Drive settings for printers with cartesian drive systems */
/** \brief Number of steps for a 1mm move in x direction.
For xy gantry use 2*belt moved!
Overridden if EEPROM activated. */
#define XAXIS_STEPS_PER_MM float(4.761875 * (float)RF_MICRO_STEPS_XY)

/** \brief Number of steps for a 1mm move in y direction.
For xy gantry use 2*belt moved!
Overridden if EEPROM activated.*/
#define YAXIS_STEPS_PER_MM float(4.761875 * (float)RF_MICRO_STEPS_XY)

Mit ist derzeitig auch kein Grund für solch ein Anliegen klar.
Sollten Probleme mit der Modellgröße bestehen, muss zu nächst die Zuverlässigkeit des Datensatzes und dann die Skalierung im Slicer überprüft werden. Die Microsteps solltest Du ohne Not nicht ändern - das fine tuning geht besser durch einen Eintrag im EPROM bei den Steps per mm an denentsprechendenAchsen.

Oder bin ich jetzt von der Rolle und Du meinst etwas völlig anderes?

Gruß zero K

Nein ich meine schon die MicroSteps. Und die kann man unter Konfiguration - Stepper auch direkt am Drucker ändern.

Das Problem ist , das z.b. Simplify3D manchmal sehr hochaufgelöste STL auch sehr hoch aufgelöst sliced . Und ein 8bit Board mit 32 Micro Steps kommt da schnell an seine Grenzen. Bei Rundungen ist da, zumindest bei mir, so ab 70 bis 80 mm/s Schluss und es fängt an zu ruckeln.
Wollte halt mal testen ob es was bringt mit weniger MicroSteps zu fahren.

Aber selbst wenn es nicht geht , sollte der Drucker nicht abstürzen, und er verwirft dabei auch noch alle anderen Einstellungen und setzt diese auf Default zurück.

Danke!

Ich werde versuchen das zu testen. Gerade sind leider beide Drucke im Einsatz und mir fehlt etwas die Zeit. Früher ging das mal.

Ricardo1980 hat geschrieben:Hallo zusammen,

habe aktuell die 1.45.01 drauf. Wenn ich versuche im Menü die Steps für XY auf 16 zu stellen, stürz der Drucker ab und bei einem Neustart werden die default Einstellungen geladen.
Diesen Fehler hatte ich bei einer älteren Version auch schon.

Kann man den RF auf 16 steps stellen? Wenn nicht sollte aber trotzdem nicht der Drucker abstürzen oder?


Grüße Ricardo

Guten Morgen

Ich habe mir dein Problem mit dem Microsteps-Menü angeschaut.
Das habe ich bei meinen beiden RF2000 getestet und da läuft es.

Du sagst jedoch, die Default-Werte werden geladen. Das bedeutet für mich, dass die Checksumme nach dem Restart nicht stimmt.
Die Checksumme wird ganz am Ende des Vorgangs aktualisiert und da das etwas dauert (einige Millisekunden) könnte es am Watchdog liegen. Eigentlich ist das aber kein Problem, denn um den Watchdog kümmert sich die Eeprom-Checksummen-Update-Funktion. Der Watchdog-Chip selbst wird ständig von einem Interrupt aus entwarnt, der einen Zeitstempel abgleicht wann die Firmware das letzte mal ihr "OK - ich laufe noch" gegeben hat.

Mir ist aufgefallen, dass ich als Paranoia-Check während der Microsteps-Änderungen alle Interrupts sperre. Und wenn das wirklich funktioniert, muss der gesamte Programm-Ablauf innerhalb des Hardware-Watchdog-Timeout ablaufen können.
Bei mir funktioniert das, wie gesagt.
Allerdings sagt die Erfahrung, dass es bei den Watchdogs der Boards größere Toleranzen gibt, wann die auslösen. Das würde den Reset erklären.

Diese einfache Zeilenvertauschung in der UI.cpp könnte das Problem also lösen:
https://github.com/Nibbels/Repetier-Fir ... c98635b3d1

Kannst du dir testweise hier https://github.com/Nibbels/Repetier-Firmware diese "community_development" (1.45.02) herunterladen und mir zurückmelden, ob es bei deinem Drucker das Problem löst?
Wenn ja, schiebe ich den Patch nach https://github.com/RF1000community/Repetier-Firmware.

LG

Ricardo1980 hat geschrieben:Und ein 8bit Board mit 32 Micro Steps kommt da schnell an seine Grenzen. Bei Rundungen ist da, zumindest bei mir, so ab 70 bis 80 mm/s Schluss und es fängt an zu ruckeln.
Wollte halt mal testen ob es was bringt mit weniger MicroSteps zu fahren.

Daran habe ich viel experimentiert. Mich würde es freuen, wenn du mir eine unabhängige Rückmeldung gibst.

Die Firmware schickt wenn die Taktung der Step-Interrupts zu hoch wird,
(=die Zeitspanne zwischen den Steps zu klein)
Steps gesammelt in einem Interrupt als "Burst" raus.
Damit will man das Problem mit den zu hohen Microsteps bei 8bit und 16Mhz etwas abfedern. Es ändert sich aber dadurch u.U. der "Ton", wenn die zeitliche Abfolge der Steps je nach Geschwindigkeit/beim Beschleunigen verändert wird.

Den Grenzwert, ab wievielen Takten "gepaart" wird findet man im Menü beim Punkt "MinInterval:". Ich glaube das war im Geschwindigkeits-Menü. (Ohne Nachschauen). Man kann da etwas rumspielen, weil ich mir nicht 100% sicher war - der sollte aber passen.

Ideal ist das Verhalten unterhalb des Double-Step-Limits, aber man kann trotzdem hohe Reise-Geschwindigkeiten (150mm/s usw.) einstellen. Stellst du auf konstante 16 Microsteps verdoppelt sich natürlich auch dass Limit und damit die Geschwindigkeit unter der "perfekt getimed" wird.

Ob ich schlussendlich beim Druckteil einen Unterschied sehen würde, ist die große Frage.

EDIT: Man darf bei kleinsten Pfadstücken (GCODE) nicht vergessen, dass die serielle Kommunikation und Pfad-Pufferung selbst ein großes Problem ist. Die reine Ausgabe der Steps würgt uns die Pfadplanung mit zu kleinem "MinInterval:" zwar zuverlässig ab. Man muss jedoch immer beide Aufgaben, Stepping und Pfadplanung als Flaschenhälse sehen, wenn der Slicer unsinnig feine Pfade generiert. Die Mod-Firmware kann aber inzwischen mit Pfadstücken die kleiner als 1 Step sind umgehen. Früher wurde das als Travel-Bewegung interpretiert und dann hats ständig geruckelt ohne dass der Grund nachvollziehbar war. (Beschleunigung auf ~0 vor jedem Travel.)
LG

ok, danke erstmal. Muss schauen wie ich dazu komme, mein Drucker steht leider nicht direkt neben dem Rechner(wegen flashen) und da ein Ausgang auf meinem Board kaputt ist muss ich die Firmware immer etwas anpassen (Ausgang umschreiben).
Aber ich schaue das ich die Woche dazu komme.