Status poll of Graphical LCDs and Printing Performance

[Natealus]

I was just curious how other people's experience are with the LCD screens and printer performance?

I've had my delta printer running at 20-80mm/s and 165 delta segments per second very smoothly. But with my Viki 2 Graphics LCD enabled, I have to drop the segments all the way to 38 to achieve smooth printing again.

What are your experiences?

[daid]

I'm not surprised. The used LCD libraries are made for functionality, not for real-time behavior. This is why I opted for a home-grown LCD library for the Ultimaker2 instead of a "standard" Arduino LCD library. (The Ultimaker2 uses a 128x64 I2C LCD display)

[clefranc]

@Natealus Same thing here with a REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER. I was at 120 segments a few weeks ago, I'm now way under 100 now.

[Natealus]

So does it affect Deltas only or does it affect other printer types too? What type is the Ultimaker2?

[thinkyhead]

@Natealus Ultimaker2 is a very nice box cartesian.

@clefranc Are you able to fit the code on your board if you compile with -O3 as the optimization level? I would be curious whether this makes any noticeable difference in performance.

[Natealus]

@thinkyhead The Azteeg X3 Pro board I have is one of those Mega2560 256k boards I think it could spare more space for a possible upgrade of performance...where is this accomplished?

So with an Ultimaker2 box cartesian like that does it use processor power with kinematics as well?

[thinkyhead]

To change the optimization you need to find the platform.txt file that your Arduino app is using. http://www.instructables.com/id/Arduino-IDE-16x-compiler-optimisations-faster-code/?lang=pt&ALLSTEPS

[thinkyhead]

@Natealus Cartesian is the most "straightforward" and requires no kinematic transform. Delta and SCARA require some trigonometry, and those math functions are expensive.

[Natealus]

Thanks a bunch @thinkyhead I'm going to study that article. I've also merged in your code that hasn't merged in the main dev yet and all compile well. Going to give it a go. :)

[clefranc]

@thinkyhead -Os : 120918 bytes -O3 : 175908 bytes There is a very (very) small improvement with -O3, not enough to call it a viable solution.

[roboprint]

Same issue with REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER and Delta-printer.

Maybe it possible to implement something like "screen saver" to disable screen refresh after print start until keypress (rotary encoder rotate/click) ?

[clefranc]

@roboprint Nice idea. Like a new command to disable the refresh MXXX S0|S1 Or something like a long press to disable the refresh (with a long beep), and another long press to enable (short beep).

[roboprint]

@clefranc maybe just specify screen refresh rate in seconds? Mxxx S0 - disables, Mxxx Syyy = sets refresh rate to yyy seconds? Long keypess is also can be used.

[clefranc]

@roboprint Yes! @thinkyhead What do you think about it?

[AnHardt]

@roboprint Just try playing with: https://github.com/MarlinFirmware/Marlin/blob/Development/Marlin/ultralcd.cpp#L305

[thinkyhead]

Less screen refresh is always a good thing. It might also be possible to just draw less on the screen on each update. Instead of updating all the items on the display, just update one item per update-session. This will make the update routine itself block for less time.

[AnHardt]

@thinkyhead I'll work on the extruder-bed-fan graphic today. here we have a update of a lot of white space. Splitting into 4 separate graphics can improve that.

[Natealus]

I must say going from default Os optimization to O3 I was able to turn my delta segments per sec up from 38 to 60...so I can say there is an improvement given the same code. :+1: But compared to my previous smooth prints at 165 the LCD sure does eat a wallop of processor lol.

[boelle]

is this a bug or?

[Natealus]

Well thinkyhead referenced an article up above about the platform.txt – to change the compiling optimization routine that Arduino IDE uses. Two main concerns are sketch size and execution speed. Seeing as I have a 256k Mega 2560, I was able to sacrifice space to gain performance. My sketch is 202,112 bytes big but I still have about 50k of free space. Vs it being about 175K ish...(I don't exactly remember). The article describes a simple test he did to prove his theory.

[boelle]

it just wanted to put a label on it, but it take i can put "not a bug" on this one

[roboprint]

Yes, it is bug (full graphic display refresh causing freeze during refresh on delta printers). But this can be 'fixed' by implementing 'screen saver' or 'change screen refresh rate' features.

[Natealus]

Yeah I think thinkyhead has been working really hard on temp and bed leveling issues the last few days but I think him and a few people intend to test a few ways to lighten or circumvent the delay of the graphics lcd system.

[thinkyhead]

@boelle I think we might consider this a "feature request." Namely, that the graphical display not interfere with Delta printing (especially), as both require extra computing resources. There are workarounds, such as reducing delta segments per second or using a faster board, but I'm sure we can shave cycles from all the display updates.

[Natealus]

Could help all around but yeah I think this issue is perhaps a ...mid priority in comparison to more important issues. You've been making fixes daily on bed leveling Scott that's awesome and I'm glad you're working hard on it. :)

[AnHardt]

Saved some cycles today in the dogm-code. Preview on https://github.com/AnHardt/Marlin/tree/StatusSpeedDogm. To much features for a PR now - i guess.

[Natealus]

Badass I look forward to giving it a try :)

[AnHardt]

Heading for the 'Number to string conversion's again. There are lots if modulo divisions. Every % consists of a division a multiplication and a subtraction on the Atmels. I know there are algorithms to avoid this and save about 50% of the cycles. So this time i'm looking for pure speed - not space.

[alexborro]

Just for your information, the Repetier firmware runs Graphic LCD on deltas with no hiccups at all, on the same hardware. So yes, there is a way to do that.

Cheers.

Alex. Em 01/04/2015 23:06, "AnHardt" notifications@github.com escreveu:

Heading for the 'Number to string conversion's again. There are lots if modulo divisions. Every % consists of a division a multiplication and a subtraction on the Atmels. I know there are algorithms to avoid this and save about 50% of the cycles. So this time i'm looking for pure speed - not space.

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

[Natealus]

Yeah I would still classify it as a performance-hindering bug...we've just been focusing on getting leveling and temps and homing working as intended. I had to reduce delta segments per second from 165 to 38...just to enable the LCD. So there is some inefficiencies or inappropriate interrupting happening that's causing it to delay so much more than Repetier's Graphical LCD system. Yea these 8-bit sub 30mhz aren't that powerful so every bit of efficiency helps lol.

[AnHardt]

@alexborro Had a look into Repetier today. The loop for writing the buffer to the display is quite the same as in Marlin. The graphics they copy onto the info-screen are much smaller than in Marlin. This is nearly ready for a PR. They use a modulo free number to string conversion. That's what i'm working on.

[alexborro]

Thanks @AnHardt ,

I was talking yesterday with @thinkyhead on skype about this issue. I guess we are updating all the GLCD buffer all the time and that makes no sense.. We could update just the pixels that have changed.

And getting rid of modulo operations is really good as well.

Cheers.

Alex;

[thinkyhead]

:+1:

[Natealus]

:+1: :+1:

[AnHardt]

A bit a improvement is done. See #1817. I guess that's factor 4 or better.

[alexborro]

Humm, nice.. I think the optimal idea would be calling the lcd refresh function from an interruption executed at about 1hz. There is no reason for a faster update. And the buttons/scroller function must be called faster to make the display responsive... That way the LCD will be refreshed faster when navigating through menus, but at a lower rate when at info screen... That will be awesome for Delta bots.

2015-04-04 13:11 GMT-03:00 AnHardt notifications@github.com:

A bit a improvement is done. See #1817 https://github.com/MarlinFirmware/Marlin/pull/1817. I guess that's factor 4 or better.

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

"Não é o mais forte da espécie que sobrevive, nem o mais inteligente. É aquele que se adapta melhor as mudanças" ( Charles Darwin )

Alex Borro

[thinkyhead]

@alexborro I'm still very interested in slicing up the updates into smaller segments. No matter how often you do the routine, if the routine still takes a long time to do the update, then there will be more chance of stuttering in movement. Ideally, it would be nice to able to update 1/10th of the screen at 10Hz. The main cost may be in setup for doing the update, so pre-calculation may help here too. I kind of like the idea of splitting up the main display update routine, so it counts up from 0 to however many things it normally draws. On each call of the draw routine, only draw a single item, then update the counter. If it clears the screen before drawing each frame, we'd have to get rid of that…

[alexborro]

@thinkyhead Something I'm concerned about is the buttons reading routine. It should have high priority in order to have a responsive LCD.

No matter when we do the LCD refresh, we should poll the buttons quite fast (in a separate routine from refresh one).. And as soon as a button is pressed, update the LCD immediately.

Bear in mind I know almost nothing about the LCD and buttons polling routines - I don't know how it currently works.

Cheers.

Alex.

[AnHardt]

The 10Hz is already there in 'lcd_status_update_delay'-loop. Should not be a big problem to path it down to lcd_implementation_status_screen(). Partial updates there are no problem. Give me some days.

There is also a possibility to split the update from the buffer to the display, but this makes things really uncomfortable. But that's only writing 1K of data written by software SPI - compared to the divisions this is close to nothing.

Button - encoder updates will have the same speed as before.

[AnHardt]

If we want the 10 Hz splitted update #1817 makes no sense. Or, maybe, only for a week.

[thinkyhead]

It definitely bears some experimentation. :zap:

[AnHardt]

1823 gave more insight to the problem.

Will make the 10 Hz update a bit more complicated. We'll see.

[alexborro]

Nice job @AnHardt !!

My main concern on speed is not during menus navigation.. In this case it should be refresh as soon as a button is pressed. Why not refresh all the buffer at once instead of splitting in two sections ? This 2-part refresh causes an ugly aspect to the LCD during navigation..

We should stop fast refresh during print and LCD on info screen... that is 99.99% of the time and causes a huge performance degradation on Delta bots.

Cheers.

Alex.

[AnHardt]

Got the 10Hz precalculation of the strings to work. Preview: https://github.com/AnHardt/Marlin/tree/viki A bit untidy for now - but works nice. Also the work to do during the update is greatly reduced by using 'stripes'.

[thinkyhead]

@AnHardt You are officially the display guru. :bow:

[AnHardt]

Here i have a single-liner to improve the performance of the viki displays: Change https://github.com/MarlinFirmware/Marlin/blob/Development/Marlin/dogm_lcd_implementation.h#L128

to: U8GLIB_NHD_C12864_2X u8g(DOGLCD_CS, DOGLCD_A0);

This requires u8glib v1.13 or newer. The new device will only need 4 loops to draw the display, instead of 8 loops before.

I'd really like to know if that improves the number of segments you can print.

[Natealus]

I've been out of the loop for the last month and a half but I have some free time from work now so I'll probably be running more testing having to do with the segments with and without display to verify. Also will be trying to document the delta auto bed leveling. :)

[thinkyhead]

@Natealus When you feel like testing homing / leveling, give this branch a run and post the output: https://github.com/thinkyhead/Marlin/tree/debug_G29

[Natealus]

Well congrats you guys did figure out the bug where in between the probing points, it is moving straight and not moving down in a bowl fashion. Kudos there. :)

Unfortunately now it seems like it is not taking the probe switch into action when it is triggered to Stop moving down and not crush my probe rig. I've tried adjusting between and before probing heights, manual z height, z-probe extruder Z offset (M851) and while the initial height changes...they all still go down too far and flex the probe rig before pulling back up to move to the next point.

I have checked to see if the probe switch is still working to the firmware and it is. Tested multiple times. I also noticed that Z-probe and Z-min register at the same time if I enable min endstops...and that Z-probe still works if I disable them too but the problem still seems to be the same. Here is a paste bin of a few probes I let it do before I thought I should stop before it busts.

http://pastebin.com/qQB12y5C

[Natealus]

Scratch that after fiddling with it some more in different positions I think it is a wiring issue. Not sure why it chooses now to start malfunctioning but I'm trying to fix it. No success so far I need a brake from tedious wiring crap.

[thinkyhead]

@Natealus Eek, you had me worried there, that maybe it was doing the fast probe, then trying to do a slow probe without lifting up first... or something like that. Please keep me posted as you fix the wiring.