CoreXY printer slowing down near 0 speed

I am finalizing a big volume CoreXY printer and now when trying to get it move right I find a weird problem with many different hardware combinations. The printer makes right moves but in a horribly weird speed. First seconds the printing looks nice (reasonable speed, a little bit of unwanted very short "pausing" on the way) and then the thing freezes almost completely - it barely moves. Suddenly after some seconds going real snail slow, it gets up the speed for a second or so, just to get veeeryyy sloooooww again. I have been trying to change the buffer settings and god knows what, but this thing doesn't even change, everything else has been changing around the problem. I have been mixing 2 controllerboards (3Drag/K8200 and Mega+Ramps 1.4) and 2 firmwares (Repetier fw and Marlin) with a zillion of configurations and the same thing keeps on ruining my days! I can't understand how this can happen with completely different hardwares and firmwares

In my other printer (mash up from K8200 and Replicator) I haven't had any problems what so ever. I use Cura to slice the objects and have tried if the file was faulty, but nope. I even suspected the memory card when running out of ideas...

If somebody could tell me what I have to do... Thanks!

Edited 2 time(s). Last edit at 03/26/2015 06:49AM by PropellerHat.

Could it be a cooling problem of the electronics?

Hi.

If it helps, I've had motion troubles with 1/32 stepping on Ramps/Marlin. 1/16 seems ok.

It showed itself most when coming to the end of travel where it seemed one motor would stop before the other with a nasty clonk.

It is tricky to diagnose travel problems with coreXY as both motors are usually moving and its impossible to isolate each drive to check for mechanical issues.
Maybe try setting it to cartesian, non CoreXY in firmware which will give diagonal travel (watch those end stops!) and check that the X and Y moves react the same.

-a

Try to run the following G code:

G28
G1 x0 y0 z10 f3000
G1 x100 F3000
G1 x0 F3000
G1 x100 F3000
G1 x0 f3000
G1 x100 F3000
G1 x0 f3000
G1 x100 F3000
G1 x0 f3000
G1 x100 F3000
G1 x0 f3000
G1 x100 F3000
G1 x0 f3000
G1 x100 F3000
G1 x0 f3000
G1 x100 F3000
G1 x0 f3000
G1 x100 F3000
G1 x0 f3000


This should move from x0 to x100 and back a couple of times using both motors to make the move. Does it act strange as you say?

If yes, try:

G28
G1 x0 y0 z10 F3000
G1 x100 y100 F3000
G1 x0 y0 F3000
G1 x100 y100 F3000
G1 x0 y0 F3000
G1 x100 y100 F3000
G1 x0 y0 F3000
G1 x100 y100 F3000
G1 x0 y0 F3000

Now this move pattern should only take one motor. It moves across along the diagonal. Does it still do it?

No matter what, try now:

G28
G1 x100 y0 z10 F3000
G1 x0 y100 F3000
G1 x100 y0 z10 F3000
G1 x0 y100 F3000
G1 x100 y0 z10 F3000
G1 x0 y100 F3000
G1 x100 y0 z10 F3000
G1 x0 y100 F3000
G1 x100 y0 z10 F3000
G1 x0 y100 F3000


What is the result of those 3 moves?

Are you printing over the USB port? If so, this is a known issue when using Mega/RAMPS electronics (or anything else that has a slow serial-over-USB connection with no flow control) and the gcode you are printing contains sequences of lots of short moves - although to be fair, the slow down you describe does sound worse than usual. Try printing from SD card instead, or use better controller electronics with a native USB port or Ethernet.

---

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].

No. The problem appears as if it would be a error in the print file, but I just don't get why then the same file runs smoothly on my other printer. The weird behaviour is always the same, exactly same tiny pauses first and then in the same coordinates the slow motion.

LarsK, It looks all cool. Straight G-commands make no problems. It's only with printing. Now I run Marlin. on 3Drag controller, SD all the time. Even when printing the straight lines (0 or 90deg) come nicely, but anything angled or diagonal will cause the freezing. Electronics run cool and the problem is identical every time. I have been swapping and crossing electronics and firmwares and even slicers to hunt this down. When I print the 12-faceted pyramid in 50mm diameter, the problems start after a couple of first rounds on the first layer, when its a 300mm pyramid the freezing occurs on the first 1/4 of the first outline. Could it be the buffer somehow? I set it on 32, after trying 16 and 64 (too high).

Edited 3 time(s). Last edit at 03/26/2015 09:17AM by PropellerHat.

What speeds do the gcodes in your files use? I hear that Marlin has problems if you ask for more than a certain speed on a CoreXY printer. AFAIR for one particular user the speed was 150mm/sec, but the speed at which the problem starts on your printer may be different, depending on the steps/mm factor.

---

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].

I have it on 150mm/s, but the actual speed looks slower. My XY steps/mm are 319. I try now to lower it.

Edited 1 time(s). Last edit at 03/26/2015 09:23AM by PropellerHat.

I lowered the print speed in the file into 50mm/s. It looked better for a full round of an edge, before freezing on the second round. Anyway better. The weird thing is also that infact the 150mm/s never was that fast, I didn't see difference in the real printing speed between 150 and 50mm/s. When trying 20mm/s the freezing happens ealier than with 50mm/s.

Edited 1 time(s). Last edit at 03/26/2015 09:31AM by PropellerHat.

Quote
PropellerHat
I have it on 150mm/s, but the actual speed looks slower. My XY steps/mm are 319. I try now to lower it.

Here [forums.reprap.org] is the thread that talks about the limitation in Marlin. The last post in it mentions the limit as being around 20000 steps/second. So at 319 steps/mm, you may have to reduce the speed to around 60mm/sec, perhaps even lower.

---

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].

Heeeyyyy I dropped the half stepping into more coarse as Alan suggested, so it started to look alot better. Apparently this amount of steps and speed really makes a difference even though I am running Longs's beefy drivers.

I think I can carry on from here with fine tuning it into perfect.

Thank you all for fast replies

Hopefully you don't hear from me for a while

Edited 1 time(s). Last edit at 03/26/2015 09:46AM by PropellerHat.

Ok, back on the same thing. The rectangular ones and angled straight stuff comes nicely now, but circular shapes still cause that intermitting moving. There is no freezing (at least in the first minutes that I have been dry-running) but these micro stops cause a lot of shaking so I guess it's totally not acceptable. I have been cutting the resolution of steppers as low as 400 microsteps that requires a total of 10 steps per mm from the controller electronics so it should not be too high. The speeds have also been very humble 50mm/s.

The limit with Marlin is at ~40.000 steps/s. But with a CoreXY the motors reached sqrt(2) more steps than a normal cartesian printer.
So with GT2 pulleys with 20 tooth and 1/32 µsteps the limit should be at ~176mm/s.

Also reduce the buffer to 16. When the buffer is not full, the printer will slow down.

Edited 1 time(s). Last edit at 03/26/2015 11:24AM by Wurstnase.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Hmmm...

Even on 20mm/s speed the circular shapes cause intermitting.

Here are my buffer settings:

#ifdef SDSUPPORT
#define BLOCK_BUFFER_SIZE 16 // SD,LCD,Buttons take more memory, block buffer needs to be smaller
#else
#define BLOCK_BUFFER_SIZE 32 // maximize block buffer
#endif


//The ASCII buffer for receiving from the serial:
#define MAX_CMD_SIZE 96
#define BUFSIZE 4

How should they be?

Edited 1 time(s). Last edit at 03/26/2015 11:55AM by PropellerHat.

Hello,

Is it correct that you have tried this with two completely different boards? So that the only common electronic parts for the two are the motors, extruder, hotend and endstops?
Is it correct that you have tried with Ramps and both running that with Marlin and Repetier?
Is it correct that the G-code that Cura outputs for you, you have tried in your working printer and it prints correct, while it does not work on your CoreXY?
Is it correct that you have tried printing both from SD and USB?

Are you using the same power supply for all your tests?
Do you see any change in how often the problems occurs depending if the hotend is heating or not?
Do you have an oscilloscope available?
Can you record a movie of the issue and upload? A simple phone camera recording will be enough.

Can you upload the stl-file or gcode? Maybe the resolution of this file is much to high?!?

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

LarsK, Yes to all of your suggestions. I only tried shortly printing via USB and it started to do the same. I am printing G-codes. Yesterday I managed to get things better, but circular motions are still intermitted. Powersupply is the same but since the straight moves (diagonal or not) work fine, I would not suspect that to cause the intermitting in the circular moves. I have not been heating the hot end, infact it is off the printer. Te G-codes I have been dryrunning are set to be 0 temp. I noticed a huge gain in overall smoothness and speed after I dropped the steps/mm for the extruder. The extruder is also intermitting in the same phase as the motions of the gantry. I don't have an oscilloscope but I started to look for an used one yesterday. I try to upload a video of the problem somewhere, though I really hate how you can't nowadays do it without pain in the ass connections to Google or something else. The resolution issue has something to do with this, for sure. It's the overall counting for the electronics that has to be made lighter, I suppose. I just don't know what setting is wrong, or should I get some beefier controller for the machine because of the Corexy and the print size. Maybe they are a killer combo for normal consumer controllers? Can anyone name a controller able to do faster calculations? This has to be a fast machine, thats the point of it. I built it to handle serious speed and accelerations.

Edited 2 time(s). Last edit at 03/27/2015 05:51AM by PropellerHat.

Quote
PropellerHat
LarsK, Yes to all of your suggestions. I only tried shortly printing via USB and it started to do the same. I am printing G-codes. Yesterday I managed to get things better, but circular motions are still intermitted. Powersupply is the same but since the straight moves (diagonal or not) work fine, I would not suspect that to cause the intermitting in the circular moves. I have not been heating the hot end, infact it is off the printer. Te G-codes I have been dryrunning are set to be 0 temp. I noticed a huge gain in overall smoothness and speed after I dropped the steps/mm for the extruder. The extruder is also intermitting in the same phase as the motions of the gantry. I don't have an oscilloscope but I started to look for an used one yesterday. I try to upload a video of the problem somewhere, though I really hate how you can't nowadays do it without pain in the ass connections to Google or something else. The resolution issue has something to do with this, for sure. It's the overall counting for the electronics that has to be made lighter, I suppose. I just don't know what setting is wrong, or should I get some beefier controller for the machine because of the Corexy and the print size. Maybe they are a killer combo for normal consumer controllers? Can anyone name a controller able to do faster calculations? This has to be a fast machine, thats the point of it. I built it to handle serious speed and accelerations.

Duet or Smoothieboard

RADDS with Arduino Due.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

For what it's worth, I have been printing for a few months on my P3Steel's at around 45mm/s with 1/32 microstepping for the X and Y axis (DRV8825 on RAMPS 1.4, Marlin, 12864 Graphics LCD) and never had the least problem.

If you are having problems printing at half that speed on a CoreXY, I can't see how that could be caused by lack of processing speed in the Arduino.

AndrewBCN, do you live here in BCN? Come to check my project here in Macus I don't understand it neither. The controllerboard is somehow overwhelmed or something, surely because of a wrong setting in somewhere. I aim at least into 150mm/s printing speed.

I will check those above mentioned boards right away...

Edited 1 time(s). Last edit at 03/27/2015 07:08AM by PropellerHat.

Well, I dropped the resolution of the piece in STL exporting from Rhino. The printer goes real smooth now, especially if the curvature is not too tight. Maybe it's just that I have to optimize the pieces when exporting now more carefully than with the FrankenReplicator.