CoreXY setup problems with movement
-
It seems to me you are missing steps (maybe due to unsufficient motor current), on top of your config.g, please post the output of M122 (after performing move commands)
-
Thanks for the replies. I will try and get the info and testing done tonight and will post what I find.
-
If a command to move just X or Y caused a diagonal move, then it sounds as though your config.g file is set up for a Cartesian instead of a CoreXY printer. Post your config.g file so we can check.
-
Make sure that you have:
M667 S1, that's what tells your Wifi to go CoreXY.
Sources:
http://reprap.org/wiki/G-code#M667:_Select_CoreXY_mode
https://www.duet3d.com/wiki/Configuring_RepRapFirmware_for_a_CoreXY_printer -
Here is my config file, as requested.
; Configuration file for Duet WiFi (firmware version 1.20 or newer)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool on Mon Jan 08 2018 23:23:13 GMT-0500 (Eastern Standard Time); General preferences
M111 S0 ; Debugging off
G21 ; Work in millimetres
G90 ; Send absolute coordinates…
M83 ; ...but relative extruder moves
M555 P2 ; Set firmware compatibility to look like Marlin
M911 S10 R11 P"M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000" ; Configure automatic saving on power lossM667 S1 ; Select CoreXY mode
M208 X0 Y0 Z0 S1 ; Set axis minima
M208 X300 Y300 Z300 S0 ; Set axis maxima; Endstops
M574 X1 Y1 Z1 S0 ; Set active low endstops
M558 P0 H5 F120 T6000 ; Set Z probe type to switch and the dive height + speeds
G31 P600 X0 Y0 Z2.5 ; Set Z probe trigger value, offset and trigger height
M557 X15:285 Y15:285 S20 ; Define mesh grid; Drives
M569 P0 S1 ; Drive 0 goes forwards
M569 P1 S1 ; Drive 1 goes forwards
M569 P2 S1 ; Drive 2 goes forwards
M569 P3 S1 ; Drive 3 goes forwards
M350 X64 Y64 Z16 E16 I1 ; Configure microstepping with interpolation
M92 X320 Y298 Z1000 E420 ; Set steps per mm
M566 X900 Y900 Z12 E120 ; Set maximum instantaneous speed changes (mm/min)
M203 X6000 Y6000 Z180 E1200 ; Set maximum speeds (mm/min)
M201 X500 Y500 Z250 E250 ; Set accelerations (mm/s^2)
M906 X1600 Y1600 Z800 E800 I30 ; Set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout; Heaters
M301 H0 S1.00 P10 I0.1 D200 T0.4 W180 B30 ; Use PID on bed heater (may require further tuning)
M305 P0 T100000 B4138 C0 R4700 ; Set thermistor + ADC parameters for heater 0
M143 H0 S120 ; Set temperature limit for heater 0 to 120C
M305 P1 T100000 B4138 C0 R4700 ; Set thermistor + ADC parameters for heater 1
M143 H1 S280 ; Set temperature limit for heater 1 to 280C; Tools
M563 P0 D0 H1 ; Define tool 0
G10 P0 X0 Y0 Z0 ; Set tool 0 axis offsets
G10 P0 R0 S0 ; Set initial tool 0 active and standby temperatures to 0C; Network
M550 ; Set machine name
M551 ; Set password
M552 S1 ; Enable network
M587 ; Configure access point. You can delete this line once connected
M586 P0 S1 ; Enable HTTP
M586 P1 S0 ; Disable FTP
M586 P2 S0 ; Disable Telnet; Fans
M106 P0 S0.6 I0 F500 H-1 ; Set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned off
M106 P1 S1 I0 F500 H1 T45 ; Set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned on
M106 P2 S1 I0 F500 H1 T45 ; Set fan 2 value, PWM signal inversion and frequency. Thermostatic control is turned on; Custom settings are not configured
; Miscellaneous
M501 ; Load saved parameters from non-volatile memory -
Here is the result of M122 after performing some X and Y moves:
7:48:38 PMM122
=== Diagnostics ===
Used output buffers: 3 of 32 (14 max)
=== Platform ===
RepRapFirmware for Duet WiFi version 1.20 running on Duet WiFi 1.0
Board ID: 08DGM-95BNL-MGPSN-6JKDG-3SJ6M-T1Y3Y
Static ram used: 15448
Dynamic ram used: 99000
Recycled dynamic ram: 240
Stack ram used: 1392 current, 4504 maximum
Never used ram: 11880
Last reset 00:03:21 ago, cause: software
Last software reset at 2018-01-09 19:45, reason: User, spinning module GCodes, available RAM 11904 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 31.9, current 32.5, max 32.7
Supply voltage: min 12.4, current 12.4, max 12.6, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max 0/62
Driver 1: standstill, SG min/max 0/187
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Date/time: 2018-01-09 19:48:37
Cache data hit count 761373032
Slowest main loop (seconds): 0.155537; fastest: 0.000110
=== Move ===
MaxReps: 4, StepErrors: 0, FreeDm: 240, MinFreeDm 237, MaxWait: 113854ms, Underruns: 0, 0
Scheduled moves: 26, completed moves: 26
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
Network state is running
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.20
WiFi MAC address 2c:3a:e8:0b:1e:c7
WiFi Vcc 3.40, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 16336
WiFi IP address 192.168.10.131
WiFi signal strength -51dBm, reconnections 0, sleep mode modem
HTTP sessions: 1 of 8
Socket states: 2 0 0 0 0 0 0 0
Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) -
Why are your X and Y steps/mm different in the M92 command? Thet would normally be identical for a CoreXY printer.
-
They are different, because if they were the same, it was not accurate. So this way if I move 20mm, I get 20mm. They both stared at 320 steps/mm.
-
Also, when I had this printer running with a ramps 1.4 and mega 2560 setup, the steps were the same and I could print a calibration cube to within 0.02mm accuracy. So I don’t think it’s a printer setup issue.
-
We have a good number of CoreXY printer owners running with Duets, and none of them has had this type of issue before. AFAIK all of them are running with the same X and Y steps/mm. So I think the issue is either a new mechanical problem on your machine, or one of the following:
- Acceleration configured too high (M201)
- Maximum speed configured too high (M203)
- Jerk configured too high (M566)
- Motor current configured too low (M906)
However, I don't rule out a hardware problem, such as a partially failed driver chip on the Duet.
-
Both motors contribute to movement on a CoreXY. For pure X moves, both motors rotate in the same direction. For pure Y moves, the motors rotate in opposite directions. To get movement at 45 degrees, one motor will be stationary. Any other angle will require one motor to run at a different speed to another.
So it follows that, providing both motors have the same step angle (which they should) and both pulleys are the same size (which they should be) then the steps per mm must be set the same. If this results in some degree of angular movement, then one pulley must be rotating at a different speed to the other. So as well as the settings that David suggested you check, I'd also suggest you check that all the grub screws are tight, in case one or other pulley is slipping.
Edit. A 20 tooth pulley needs 80 steps per mm at 16x micro stepping so at 64 times micro stepping 320 steps per mm is correct.
2nd Edit. Or it could be that the belts aren't parallel to the axes but they would need to be a long way out and it would be a fundamental design\build fault that needs rectifying.
3rd Edit. The speed, acceleration, instantaneous speed change (jerk) and motor currents in the above config.g are all less than than my setting for my printer, so unless your moving mass is greater than my 2kg per gantry, then they should be fine.
-
I’ll see if I can clarify anything.
Before changing to the Duet board, I was using a ramps 1.4, an Arduino mega 2560 clone alone with A4988 drivers. The printer was able to print at 100mm/s accurately to within 0.02mm.
The only thing I changed was going to a Duet Wifi board. I ran the configurator and uploaded the files to the board through the web interface. I first started with default speeds and acceleration but I was having problems, so I changed to settings similar to my ramps setup, but it hasn’t helped.
At first I was getting almost 45 degree movements and as I changed microsteps and current, it got better and worse and better again.
For troubleshooting, I tried to loosen and tighten the belts, kept upping the current but stopped at 1600ma since these motors are rated at 1.68 amps. I also changed both X and Y motors, went through the microsteps and current changes and still no difference.Right now I have it at the closest it’s been. For 200mm of X movement, 10mm of Y movement happens also. Same if I move 200mm Y, I get 10mm X.
I’m leaning towards the board and might pull the board and put the ramps back in tonight to see what happens.
-
I really don't understand why you would ever need to reduce the steps/mm (from 320 to 298). A belt might move less than it is supposed to, if the pulley is loose or the motor loses steps. But if you reduced the steps/mm, that suggests the belt was moving more than it should have done, which isn't possible unless something else is pulling it as well as the motor.
-
I just reinstalled the ramps setup and confirmed that X and Y have the same steps in Marlin ( same firmware when it was installed before switching tnthecDuet board), they are each set at 80 steps/mm since it’s 16 microsteps. Just about to print a test cube, but all movements are the way they are supposed to. I command 200mm Y and I get 200mm Y with no X movement. Command 200mm X and I get 200mm X with no Y movement.
So that tells me there is something wrong with the DUET board. For some reason it's not driving the motors the way it's supposed to.
So a 50$ ramps 1.4/arduino mega 2560/A4988 clone setup performs great so far, not like the nearly 300$ CAD duet board.
Is this possibly a programming issue, even though it all appears correct, or is it possibly a defective board?
-
20mm test cube complete with the Ramps setup.
Printed at 100mm/s and all axis are within 0.03mm or less. I would say the printer is good mechanically.
Should i be contacting the dealer that sold me the board and return it?
-
you said that with the Ramps both X and Y steps are at 80 steps/mm at 16 micro steps so they are the same Yes or No
-
20mm test cube complete with the Ramps setup.
Printed at 100mm/s and all axis are within 0.03mm or less. I would say the printer is good mechanically.
Should i be contacting the dealer that sold me the board and return it?
It is possible that you have a defective stepper driver but I suggest you run the checks of motor movement that I linked to in my first post above, just to make sure that it isn't a configuration issue.
-
you said that with the Ramps both X and Y steps are at 80 steps/mm at 16 micro steps so they are the same Yes or No
With the Ramps setup, yes they are the same and everything works like it is supposed to. With the Duet board, NO, it wasn’t working with the steps the same.
-
It is possible that you have a defective stepper driver but I suggest you run the checks of motor movement that I linked to in my first post above, just to make sure that it isn't a configuration issue.
I went through that before joining the forum as part of the troubleshooting.
The one thing I didn’t do was to measure to see if it was actually diagonal by measuring. I was looking for general direction movement. Also when commanding just one axis to move, as in X +10, the X and Y both had movement.
-
It is possible that you have a defective stepper driver but I suggest you run the checks of motor movement that I linked to in my first post above, just to make sure that it isn't a configuration issue.
I went through that before joining the forum as part of the troubleshooting.
The one thing I didn’t do was to measure to see if it was actually diagonal by measuring. I was looking for general direction movement. Also when commanding just one axis to move, as in X +10, the X and Y both had movement.
I'm just a tad confused by that. When you run the G1 S2 commands that I linked to, they test each individual motor so movement should be at 45 degrees. You shouldn't need to measure anything to see if it's diagonal as it ought to be obvious. So when you run G91 then G1 S2 X10 F3000 what do you get in terms of X and Y movement (direction that is, not distance)? Also, what X and Y movement do you get when you run G91 followed by G1 S2 Y10 F3000?
