Neue Development Firmware (RF.01.15)
-
- Developer
- Beiträge: 340
- Registriert: Fr 10. Okt 2014, 16:31
- Has thanked: 40 times
- Been thanked: 80 times
Neue Development Firmware (RF.01.15)
Hallo,
wir haben heute die neue Version der Development Firmware auf GitHub hochgeladen. Diese meldet sich als "RF.01.15" und kann sowohl für den RF1000 als auch für den RF2000 kompiliert werden.
Das Change Log dazu lautet:
V RF.01.15 (2016-03-05)
- Adding of support for the following device configuration:
- RF2000 + miller
- Direct steps into the y and z direction could cause small, unwanted steps into the x direction.
- These small steps could cause the x stepper to buzz.
- The menu items "Set XY Start" and "Set XY End" did not set the start/end position properly in case direct movements where used to move to the start/end position.
- The driving free of Z-Max has been improved for RF1000 configurations where Z-Min and Z-Max are within one circuit.
- readIdlePressure() cancels the heat bed scan in case the idle pressure is not constant.
- After the start of the heat bed scan, the firmware waits until all temperatures are reached before it starts with the homing.
- After the homing, the z-axis is moved down HEAT_BED_SCAN_Z_START_STEPS steps (default = 0.5 mm).
- The default homing speeds for the milling mode have been increased by about 50 %.
mfG
RF1000
wir haben heute die neue Version der Development Firmware auf GitHub hochgeladen. Diese meldet sich als "RF.01.15" und kann sowohl für den RF1000 als auch für den RF2000 kompiliert werden.
Das Change Log dazu lautet:
V RF.01.15 (2016-03-05)
- Adding of support for the following device configuration:
- RF2000 + miller
- Direct steps into the y and z direction could cause small, unwanted steps into the x direction.
- These small steps could cause the x stepper to buzz.
- The menu items "Set XY Start" and "Set XY End" did not set the start/end position properly in case direct movements where used to move to the start/end position.
- The driving free of Z-Max has been improved for RF1000 configurations where Z-Min and Z-Max are within one circuit.
- readIdlePressure() cancels the heat bed scan in case the idle pressure is not constant.
- After the start of the heat bed scan, the firmware waits until all temperatures are reached before it starts with the homing.
- After the homing, the z-axis is moved down HEAT_BED_SCAN_Z_START_STEPS steps (default = 0.5 mm).
- The default homing speeds for the milling mode have been increased by about 50 %.
mfG
RF1000
- riu
- Administrator
- Beiträge: 1297
- Registriert: Do 4. Sep 2014, 23:48
- Wohnort: Düsseldorf
- Has thanked: 55 times
- Been thanked: 165 times
- Kontaktdaten:
Re: Neue Development Firmware (RF.01.15)
Hallo RF1000.
Kurze Bemerkung am Rande. Meines erachtens wird der RF1000 hauptsächlich in DACH verkauft oder? Das Changelog sollte das auch honorieren und in deutsch existieren. Nicht alle die einen RF1000 haben kommen mit dem Fachenglisch wirklich klar. Das finde ich suboptimal.
Zum Changelog:
Liebe Grüße,
Udo
Kurze Bemerkung am Rande. Meines erachtens wird der RF1000 hauptsächlich in DACH verkauft oder? Das Changelog sollte das auch honorieren und in deutsch existieren. Nicht alle die einen RF1000 haben kommen mit dem Fachenglisch wirklich klar. Das finde ich suboptimal.
Zum Changelog:
Während eines HBS ist meine IDLE Pressure nie konstant. Die ist schon nach dem ersten abtasten (Anfahren an Z Punkt ermitteln, freifahren) anders als beim start. Bedeutet dies einn abbruch des Scans? Und nein meine Meszellen sind nicht defekt oder ausgenudelt. Das gleiche verhalten habe ich mit nagelneuen Meszellen die ich testweise eingebaut habe um das auszuschliessen die hatte ich in Reserve.RF1000 hat geschrieben: - readIdlePressure() cancels the heat bed scan in case the idle pressure is not constant.
Liebe Grüße,
Udo
-
- Developer
- Beiträge: 340
- Registriert: Fr 10. Okt 2014, 16:31
- Has thanked: 40 times
- Been thanked: 80 times
Re: Neue Development Firmware (RF.01.15)
Wird geklärt.riu hat geschrieben: Das Changelog sollte das auch honorieren und in deutsch existieren. Nicht alle die einen RF1000 haben kommen mit dem Fachenglisch wirklich klar. Das finde ich suboptimal.
Nein, bedeutet es nicht. Diese Änderung ist eine reine Sicherheitsmaßnahme für jemanden, der mechanisch etwas grob falsch gemacht hat (z.B. Extruder berührt das Heizbett wenn Z-Min auslöst). Der "Idle Pressure" ist der Druck VOR dem Anfahren vom ersten Messpunkt, der sollte recht konstant sein (+/- wenige Digits). Wenn der Scan einmal gestartet worden ist wird readIdlePressure() nicht mehr verwendet.riu hat geschrieben: Während eines HBS ist meine IDLE Pressure nie konstant. Die ist schon nach dem ersten abtasten (Anfahren an Z Punkt ermitteln, freifahren) anders als beim start. Bedeutet dies einn abbruch des Scans?
mfG
RF1000
-
- Erfahrener 3D-Drucker
- Beiträge: 163
- Registriert: Do 13. Nov 2014, 08:55
- Wohnort: Wuppertal
- Has thanked: 57 times
- Been thanked: 9 times
Re: Neue Development Firmware (RF.01.15)
Hallo RF1000
Schön wäre, wenn der maximale Druck an den Sensoren beim Scannen bei einer Überlast >16000, keinen weiteren Versuch macht den Drucker zu zerstören. Das passiert bei mir leider in unregelmäßigen Abständen, wo ich das Gefühl habe ein Vorzeichen im Anfahren/Wegfahren vertauscht wird.
Bei mir nur mit NOT-AUS aufzuhalten und macht mächtig Krach.
Es scheint die maximale Kontrolle zu fehlen (bzw. denkt er macht es richtig, fährt aber in die falsche Richtung.
Dadurch ist mein Grundwert der Wägezellen auf einen viel höheren Wert geklettert (Bleibende Verformung) und das passierte beim automatischen Scannen.
Zur Zeit ist die Firmware (und da wird die RF.01.15 auch zu gehören) nicht bei jeder Konfiguration in der Lage einen brauchbaren kurzen Scan zu machen (teilweise 3 Versuche um einen Wert zu erhalten). Bei der optischen Kontrolle weiß man gar nicht was da falsch läuft, den alles sieht gut aus.
Ob die Toleranzschwelle nicht ausreicht (Toleranz) um rund zu laufen, keine Ahnung warum dies so statisch passiert und nicht vor jeder Messung neu eingestellt wird (ebenfalls von rui beobachtet).
Ist es ggf. möglich den jetzigen Wert (der Wägezellen) als Null-Wert einzustellen also mit einem Offset zu belegen?
Gruß Frank
Schön wäre, wenn der maximale Druck an den Sensoren beim Scannen bei einer Überlast >16000, keinen weiteren Versuch macht den Drucker zu zerstören. Das passiert bei mir leider in unregelmäßigen Abständen, wo ich das Gefühl habe ein Vorzeichen im Anfahren/Wegfahren vertauscht wird.
Bei mir nur mit NOT-AUS aufzuhalten und macht mächtig Krach.
Es scheint die maximale Kontrolle zu fehlen (bzw. denkt er macht es richtig, fährt aber in die falsche Richtung.
Dadurch ist mein Grundwert der Wägezellen auf einen viel höheren Wert geklettert (Bleibende Verformung) und das passierte beim automatischen Scannen.
Zur Zeit ist die Firmware (und da wird die RF.01.15 auch zu gehören) nicht bei jeder Konfiguration in der Lage einen brauchbaren kurzen Scan zu machen (teilweise 3 Versuche um einen Wert zu erhalten). Bei der optischen Kontrolle weiß man gar nicht was da falsch läuft, den alles sieht gut aus.
Ob die Toleranzschwelle nicht ausreicht (Toleranz) um rund zu laufen, keine Ahnung warum dies so statisch passiert und nicht vor jeder Messung neu eingestellt wird (ebenfalls von rui beobachtet).
Ist es ggf. möglich den jetzigen Wert (der Wägezellen) als Null-Wert einzustellen also mit einem Offset zu belegen?
Gruß Frank
RF1k_1: Erhöh.+Verl. Kabelk. (2G), NOT-AUS (Reset), Opt. Z-Endschalter, Einhausung, Aludruckfräspl.
RF1k_2: Erhöh. Kabelk., 2x Motorkühlung, Lüfterplatine, 2xY, X-,Y-Gegenlager, magn. Alupl. mit Metallauflage, 2x E3D V6 (L 3mm, R 1,75mm)
RF1k_2: Erhöh. Kabelk., 2x Motorkühlung, Lüfterplatine, 2xY, X-,Y-Gegenlager, magn. Alupl. mit Metallauflage, 2x E3D V6 (L 3mm, R 1,75mm)
-
- Anfänger
- Beiträge: 7
- Registriert: Sa 4. Jul 2015, 16:45
- Wohnort: Bad Steben
Re: Neue Development Firmware (RF.01.15)
Hey Leute, bekomm die neue Firmware irgendwie nicht kompiliert. Bei mir kommt trotz neuster Version von Ardiuno, ständig die Fehlermeldung: pasting "/* PINB.3, 22, MISO*/" and "_DDR" does not give a valid preprocessing token
Hat jemand diesbezüglich eine Idee? Wäre für jede Hilfe dankbar. PS: Versuch natürlich auch die richtige Firmware auf den RF2000 zu spielen, also das könnte ihr schon mal ausschließen!
Hat jemand diesbezüglich eine Idee? Wäre für jede Hilfe dankbar. PS: Versuch natürlich auch die richtige Firmware auf den RF2000 zu spielen, also das könnte ihr schon mal ausschließen!
-
- Profi 3D-Drucker
- Beiträge: 415
- Registriert: Sa 18. Okt 2014, 22:20
- Has thanked: 84 times
- Been thanked: 69 times
Re: Neue Development Firmware (RF.01.15)
Du darfst nicht die neueste Arduino Version nehmen sondern 1.6.5
E3DV6+Titan Total Conversion
Aluheizbett + MTPlus + zweite Y-Schiene mit Wagen
Z-Kette
X-kette
Platinenlüfter
X19 Schaltung LED
pi-Octopi+ Cam
Ritzel-Kühler
Firmware Mod 1.45.00
Aluheizbett + MTPlus + zweite Y-Schiene mit Wagen
Z-Kette
X-kette
Platinenlüfter
X19 Schaltung LED
pi-Octopi+ Cam
Ritzel-Kühler
Firmware Mod 1.45.00
-
- Developer
- Beiträge: 340
- Registriert: Fr 10. Okt 2014, 16:31
- Has thanked: 40 times
- Been thanked: 80 times
Re: Neue Development Firmware (RF.01.15)
Typischerweise gibt es ein mechanisches Problem, sobald irgend ein Messpunkt einen 2. Scanversuch benötigt. Bitte kontrolliere noch einmal, ob der Extruder wirklich frei ist oder ob er z.B. über eine Schraube oder das Förderrad eine unerwünschte Verbindung hat.RFrank hat geschrieben: Zur Zeit ist die Firmware (und da wird die RF.01.15 auch zu gehören) nicht bei jeder Konfiguration in der Lage einen brauchbaren kurzen Scan zu machen (teilweise 3 Versuche um einen Wert zu erhalten). Bei der optischen Kontrolle weiß man gar nicht was da falsch läuft, den alles sieht gut aus.
Die Toleranz wird am Anfang von jedem Scan auf Basis des "Idle Pressure" ermittelt, also auf Basis von dem DMS-Wert, der vor dem Scan dem Ruhezustand entspricht. Eine Nullstellung sollte daher nicht notwendig sein.RFrank hat geschrieben: Ob die Toleranzschwelle nicht ausreicht (Toleranz) um rund zu laufen, keine Ahnung warum dies so statisch passiert und nicht vor jeder Messung neu eingestellt wird (ebenfalls von rui beobachtet).
Ist es ggf. möglich den jetzigen Wert (der Wägezellen) als Null-Wert einzustellen also mit einem Offset zu belegen?
mfG
RF1000
-
- Anfänger
- Beiträge: 7
- Registriert: Sa 4. Jul 2015, 16:45
- Wohnort: Bad Steben
Re: Neue Development Firmware (RF.01.15)
Danke für den Tipp, hab mich mir gedownloaded, nun kommt aber wieder eine andere Fehlermeldung...Wessix hat geschrieben:Du darfst nicht die neueste Arduino Version nehmen sondern 1.6.5
Langsam nervt mich das alles nur noch...
Hier die aktuelle Fehlermeldung:
Arduino: 1.6.5 (Windows 8.1), Platine: "Arduino/Genuino Mega or Mega 2560, ATmega2560 (Mega 2560)"
Build-Optionen wurden verändert, alles wird neu gebaut
Code: Alles auswählen
Commands.cpp:21: error: stray '\' in program
const int sensitive_pins[] PROGMEM = SENSITIVE_PINS; // Sensitive pin list for M42
^
In file included from Repetier.h:35:0,
from Commands.cpp:19:
pins.h:225: error: stray '#' in program
#define SENSITIVE_PINS {0, 1, X_STEP_PIN, X_DIR_PIN, X_ENABLE_PIN, ORIG_X_MIN_PIN, X_MAX_PIN, Y_STEP_PIN, Y_DIR_PIN, Y_ENABLE_PIN, Y_MIN_PIN, Y_MAX_PIN, Z_STEP_PIN, Z_DIR_PIN, Z_ENABLE_PIN, Z_MIN_PIN, Z_MAX_PIN, LED_PIN, PS_ON_PIN, \ HEATER_0_PIN, HEATER_1_PIN, ORIG_FAN_PIN, E0_PINS E1_PINS E2_PINS TEMP_0_PIN, TEMP_1_PIN, SDSS }#endif // PINS_H
^
Commands.cpp:21:39: note: in expansion of macro 'SENSITIVE_PINS'
const int sensitive_pins[] PROGMEM = SENSITIVE_PINS; // Sensitive pin list for M42
^
In file included from Repetier.h:35:0,
from Commands.cpp:19:
pins.h:2: error: 'This' does not name a type
This file is part of the Repetier-Firmware for RF devices from Conrad Electronic SE.
^
pins.h:10: error: 'without' does not name a type
but WITHOUT ANY WARRANTY; without even the implied warranty of
^
In file included from p:\program files (x86)\arduino\hardware\tools\avr\lib\gcc\avr\4.8.1\include\stdint.h:9:0,
from p:\program files (x86)\arduino\hardware\tools\avr\avr\include\inttypes.h:37,
from p:\program files (x86)\arduino\hardware\tools\avr\avr\include\avr\pgmspace.h:86,
from HAL.h:28,
from Repetier.h:36,
from Commands.cpp:19:
p:\program files (x86)\arduino\hardware\tools\avr\avr\include\stdint.h:159:9: error: 'int8_t' does not name a type
typedef int8_t int_least8_t;
^
p:\program files (x86)\arduino\hardware\tools\avr\avr\include\stdint.h:213:9: error: 'int8_t' does not name a type
typedef int8_t int_fast8_t;
^
In file included from HAL.h:57:0,
from Repetier.h:36,
from Commands.cpp:19:
HAL.h: In static member function 'static void HAL::spiBegin()':
fastio.h:49: error: 'DIOMISO_PIN_DDR' was not declared in this scope
#define _SET_INPUT(IO) do {DIO ## IO ## _DDR &= ~MASK(DIO ## IO ## _PIN); } while (0)
^
fastio.h:73:25: note: in expansion of macro '_SET_INPUT'
#define SET_INPUT(IO) _SET_INPUT(IO)
^
HAL.h:645:9: note: in expansion of macro 'SET_INPUT'
SET_INPUT(MISO_PIN);
^
In file included from HAL.h:57:0,
from Repetier.h:36,
from Commands.cpp:19:
fastio.h:49: error: 'DIOMISO_PIN_PIN' was not declared in this scope
#define _SET_INPUT(IO) do {DIO ## IO ## _DDR &= ~MASK(DIO ## IO ## _PIN); } while (0)
^
fastio.h:30:30: note: in definition of macro 'MASK'
#define MASK(PIN) (1 << PIN)
^
fastio.h:73:25: note: in expansion of macro '_SET_INPUT'
#define SET_INPUT(IO) _SET_INPUT(IO)
^
HAL.h:645:9: note: in expansion of macro 'SET_INPUT'
SET_INPUT(MISO_PIN);
^
In file included from HAL.h:57:0,
from Repetier.h:36,
from Commands.cpp:19:
HAL.h: In static member function 'static void HAL::spiInit(uint8_t)':
fastio.h:49: error: 'DIOMISO_PIN_DDR' was not declared in this scope
#define _SET_INPUT(IO) do {DIO ## IO ## _DDR &= ~MASK(DIO ## IO ## _PIN); } while (0)
^
fastio.h:73:25: note: in expansion of macro '_SET_INPUT'
#define SET_INPUT(IO) _SET_INPUT(IO)
^
HAL.h:671:9: note: in expansion of macro 'SET_INPUT'
SET_INPUT(MISO_PIN);
^
In file included from HAL.h:57:0,
from Repetier.h:36,
from Commands.cpp:19:
fastio.h:49: error: 'DIOMISO_PIN_PIN' was not declared in this scope
#define _SET_INPUT(IO) do {DIO ## IO ## _DDR &= ~MASK(DIO ## IO ## _PIN); } while (0)
^
fastio.h:30:30: note: in definition of macro 'MASK'
#define MASK(PIN) (1 << PIN)
^
fastio.h:73:25: note: in expansion of macro '_SET_INPUT'
#define SET_INPUT(IO) _SET_INPUT(IO)
^
HAL.h:671:9: note: in expansion of macro 'SET_INPUT'
SET_INPUT(MISO_PIN);
^
In file included from Repetier.h:37:0,
from Commands.cpp:19:
gcode.h: At global scope:
gcode.h:226: error: 'int8_t' does not name a type
static int8_t waitingForResend; ///< Waiting for line to be resend. -1 = no wait.
^
In file included from Repetier.h:38:0,
from Commands.cpp:19:
RF.h:551: error: variable or field 'nextPreviousZAction' declared void
extern void nextPreviousZAction( int8_t next );
^
RF.h:551: error: 'int8_t' was not declared in this scope
In file included from Repetier.h:39:0,
from Commands.cpp:19:
ui.h:234: error: 'int8_t' does not name a type
extern const int8_t encoder_table[16] PROGMEM;
^
In file included from Repetier.h:39:0,
from Commands.cpp:19:
ui.h:368: error: 'int8_t' does not name a type
int8_t shift; // Display shift for scrolling text
^
ui.h:382: error: 'int8_t' does not name a type
int8_t oldMenuLevel;
^
ui.h:385: error: 'int8_t' does not name a type
int8_t encoderPos;
^
ui.h:386: error: 'int8_t' does not name a type
int8_t encoderLast;
^
ui.h:395: error: 'int8_t' has not been declared
void nextPreviousAction(int8_t next);
^
In file included from Repetier.h:43:0,
from Commands.cpp:19:
SdFat.h:1962: error: 'int8_t' does not name a type
int8_t readDir(dir_t& dir, char *longfilename) {return readDir(&dir, longfilename);}
^
SdFat.h:1975: error: 'int8_t' does not name a type
int8_t readDir(dir_t* dir, char *longfilename);
^
SdFat.h:2048: error: 'int8_t' does not name a type
int8_t lsPrintNext(uint8_t flags, uint8_t indent);
^
SdFat.h:2055: error: 'int8_t' has not been declared
dir_t *getLongFilename(dir_t *dir, char *longFilename, int8_t cVFATNeeded, uint32_t *pwIndexPos);
^
SdFat.h:2056: error: 'int8_t' has not been declared
bool findSpace(dir_t *dir, int8_t cVFATNeeded, int8_t *pcVFATFound, uint32_t *pwIndexPos);
^
SdFat.h:2056: error: 'int8_t' has not been declared
bool findSpace(dir_t *dir, int8_t cVFATNeeded, int8_t *pcVFATFound, uint32_t *pwIndexPos);
^
SdFat.h:2203: error: 'int8_t' does not name a type
int8_t readDir(dir_t& dir) // NOLINT
^
In file included from Repetier.h:129:0,
from Commands.cpp:19:
Extruder.h:52: error: 'int8_t' does not name a type
int8_t heatManager; ///< How is temperature controled. 0 = on/off, 1 = PID-Control, 3 = dead time control
^
In file included from Repetier.h:129:0,
from Commands.cpp:19:
Extruder.h:113: error: 'int8_t' does not name a type
int8_t stepperDirection;
^
In file included from Repetier.h:35:0,
from Commands.cpp:19:
pins.h:225: error: expected ',' or ';' before 'endif'
#define SENSITIVE_PINS {0, 1, X_STEP_PIN, X_DIR_PIN, X_ENABLE_PIN, ORIG_X_MIN_PIN, X_MAX_PIN, Y_STEP_PIN, Y_DIR_PIN, Y_ENABLE_PIN, Y_MIN_PIN, Y_MAX_PIN, Z_STEP_PIN, Z_DIR_PIN, Z_ENABLE_PIN, Z_MIN_PIN, Z_MAX_PIN, LED_PIN, PS_ON_PIN, \ HEATER_0_PIN, HEATER_1_PIN, ORIG_FAN_PIN, E0_PINS E1_PINS E2_PINS TEMP_0_PIN, TEMP_1_PIN, SDSS }#endif // PINS_H
^
Commands.cpp:21:39: note: in expansion of macro 'SENSITIVE_PINS'
const int sensitive_pins[] PROGMEM = SENSITIVE_PINS; // Sensitive pin list for M42
^
stray '\' in program
"Ausführliche Ausgabe während der Kompilierung"
aktiviert in Datei > Einstellungen
Zuletzt geändert von riu am Di 22. Mär 2016, 08:42, insgesamt 1-mal geändert.
Grund: Das Chaos mal in CODE Tags gepackt
Grund: Das Chaos mal in CODE Tags gepackt
-
- Prof. Dr. des 3D-Drucks
- Beiträge: 1672
- Registriert: Fr 11. Sep 2015, 11:37
- Has thanked: 279 times
- Been thanked: 247 times
Re: Neue Development Firmware (RF.01.15)
Moin,
habe nun endlich Zeit gefunden, mich mal wieder mit dem Drucker zu beschäftigen und als erstes die neue Firmware aufgespielt Zwei Bugs sind mir aufgefallen. Beide sind wahrscheinlich nicht neu in dieser Version, ich bin einfach nur noch nicht so weit gekommen mit den alten Versionen:
1. Wenn ich FEATURE_OUTPUT_FINISHED_OBJECT deaktiviere, compiliert die Firmware nicht mehr, da die Symbole OUTPUT_OBJECT_SCRIPT_PRINT und OUTPUT_OBJECT_SCRIPT_MILL nicht mehr existieren. Ich habe als Lösung in dem Fall (#else) beide einfach als leer definiert.
2. Im Fräsmodus funktioniert bei mir die Work Part Compensation nicht. Ich habe zum Test eine absichtlich schiefe Platte gescannt. Die Matrix sieht wie zu erwarten aus:
Gruß und danke!
Martin
habe nun endlich Zeit gefunden, mich mal wieder mit dem Drucker zu beschäftigen und als erstes die neue Firmware aufgespielt Zwei Bugs sind mir aufgefallen. Beide sind wahrscheinlich nicht neu in dieser Version, ich bin einfach nur noch nicht so weit gekommen mit den alten Versionen:
1. Wenn ich FEATURE_OUTPUT_FINISHED_OBJECT deaktiviere, compiliert die Firmware nicht mehr, da die Symbole OUTPUT_OBJECT_SCRIPT_PRINT und OUTPUT_OBJECT_SCRIPT_MILL nicht mehr existieren. Ich habe als Lösung in dem Fall (#else) beide einfach als leer definiert.
2. Im Fräsmodus funktioniert bei mir die Work Part Compensation nicht. Ich habe zum Test eine absichtlich schiefe Platte gescannt. Die Matrix sieht wie zu erwarten aus:
Matrix
Wenn ich die Kompensation mit M3141 einschalte, fährt zwar einmalig der Z-Motor hörbar und laut Anzeige an eine leicht andere Position, bei X und Y Bewegungen bleibt die Z-Position aber die selbe. Die geänderte Position scheint nicht von der X und Y Position abzuhängen, und ein erneuter M3141 bewirkt gar nichts. Das sollte doch aber so funktionieren, oder?Gruß und danke!
Martin
Gruß, Martin
Klipper Firmware für den RFx000: Klipper für RFx000 | Original-Dokumentation | Diskussion | Wiki mit Installations-Anleitung
(Ich bin in diesem Forum nicht mehr aktiv)
Klipper Firmware für den RFx000: Klipper für RFx000 | Original-Dokumentation | Diskussion | Wiki mit Installations-Anleitung
(Ich bin in diesem Forum nicht mehr aktiv)
-
- Developer
- Beiträge: 340
- Registriert: Fr 10. Okt 2014, 16:31
- Has thanked: 40 times
- Been thanked: 80 times
Re: Neue Development Firmware (RF.01.15)
Hallo mhier,
grundsätzlich sollte das natürlich funktionieren.
Der Scan von deiner Matrix hat ja ganz offensichtlich geklappt. Kannst du die Firmware einmal mit DEBUG_WORK_PART_Z_COMPENSATION auf 1 kompilieren, den Repetier-Host mitlaufen lassen und dann die Logdatei (vom Einschalten der Firmware bis zum Ende vom Fräsvorgang) hier posten?
Zusätzlich wäre evtl. auch der verwendete G-Code nützlich und ein M3153 (= Ausgabe der Matrix), falls sich die Matrix seit deinem letzten Post geändert hat.
Danke im Voraus,
RF1000
grundsätzlich sollte das natürlich funktionieren.
Der Scan von deiner Matrix hat ja ganz offensichtlich geklappt. Kannst du die Firmware einmal mit DEBUG_WORK_PART_Z_COMPENSATION auf 1 kompilieren, den Repetier-Host mitlaufen lassen und dann die Logdatei (vom Einschalten der Firmware bis zum Ende vom Fräsvorgang) hier posten?
Zusätzlich wäre evtl. auch der verwendete G-Code nützlich und ein M3153 (= Ausgabe der Matrix), falls sich die Matrix seit deinem letzten Post geändert hat.
Danke im Voraus,
RF1000