CoreXY Binding: Mechanical or Firmware Issue?

Lately I've been testing high speed printing with my CoreXY printer (running Marlin firmware), and have been running into an issue with movements faster than ~250mm/s. At higher speeds, when decelerating, the gantry seems to "stick" for a very short time, causing a jerk in the movement. Usually this only happens during travel moves (since my travel speeds are the highest) and causes no noticeable problems. However, occassionally, the binding causes the steppers to skip, causing layer shifts and ruining the print.

Changing the acceleration seems to have no effect on the binding issue; I've tried everything from 500mm/s^2 to 4000mm/s^2 (the firmware limit I set). Also, the problem doesn't seem to be localized to one axis, leading me to think that the smooth rods and bearings aren't to blame. Running a few x-axis and y-axis moves with low acceleration, it seems that the binding occurs when passing a certain speed during deceleration. Changing stepper currents both ways doesn't change anything either.

Here's a video of the problem. It's kind of hard to see the binding at normal speeds in the video, so I've also taken 120fps high speed shots with my phone which shows the issue more clearly.

Other people have reported this too, it seems there is a bug in Marlin that limits the speed of a CoreXY machine. AFAIR last time this was reported when exceeding 150mm/sec, but it probably depends on your steps/mm. I suggest you try different CoreXY firmware, unless someone else here has a version of Marlin with a fix for it.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Thanks, I'll flash my printer with Repetier firmware and see if the problem goes away. If it is an issue with Marlin, do you know whether there's going to be a fix for it anytime soon?

Which Marlin Version do you use? I've never seen this issue. Not with my RAMPS and also not with my Due/RADDS.

I run my CoreXY with >250mm/s without issues.

Does this also happen when you drive diagonal with half speed?

Do you use DRV8825? If I see your setup correctly in that video you have GT2 with 16 teeth pulleys.
So when you try to speed up to 280mm/s you reach the limit of the AVR with 40.000 steps/s. (280*200/sqrt(2) ~ 40kHz) Which is probably to much if you have also a display etc.

Edited 2 time(s). Last edit at 08/06/2015 09:06AM by Wurstnase.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
dc42
Other people have reported this too, it seems there is a bug in Marlin that limits the speed of a CoreXY machine.

Do you have some links?

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase

Quote
dc42
Other people have reported this too, it seems there is a bug in Marlin that limits the speed of a CoreXY machine.

Do you have some links?

Here [forums.reprap.org] is one example.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Yeah, this was march. Since march was a lot of work done in Marlin btw.

Also there are no information about steprates etc.

CoreXY on Marlin works now better than in most other firmwares. But on AVR the limit is max. 40kHz.

If we have 1/32µsteps and a 16 teeth GT2 pulley we set up 200 steps/mm.

Pure X or Y moves needs then 141 steps/mm or the maximum speed is ~282mm/s (you should have less than 40kHz). Diagonal move can only move with 141mm/s in this setup. But this is no bug.

I've used Marlin on my Due with 640 steps/mm and reached 300mm/s on diagnal moves before I lost steps because my mechanic are too weak. Never saw such issues.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

I'm running 20 tooth GT2 pulleys and Allegro drivers set to 1/16 microstepping. It seems like pure x or y moves max out at exactly 250mm/s before skipping, while pure diagonal moves wont skip at any entered feedrate due to the firmware speed limits.

Ok, and which version exactly did you download?

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

I'm running Marlin 1.0.2. After doing some test prints, it seems that even with travel speeds of 180mm/s I still get occasional freezing from the steppers.

1.0.2 is pretty old. We are currently hard working for the next release. But you could test the latest development-version. [github.com]

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

I flashed my printer with the latest Marlin dev firmware, but the problem seems exactly the same as before. I'll try Repetier firmware to see if it's compatible with higher speeds.

Edited 1 time(s). Last edit at 08/07/2015 11:14AM by AlexY.

OK, so it seems that Repetier firmware doesn't have the issues with high steprates that Marlin has, so I guess I'll stick with it for now.

Can you please upload your config from Marlin. I would like to test it out.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Here's the configuration.h file.

You should use a newer version of Marlin. This one is old and the CoreXY-part got a lot of rework.
Please try the development-version and see if the problem exist anymore.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

I think I uploaded my old Marlin config by mistake; here's the new one. When I tried the development version, the problem didn't go away, however.

Edited 1 time(s). Last edit at 08/22/2015 12:37AM by AlexY.

Ok, just an idea.

Open your stepper.cpp. At line 752 should stay "// If current block is finished, reset pointer".
Just before that line please copy this one:

OCR1A = (OCR1A < (TCNT1 +16)) ? (TCNT1 + 16) : OCR1A;

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

That seems to have fixed it! I'll test the patched Marlin out a bit more to make sure the problem's actually gone.

The stepper problem seems fixed, but the dev Marlin is tripping the thermal runaway far too easily. Is there any way around this problem without disabling the protection outright?

Quote
AlexY
The stepper problem seems fixed, but the dev Marlin is tripping the thermal runaway far too easily. Is there any way around this problem without disabling the protection outright?

Great

You can play with the values in the config_adv.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
dev Marlin is tripping the thermal runaway far too easily

It might just be the default settings are too touchy. Are you able to adjust the thermal runaway parameters in Configuration_adv.h to a point where it behaves better? If so, please post them here or in an issue on the Marlin Github page.

Edited 1 time(s). Last edit at 09/03/2015 04:43AM by Thinkyhead.

---

|
| Lead Developer of Marlin Firmware
| Help support my work at Patreon and Elsewhere.
|

lol, I ended up being lazy and just disabling it rather than going into the advanced config.