Computation problem with RAMPS V1.4 and 128x64 lcd?

Marco67

I've used for a long time the classic display for "RAMPS V1.4 and Arduino Mega 2560" without ever having this problems.
I recently installed the "RepRapDiscout Full Graphic Smart Concoller 128x64" and see my video, at 0:48:



Roland, what do you think? Is a computation problem?
It's obvious during the infill print.
Same issue when print from SD and from USB.
Regards,

Marco

Repetier

Do you mean the pauses?

Well the display needs to be rendered 8 times( every time 1/8 of screen due to memory usage) on the avr and send over software spi, that takes 0.1s per screen update. Each click/press causes a update. So you can easily waste 100% CPU on display update and delta also needs many cpu% for movements especially on AVR. On due it is not as drastic but still needs a good time to update. So it is just a speed problem. So during print be carefull if you need to change something do it slow and it will not interrupt print as much. Beside this there is nothing you can do.

Marco67

Switch back to the other "low-res lcd", problems disappeared.
Now, i verified that, raising the print speed to 200% still experiencing slow issues like in my video (not good), also without touch the rotary switch, the LCD still requires too many resources to the cpu even if i don't touch anything!
So Roland what do you think to implement a sorta of "screensaver" to disable the LCD after "x seconds" during printing for decrease the cpu overcharging, and to reactivate it if you move the pot?

Repetier

I don't think a screensaver is what users want.

Your problem is more that you are using a delta printer. That means you want to put as many cpu power to quality and that is balancing on the edge with a avr processor. For deltas I highly recommend Arduino Due based boards, which are 10 times faster and have more ram for buffering. In your case simply do not increase speed too much so cpu is never near 100% and you get no pauses. You might want to reduce updates per second which is a quality factor but also increases cpu power a lot as each subsegment requires several sqrt operations which are inherently slow without math cpu. On AVR i had it 150-170 updates per second. On due I increased it to 600 and increased buffer/sub buffer and everything is working fine.

Marco67

I agree about Arduino Due, but why i can't get pause with the "Smartcontroller LCD" (low res) also at 200% printing speed?
So the problem is the processor computation with the "128x64 LCD" and delta printer, for this reason i ask to implement a sorta of "screensaver", you could leave the screen just a blinking cursor or an asterisk, indicating that the display is paused.
If the code doesn't have the burden of having to renew the LCD screen surely the processor remains freer to print, even on Arduino 2560 with "128x64 LCD", and also with the other display.
Why not try? ;-)

Repetier

Disable screen for compilation and you can see if it helps. Delta computations will still be main factor compared to display update, so there is always a speed you can not reach without getting pauses. You just have to accept that and print slower then that speed. Sure with display it is a bit lower then with and with graphic display much slower. But disabling screen is not a solution as that misses the point of having a display.

Marco67

Yeah, i don't mean "disable the display" from the code, i'm sure this can improve performance, i mean "the code must disable the display when not used".
During printing i don't look at the display for hours... ;-)
Cellular phone use this trick to save the battery, i'm sure Repetier can use this for Arduino Uno boards and delta printer...

Repetier

Yes, but when you look you like to see the print status. I often use this as display is always on and new versions with server even show print progress/eta whcih I like to see from time to time. That is what I mean with not generally wanted.