Latest firmware increased reprapdiscount full display update speed, but stutters prints

jmaeding

I read a lot of posts on several forums about how the reprapdiscount full graphic display causes print stuttering problems.

Most of them related to delta machines, but I do not have a delta, just regular prusa I3. What got me thinking was I noticed the latest repetier firmware shows the bed and hotend temperatures changing way more detail than using older firmware. All the other posts talk about a buffer running out and so on, and that happens when the screen updates cause too much activity.

Is there a way to tell the firmware to only update the lcd controller screen every 1/2 second or whatever the older firmware used?

Its not a minor issue, the printing is horrible with the latest firmware. I checked all my config.h settings to make sure they were the same where possible. I've been dealing with that file for years so am fairly familiar with it.

thanks

Repetier

Updating takes 0.1s and is done every second. I'm not aware of having changed that time, only display content may have changed.

The normal solution for cartesian printers is increasing buffer to 32 which hopefully gives you enough buffer to bridge 0.1s of print. 

At end of ui.cpp you see 1s for main menu and 800ms update frequency in submenus.

jmaeding

wow, thanks for the reply. I will try the 32 buffer, too easy.

jmaeding

I have not tried the buffer yet, but did look at the code and there were several additions since 0.91.

My files are dated 8-9-2014, and I am comparing with the latest stable 0.92.9.

Something important did change, as the lcd controller is updating way faster than before.

I started looking at Commands.cpp, as the ui.cpp files seemed to have not much changed of interest.

In Commands.cpp, there is a method named checkForPeriodicalActions, and it has an item EVENT_TIMER_100MS, then EVENT_TIMER_500MS in the if statement.

I'm a C# programmer, but can read C++, but those are not clear to me. They are events being fired, but what is their callback? What is subscribed to those events?

I'd like to figure this out as I think my controller is very common, and also the update increase is likely to cause all kinds of problems with other printers like deltas that are even heavier on processing.

What is the best place to be asking questions about the source code on this?

thanks

Repetier

All EVENT_ macros have no function by default. These are hooks to allow adding functions without changing the official code.

The ui.cpp function near end controls update of screen. I had copied it in my last answer but I see forum has eaten the code:-(

Anyhow it updates if a action was taken (key hit with UI_ACTION...), every 1000ms at top menu and 800ms in submenus. My stacker has also graphic display and no problems there with frequency. You could write a message using

Com::printFLN(PSTR("refresh"));

in refresh function. Then host should show in log times of refresh. Just make sure to write only when screen is updated and not in all slowAction calls.

jmaeding

I'm still wondering, why does 0.91 refresh like 5x slower than 0.92?

I honestly would not care much, but it is the prime suspect here and I have always been interested in how the firmware does things anyway. It sounds like you are saying there is no obvious reason.

Again, my setup is super generic, arduino mega with ramps 4.1, there must be a million out there like this.

thx

Repetier

I'm also wondering since it is updating every 1000ms and not 200ms for me. That is why I asked to add the log output to see how often 

void UIDisplay::refreshPage()

is really called. The code still says to do it every 1000ms or on a action. So if that is happening to you so often you might have a action always triggering. As you can program look into void UIDisplay::slowAction(bool allowMoves) and you see there is a flag uint8_t refresh = 0; that decides when a refresh is due. Only if set to 1 by one of the conditions it refreshes.

jmaeding

oh, you mean run using host and get feedback that way.

I have not run using host in a long time, I always run off sd card, I can try that.

I recall reading that changes things and the problem goes away, as the lcd controller is no longer in the way.

Is there any way to log activity to the sd card, if running just using lcd controller?

Repetier

No you can not log to sd card. We can only have one open file at the moment (memory).

Host does not change how firmware works, it just gets output so you know what is happening.

jmaeding

I see how the reporting works for host now, will try tonight.