CoreXY /Repetier X/Y Achsen spinnen

Hallo zusammen,

ich komme hier mit meinem CoreXY Projekt nicht weiter: Ich bin dabei, erstmal die X&Y Achsen zu testen, Z, Extruder, Heizer usw. habe ich noch garnicht verdrahtet. Nur diese Achsen spinnen total, nach folgender, völlig verrückter "Logiktabelle":

Befehl (per gCode) ---> tatsächlicher Fahrweg
y+10 ---> x++
y-10 ---> y--
x+10 ---> y--
x-10 ---> x++

Sprich: Die Achsen bewegen sich nur stur in eine Richtung, unabhängig in welche Richtung sie eigentlich fahren sollen. Oder ob sie überhaupt dran sind mit fahren.

Der Verhalten tritt mit Repetier 0.92.7 und 0.92.8 auf. Hardware ist ein Arduino DUE Clone + radds (1.5, glaube ich) + RAPS128 Stepper, an 24V.
Probiert habe ich in den Einstellungen die beiden "z axis + H-gantry/Core" Möglichkeiten, "Delay stepper high signal" 0-2, "Delay stepper direction signal" 0-2 und alle möglichen Kombinationen davon. EEPROM ist von Anfang an auf disabled, sodas mir hier hoffentlich nix reinfuscht.
Zur Sicherheit ist hier die Configuration.h .

Hat jemand von Euch eine Idee?

-Alex-

M119 liefert für alle Endstops ein low/offen?

Nicht, dass die FW glaubt ein endstop wäre ausgelöst und deshalb die fahrbewegung nur in eine Richtung ausführt.

Bis dann,
jan

M119 liefert Endstopwerte wie erwartet. Es passt ja auch nicht zum Verhalten: Der Achsen fahren ja. Nur halt in 50% der Fälle die falschen und immer in eine Richtung. Bei getriggertem Endstop dürfte er ja in einer Richtung garnichts tun.

Selbst beim Homen macht er den selben Quatsch: An den Endstop fahren, dann statt 2mm zurück die andere Achse fahren.

Hallo!

Vielleicht mal Marlin4Due ausprobieren?
Wenn das klappt, dann liegt es wohl nicht an der Hardware.

Klingt auf jeden Fall speziell...

Bis dann,
jan

Marlin4Due kompiliert garnicht erst:

/home/alex/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -Os -Wl,--gc-sections -T/home/alex/.arduino15/packages/arduino/hardware/sam/1.6.6/variants/arduino_due_x/linker_scripts/gcc/flash.ld -Wl,-Map,/tmp/build5347646041162729127.tmp/Marlin.cpp.map -o /tmp/build5347646041162729127.tmp/Marlin.cpp.elf -L/tmp/build5347646041162729127.tmp -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--entry=Reset_Handler -Wl,--unresolved-symbols=report-all -Wl,--warn-common -Wl,--warn-section-align -Wl,--start-group /tmp/build5347646041162729127.tmp/syscalls_sam3.c.o /tmp/build5347646041162729127.tmp/watchdog.cpp.o /tmp/build5347646041162729127.tmp/vector_3.cpp.o /tmp/build5347646041162729127.tmp/ultralcd.cpp.o /tmp/build5347646041162729127.tmp/temperature.cpp.o /tmp/build5347646041162729127.tmp/stepper_indirection.cpp.o /tmp/build5347646041162729127.tmp/stepper.cpp.o /tmp/build5347646041162729127.tmp/servo.cpp.o /tmp/build5347646041162729127.tmp/qr_solve.cpp.o /tmp/build5347646041162729127.tmp/planner.cpp.o /tmp/build5347646041162729127.tmp/mesh_bed_leveling.cpp.o /tmp/build5347646041162729127.tmp/fsr_sensor.cpp.o /tmp/build5347646041162729127.tmp/digipot_mcp4451.cpp.o /tmp/build5347646041162729127.tmp/configuration_store.cpp.o /tmp/build5347646041162729127.tmp/cardreader.cpp.o /tmp/build5347646041162729127.tmp/buzzer.cpp.o /tmp/build5347646041162729127.tmp/blinkm.cpp.o /tmp/build5347646041162729127.tmp/SdVolume.cpp.o /tmp/build5347646041162729127.tmp/SdFile.cpp.o /tmp/build5347646041162729127.tmp/SdBaseFile.cpp.o /tmp/build5347646041162729127.tmp/Sd2Card.cpp.o /tmp/build5347646041162729127.tmp/Marlin_main.cpp.o /tmp/build5347646041162729127.tmp/M100_Free_Mem_Chk.cpp.o /tmp/build5347646041162729127.tmp/HAL.cpp.o /tmp/build5347646041162729127.tmp/Marlin.cpp.o /tmp/build5347646041162729127.tmp/Wire/Wire.cpp.o /tmp/build5347646041162729127.tmp/LiquidCrystal/LiquidCrystal.cpp.o /tmp/build5347646041162729127.tmp/SPI/SPI.cpp.o /tmp/build5347646041162729127.tmp/variant.cpp.o /home/alex/.arduino15/packages/arduino/hardware/sam/1.6.6/variants/arduino_due_x/libsam_sam3x8e_gcc_rel.a /tmp/build5347646041162729127.tmp/core.a -Wl,--end-group -lm -gcc 
arm-none-eabi-gcc: error: /tmp/build5347646041162729127.tmp/core.a: No such file or directory

Marlin4Due über die ArduinoIDE? Das core.a kommt normal über die IDE und hat nix mit Marlin4Due zu tun.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Ja, ich habe es über die Arduino-IDE kompiliert. Version 1.6.5, damit bekommt man zumindest Repetier kompilliert.
Ich kann gerade nicht nachschauen: Ist da ein funktionierendes Makefile drin, das man es auch ohne die IDE kompillieren kann? Bei der 8Bit-Variante klappt das ja sehr gut.

Nein, das vorhandene Makefile wurde bisher nicht angepasst.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Ok, mit welcher IDE (und welcher Version der SAM-Boards) kompillierst Du Marlin4Due erfolgreich?

Mit der 1.5.8 unter Linux. Aber vielleicht hat deine IDE bei nem Update nen Problem bekommen?

Was meinst du mit "welche Version des SAM-Boards"?

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Die Arduino-IDE kennt von sich aus ja irgendwie den DUE garnicht. Darum muss über den Boardmanager dieses Wissen erst importiert werden -> durch Installation der SAM-Boards.

Ja, mit den neueren Versionen. Bei der 1.5.8 ist der dabei.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Ok, mit der 1.5.8 kompilliert Marlin4Due. Nur: Wie kann ich da mal fix die Thermistor-Prüfung abschalten? Ich möchte ja erstmal nur x&y Achse testen, und Marlin legt sich sofort die Karten, wenn es meint das der Thermistor einen weg hat.

Vielleicht die min temp kleiner als den gelieferten wert setzen?!?
Oder 0?

#define HEATER_0_MINTEMP 0

OdermPseudethermistor einstellen. Ich glaube 99 oder so zeigt immer 25° an.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Hab ich, und auch CoreXY in der Firmware definiert. Nun habe ich das gleiche Problem wie unter Repetier, siehe erster Post. Irgendwie bin ich langsam ratlos. Woran kann das liegen?

Das schließt wohl Software und/oder Konfiguration als Ursache aus.

Ich würde die Riemen mal vom pulley nehmen und die Firmware für ein normales kartesisches system konfigurieren. Also 1 Motor pro Achse.

Dann mal die Achsen durchprobieren.

Da kannste dann auch hingehen und mal einfach verschiedene Motor/stepper Kombinationen durchprobieren. Beim umstecken aber immer Strom aus!

Irgendein Bauteil muss es ja sein.

Bis dann,
jan

Habe ich inzwischen gemacht -> es muss einer der RAPS128 sein. *grml*
Hätte ich die mal vorher getestet...