Delta plus Graphical LCD are pushing Mega2560 limits

[clefranc]

I'm trying to use Marlin with REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER hooked to a Rumba board. But I constantly get stutterings.

Before, the printer was using Repetier firmware, no problem whatsoever. But I wish to use Marlin.

I then removed (undefined) the graphic controller code in Configuration.h. No stuttering or stalling, print like a charm.

Looking at the LCD, I then noticed that there is a stall each time the graphic or data are updated.

So, do I have a faulty graphic controller (works great with Repetier) or is it a bug in Marlin firmware?

[clefranc]

Same thing happens when printing from the SD card.

[clefranc]

I've swapped the graphic controller for a REPRAP_DISCOUNT_SMART_CONTROLLER.

There is no lags or stutterings, but as usual, the LCD flashes when Repetier-Host send ETE. It does the same thing on my Prusa i3, with a RAMPS 1.4.

Can someone confirm this issue?

[thinkyhead]

So, does it stutter every second or so, whenever the graphical LCD updates? Do you see stuttering at any other points between screen updates? There have been some recent changes to the graphical LCD code, so perhaps you can grab an earlier version of Marlin (say, 14 days ago) and test that to see if the issue existed before.

[clefranc]

I only see lags when the LCD is updated, some updates doesn't produce a lag, but the majority do. I don't think it stutter without a LCD update.

I've tried the same LCD with a RAMPS1.4 board, same firmware, no problem whatsoever.

I suspect a pin conflict, needs more work...

[thinkyhead]

Do the pins in pins_RUMBA.h look ok to you? This was recently updated.

[clefranc]

@thinkyhead Yes, the pins definition look good, downloaded many config from RUMBA users, and the pins are identical. I want to rules out a firmware issue, but the same hardware runs fine on Repetier.

I think I found something interesting: https://groups.google.com/forum/#!topic/deltabot/bTA4JTrfmfA

This seems to be a winning combination of hardware: ATMEGA2650 + DELTA + REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER

The delta calculations take too much time on the ATMEGA, it can't keep updating the graphic controller at the same time.

So, the final answer? Use a smaller graphic controller? Redo the delta codes? Upgrade to a "real" board?

[thinkyhead]

@clefranc I wonder if we can't cleverly optimize the delta calculations somehow… or optimize the graphical display update….

[thinkyhead]

@clefranc Does the suggested workaround of reducing the value of DELTA_SEGMENTS_PER_SECOND (down to ~120) get rid of the symptom?

[clefranc]

Almost 99.9% gone!

[thinkyhead]

Yeah, sounds like the delta kinematics plus the graphical lcd together are pushing the limit on how much time is left to execute interrupt code. The only thing we can do in software is to try to optimize the code for these features as much as possible.

[Wurstnase]

A Delta itself can easily reach the limit of the Mega. A full-graphic and a cartesian also. I don't think that there is much to optimize. Less a bug, more a physical limit.

[thinkyhead]

We might want to include some documentation about these limitations in the code, perhaps above the DELTA_SEGMENTS_PER_SECOND declaration, or maybe the REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER declaration.

"We're gonna need a bigger board…."

[alexborro]

I think Graphic LCD are not that responsive even in cartesians bots. I don't know if there is any room for optimization in the routine. Em 31/01/2015 01:13, "Scott Lahteine" notifications@github.com escreveu:

We might want to include some documentation about these limitations in the code, perhaps above the DELTA_SEGMENTS_PER_SECOND declaration, or maybe the REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER declaration.

"We're gonna need a bigger board…."

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1404#issuecomment-72302029 .

[thinkyhead]

Darn, one always hopes for some magic key....

[Natealus]

Well I wouldn't give up so quickly. You'd be amazed at the differences software can make on the same hardware. My old computer was 13 year old by the time I retired it and took I it from XP to Vista to 7 to 8.1. Each and every time there was a largely noticeable difference from the upgrade in speed. Exact same hardware...yet somehow almost twice as fast. Because in each iteration they keep finding ways to improve overall response, make certain things run in parallel, better and more efficient drivers, and they improve the way the code works.

I work both software and hardware issues on computers and 9 times out of 10...what people think is a hardware problem is simply a software issue. Hardware is cool...every couple of weeks or month there's a newer stronger better board available. We could upgrade till we're blue in the face and still have the same issue. But Software is where the real advances are made and where the large majority of fixes come from.

I believe in you guys. :)

[thinkyhead]

"To make code go faster, make it do less." –some smart geek somewhere.

[Natealus]

Yeah that was one thought I was having was that we could add in defines to shut off animations and additional graphics and perhaps make a text only setup for graphics LCDs mixed with deltas. Or like someone else was saying if they were having stutters on a carrage style too. I thought when I was getting the Azteeg X3 Pro that it was a higher end board but I guess that's mostly connectivity not in processing power.

Another interesting point was brought up in the linked post that some I2C libraries have some issues that can cause these sort of stalls if the library isn't handling its interrupts appropriately. I've heard that some were revised and fixed for this issue but they take some coding knowhow to integrate.

[thinkyhead]

Keep this (closed) issue in mind. Will revisit.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.