Kossel stuttering (not the steppers, not the g-code, and "not" starving)

Hi, first of all I built a big kossel after using, for more than a year now, my MendelMax.
I tried Jcrocholl's version of Marlin first, but was not satisfied with the configuration process for deltas. And I decided to give a try to Repetier (which now runs on my MendelMax too, perfectly)

But, I have this annoying issue that causes the print head to slow down on complex parts, as the title says, it's not a stepper problem (both driver and motors are all cold or at most warm), and it's not in the g-code, even if this one is 24MB for a supposed 3 hours print. I'm also printing from the SD Card, so data starving is not the issue (but that's the one i'm the least sure about).

Here is a brief video to show my problem while printing the T-rex skull from thingiverse : Video
The head slows down on some portions resulting in blobs and horribly bad quality prints...
I'm thinking about a processing starvation (lack of power from the ATMega2560), because as soon as I navigate through the menu on the Full graphic controller, the nozzle slows down (and almost stops, you can hear it in the video...).
I already tried reducing the segments/s parameter of repetier, but without improvements (even going as low as 70seg/s, that's the weird part, cause it should cause less calculation).

Please, I think I need help on this one...

I would think that changing the number of segments reduces how many there are, but they then must be larger. So the total number of steps to be generated hasn't changed and the processor is doing the same amount of work. The fact that it slows down when the display is used says that the processor fails to keep up with generating steps because it is busy talking to the display. So turn off the display if you can and see if the motion improves. In the old days the stepper code would have run in the interrupt service routine so it could never fall behind as it would be guaranteed processor time and the display would get real slow while motion was happening. I don't know how the code is done these days but it is clear that you can steal processing time from the step generation.

You're *really* pushing that poor mega2560 running with a speed multiplier of 201 on a Delta with a full graphics LCD!!!!!

Quote
vreihen
You're *really* pushing that poor mega2560 running with a speed multiplier of 201 on a Delta with a full graphics LCD!!!!!

Hehe, yes, but don't worry I know it's making it worse, i tried to slow down but it only improves when reaching like 20% or 30%, it was for the needs of the video in order to see it better ^^

Quote
garyhlucas
...

Thank you for your answer.
Yes it does appear the display has the same priority as the motion... I'll give a try to disabling the graphic LCD, and if it doesn't solve even partially, i'll configure Marlin to see if it is written more smartly.
Do you know if there is any better version of marlin than Jcrocholl's one?

And last question, if I can't solve the problem (I doubt it, there must be a way!) is there any board out there that has more processing power?

Marlin's handling of the GLCD is worse, according to other threads here in the past two weeks and the discussion thread in the Repetier section last fall documenting the LCD-12864 support development. Someone else removed the LCD support from Marlin last week to fix their stuttering problem.

Many of the key members of the Google Deltabot group have moved on to 32-bit board options. Unfortunately, it requires changing to different firmware. RADDS (and the no-longer-supported RAMPS-FD) use an Arduino Due processor, and only Repetier is available. Smoothieboard and the Azteeg X5 Mini run Smoothieware, which is growing a following among Delta users and is what I consider to be the next generation of controllers. There has been recent interest in the BeagleBoneBlack and BeBoPr cape, but I don't know much about it in terms of firmware options besides not believing Repetier or Marlin run on it.

I personally bought the Azteeg X5 Mini, and it took only a few minutes to copy the firmware and config file to SD card and boot it up. I still haven't hooked it up to the printer yet, but have been impressed with the simplicity of configuring it and like the feature where it presents the on-board SD card as a USB flash drive over the USB cable (in addition to the traditional serial TTY interface). From my computer, I can save a G-Code file directly to the printer's SD card in a few seconds from Cura, and run the job from any host software.....

Quote
vreihen
Marlin's handling of the GLCD is worse, according to other threads here .......... I can save a G-Code file directly to the printer's SD card in a few seconds from Cura, and run the job from any host software.....

Well, it looks gorgeous, I'm gonna do some research on it, thanks a lot for the information!

Hi everyone, and thank you for your advices!

So after a bit or research, I was very tempted with the Azteeg X5, but it is out of stock since ~2 weeks (I contacted the seller but no replies).
In the mean time (waiting for a response) I convinced myself to try again Marlin.

Marlin solved the issue, well... It still slows down on complex parts, but there in no longer any sort of stutter (the head moves slower, that's it, but at an almost constant speed). So I can't see any blob on the print now, success! ^^

Thanks again