Core XY Motor Movement Debacle
CarbonVirus last edited by
Hello all, odd one here.
I recently revamped a Core XY based printer I've been building for the last few months and essentially rotated my belt design 180 deg; after completing the physical change, I connected my Duet 2 Wifi back up and inverted the X/Y drive settings. Now when I try to move the shuttle along the x-axis it rotates only the motor connected to the x-drive port on the Duet.
I've tried the following with no luck:
- I've reset my firmware to factory and then manually added the M669 command for Core XY
- Used the RRF config tool to generate new firmware
- Tried all 4x combos on X/Y motor directions
- Run M669 command in console followed by G91/G1 commands to try and move axis
- Ran M503 to list settings and verified printer is in Core XY mode
I am seeing the same issue along the y-axis too; only the motor connected to the Duet's y-motor pinout is rotating.
At this point the only explanation I have is the printer is stuck in standard X/Y single-axis movement and cannot run in Core-XY mode, but I'm at a loss for how I can force it to reset/undo this.
Thanks In advance for any assistance!
Board: Duet 2 WiFi (2WiFi)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.1.1 (2020-05-19b2)
Duet WiFi Server Version: 1.23
engikeneer last edited by
@CarbonVirus how are you moving your machine? If manually typing Gcode (G0 or G1) and include H2 in the command, it will command only the specified axis motor, rather than move to that position. I fell in to that trap when upgrading to RRF3 and redoing my config.
If you're doing it from the DWC buttons and can still get that behaviour, I'm not so sure. Do both motors move in any case (I.e. is the Y motor just not working, dodgy wiring, driver issues etc). Do all axes home okay? Failing those ideas, a copy of the output from M122 might help someone more knowledgeable than me...
CarbonVirus last edited by
@engikeneer I was running a G91 for relative move followed by a G1 H2 X5 F2000 to move along the x-axis; it seems this series of commands side-steps the Core XY calculations and resulted in the issue I was experiencing.
I have run the homing sequences on my x and y axes now and everything is working again; the reason I was not doing this is I wished to ensure the axes moved in the proper direction before attempting the homing sequence (I use motor-stall homing on all axes).
Thank you very much for the suggestion, I am unsure if the experienced issue is a bug or just the expected outcome; either way your help is much appreciated!!
See here for testing and commissioning coreXY, particularly the motor test section.