Marlin 🚀 - Problems of MBL menu on RepRapDiscount Full Graphic Smart Controller and RepRapDiscount Smart Controller

What version/commit are you using?

epatel on 4 Apr 2016

I'm used RC5(RCBugFix) as of about GMT April 4, 22h in this video clip,
But newest RCBugFix as of GMT April 4, 12h produced same result.
And, these are my configs.
Configuration.txt
Configuration_adv.txt
These configs are made for only testing.
Because I've only delta printer, therefore I can't use MBL in the normal.

Version of the ArduinoIDE is 1.6.9 Hourly Build 2016/04/02 12:33,
Version of the U8glib is 1.18.0.

esenapaj on 4 Apr 2016

Additional infomation:
If I connect to the printer by Repetier-Host, it displays strange strings.
But I don't understand whether it's concerned with problems of LCD or not.
default

esenapaj on 4 Apr 2016

@epatel From the video seems that the LCD is redrawing every cycle, could it be ?

jbrazio on 4 Apr 2016

@esenapaj offtopic: your encoder "feels" to be reversed, you can now play with #define REVERSE_MENU_DIRECTION to get it right.

jbrazio on 4 Apr 2016

I'm grateful for your instruction.

esenapaj on 4 Apr 2016

Additional infomation 2:

If I test with RepRapDiscount Smart Controller (ASCII LCD), "Problem 1" doesn't occur, but "Problem 2" occurs.

esenapaj on 5 Apr 2016

it displays strange strings

That is now patched thanks to @jbrazio.

thinkyhead on 5 Apr 2016

So, the only problem then is that after a 60 second delay there's an automatic switch from the Homing XYZ display to Click to Begin? That is an interesting behavior. I will check to see that the appropriate flag is being set, in case it's missing there.

thinkyhead on 5 Apr 2016

Ok, so the only reason that the Homing XYZ screen should appear is that Bed Leveling was clicked (instead of Cancel), which starts the homing procedure. The only reason that it ever proceeds to the Click to Begin screen is because

(axis_known_position[X_AXIS] && axis_known_position[Y_AXIS] && axis_known_position[Z_AXIS])

So this implies that after a 60 second delay those flags are being set. That could be caused by buffer overflow or stack overflow, but during these MBL screens there isn't very much going on.

thinkyhead on 5 Apr 2016

the LCD is redrawing every cycle, could it be?

Normally it updates at 10Hz. But if the display memory is being changed at any time this can show up immediately, before a proper display update.

thinkyhead on 5 Apr 2016

An interim report:
I tested with latest RCBugFix, Strange strings on Repetier-Host is gone.
Problem 1 and 2 still occurs.

esenapaj on 5 Apr 2016

I just tested this with the latest RCBugFix (Apr-5-2016) the two bugs pictured in the video still exist. Also if you actually follow the on screen direction to Click to Begin it appears to jump right to the second probe location skipping the first location completely.

WheresWaldo on 5 Apr 2016

The jump to the second point after "Click to Begin" is probably caused by the next handler receiving an extra click. Try this and see if it fixes the problem. Change the line…

lcd_goto_menu(_lcd_level_bed_procedure);

…to this…

lcd_goto_menu(_lcd_level_bed_procedure, true);

This adds an extra delay after the click, so the next handler won't see the same click as a new one. In the long run the menu manager needs to capture all clicks and apply a proper debounce, then pass the click state on to the handlers. Currently, handlers need to do their own debounce management.

thinkyhead on 6 Apr 2016

An interim report 2:
I tested with latest RCBugFix, problem 1 and 2 still occurs.
I can't test the @WheresWaldo's issue,
because I'm testing about these problems in this thread with a delta machine(+ configs for cartesian) .

esenapaj on 6 Apr 2016

And I found a another problem(or specifications?) with latest RCBugFix,
"Kill" button doesn't works in scene of "Home XYZ".
But if in a next scene that it's "Click to Begin", it works.

esenapaj on 8 Apr 2016

I went back and tested with today's RCBugFix 2016-APR-08 and the MESH menu moving directly to point 2 appears fixed. But all the notification strings on the LCD are missing the top row of pixels. When you move the encoder the row appears, you stop and the row disappears. So the issues 1 & 2 still remain. I did not test the KILL button functionality.

WheresWaldo on 8 Apr 2016

"Kill" button doesn't works in scene of "Home XYZ"

@esenapaj I should probably add an idle() call to that screen while it's waiting for homing to complete. I presume that the kill button works okay when you issue a G28 command from the console, yes?

notification strings on the LCD are missing the top row of pixels

@WheresWaldo I'm surprised to hear that a character-based LCD display is doing weird things in the update. I'd be less surprised if it was a graphical display. Anyway, I will look and see if there's something additional that can be done to fix that. Maybe an additional screen clear or redraw is all that's needed…

thinkyhead on 9 Apr 2016

Ok, so I've added a little more control over redraws, in case we need to do an extra redraw (without clear) on character changes. The PR #3435 may not have any effect on this issue (yet), but I think it should be tested ahead of further changes. You can just download the whole branch at https://github.com/thinkyhead/Marlin/tree/rc_lcd_leveling_home_etc and test it. As long as the behavior is no worse, I will be happy. Then we can see if tweaking the handlers to do an extra redraw truly helps.

thinkyhead on 9 Apr 2016

I tested the PR #3435 with RepRapDiscount Full Graphic Smart Controller in haste,
I think that the PR needs update.
In all of the menu, whole screen disappear If I didn't rotate the encoder.
video clip

P.S.
It was no problem (about problem of the screen disappearing) with RepRapDiscount Smart Controller.

esenapaj on 9 Apr 2016

@esenapaj Thanks for giving it a try. Perhaps it's worth it to try changing some instances of LCD_DRAW_UPDATE_CALL_REDRAW_NOW to LCD_DRAW_UPDATE_CALL_REDRAW_NEXT just to see how it affects redraws – especially on the graphical display. I can test my own G3D_PANEL but I don't have a REPRAP_DISCOUNT_SMART_CONTROLLER to test. (Apparently it behaves differently from mine.)

thinkyhead on 9 Apr 2016

Sorry, I should have been more clear. I am also using the Full Graphics LCD Smart Controller. I will ask the few brave fellow Robo users that are testing RC5 or newer if any have the 2004 or XXL to see if they see the same symptoms.

WheresWaldo on 9 Apr 2016

@thinkyhead

to try changing some instances of LCD_DRAW_UPDATE_CALL_REDRAW_NOW to LCD_DRAW_UPDATE_CALL_REDRAW_NEXT

Well, it need to be tested in equal or over the 2^5 cases?
I hasten to set the numeric constants as with the undermentioned,
it's similar non-patched, but Kill button doesn't work whole area of all menues.

line 560
      lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NEXT;
line 1135
    lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NEXT;
line 1164
     lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NEXT;
line 1654
      lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NEXT;
line 2189
          lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NEXT;

If I set the constants as with the undermentioned, I'm feeling that it's similar to non-patched.
But, kill button doesn't works until the Homing is finished, when I issue a G28 from the command-line.

line 560
      lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;
line 1135
    lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;
line 1164
     lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;
line 1654
      lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;
line 2189
          lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NEXT;

I presume that the kill button works okay when you issue a G28 command from the console, yes?

Kill button works fine with non-patched,
when I issue a G28 command from the command-line in Repetier-Host.
~~But with PR #3435 and set the constants as same as the above~~

line 560
      lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;
line 1135
    lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;
line 1164
     lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;
line 1654
      lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;
line 2189
          lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NEXT;

, ~~kill button doesn't works until the Homing is finished, when I issue a G28 from the command-line.~~

(edited at GMT Apr 14, 21:21: problem about kill button is gone on newest RCBugFix.)

esenapaj on 10 Apr 2016

About problem 2:

I become aware that this problem occurs in only case of AUX power(it's 12V usually) is being cut off.

I perceived it now...

So, This isn't a problem, or no need to fix?

esenapaj on 10 Apr 2016

If "Problem 2" is not software then I guess we can't fix it here. But why is the AUX power being cut off? And, to what "long time" do you refer? The lengthy duration of doing a G28 command? The "Homing XYZ" screen should only be visible until G28 is completed, and that should take < 10 seconds.

thinkyhead on 10 Apr 2016

it need to be tested in equal or over the 2^5 cases

"5^2" cases, you mean?

Anyway, thank you for reporting your results. I got to thinking about the changes I've made, and realize there is some alteration of behavior and ordering. I'm inclined to go back to the start and try this fix again, only more gradually.

thinkyhead on 10 Apr 2016

why is the AUX power being cut off?

Because I'm testing about these problems in this thread with a delta machine(+ configs for cartesian),
therefore it's danger to move XYZ axes.
I've only delta machine.

to what "long time" do you refer?

Sorry, it's my very bad english...
I've rewritten the sentence.

it need to be tested in equal or over the 2^5 cases

"5^2" cases, you mean?

I thought about this test as follows.
It's like as 5bit of binary number.

test1:
line 560:      lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;
line 1135:    lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;
line 1164:     lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;
line 1654:      lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;
line 2189:          lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;

test2:
line 560:      lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NEXT;
line 1135:    lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;
line 1164:     lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;
line 1654:      lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;
line 2189:          lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;

test3:
line 560:      lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;
line 1135:    lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NEXT;
line 1164:     lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;
line 1654:      lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;
line 2189:          lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;

test4:
line 560:      lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NEXT;
line 1135:    lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NEXT;
line 1164:     lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;
line 1654:      lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;
line 2189:          lcdDrawUpdate = LCD_DRAW_UPDATE_CALL_REDRAW_NOW;

.
.
.

esenapaj on 10 Apr 2016

Problem 1 can be caused if you tried to call one of the relevant menus outside lcd_update().
Then probably you forgot the 'display loop' for the DOGM-displays.

        u8g.firstPage();
        do {
...
          (*currentMenu)();
        } while (u8g.nextPage());

Blue-Marlin on 10 Apr 2016

The display loop for DOGM hasn't been removed, so that isn't the proximal source of the issue. But, the changes I made to allow more "fine-grained" control over menu handlers is missing some key points that the old code managed to capture.

The old code evaluates lcdDrawUpdate _after_ the "menu handler" calls
The old code clears the screen _after_ the "menu handler" call(s), then redraws _on the next loop_
The old code always decrements lcdDrawUpdate after evaluating it

Meanwhile…

The new code evaluates lcdDrawUpdate _before_ the "menu handler" calls
The new code may clear the screen _before_ the "menu handler" calls, then draw _in the same loop_
The new code uses lcdDrawUpdate as a state machine instead of a "draw counter"

My intention was to get the behavior as close to the original as possible, but add some more options for menu handlers (so they can get a callback to test conditions without being required to redraw, for example).

Since my "clever" new implementation manifests the differences itemized above, I need to keep tweaking it until it does exactly what the old implementation did. For example, if there's a screen clear, then return and wait till the next loop to redraw. Things like that.

"Starting over" —if needed— isn't a big deal, as this isn't a huge change to the "menu manager," and I can do more logging to make sure it's all happening in the same order as before.

thinkyhead on 10 Apr 2016

@thinkyhead
What happened to my donation from 14.mar.2016?
Not received?
Ignored?
Not enough?
Used for coffee?
Not ordered yet?
Not received yet?
Not in use yet?
:-(

AnHardt on 10 Apr 2016

Just a rough guess because the symptom (only refreshing the last stripe) would fit.

Blue-Marlin on 10 Apr 2016

Oh... does development team of Marlin haven't RepRapDiscount Full Graphic Smart Controller?
If it's true, I send the actual thing to the base of developers, or I offer purchase fund. (here?)
I'm regretting that release schedule of the Marlin is delayed because of these problems in this thread,
because this thread was opened by me.

esenapaj on 10 Apr 2016

@thinkyhead, have you received your display?

Regards,

Ernesto

On 10 Apr 2016, at 09:24, esenapaj [email protected] wrote:

Oh... does development team of Marlin haven't RepRapDiscount Full Graphic Smart Controller?
If it's true, I send the actual thing to the base of developers, or I offer purchase fund. (here?)
I'm regretting that release schedule of the Marlin is delayed because of these problems in this thread,
because this thread was opened by me.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

emartinez167 on 10 Apr 2016

What happened to my donation from 14.mar.2016?

I received your donation which is much appreciated, thank you! Although I praised you by name on social media at that time, my internet access has been very limited, so I haven't had time to do my next update post on Patreon and GoFundMe, where I will be thanking you once again, perhaps even writing a poetic verse about it!

As for buying a display, I simply could not. I have no job and no income, so I bought food with it.

thinkyhead on 10 Apr 2016

@emartinez167 I have been watching my mailbox but it has not arrived. I was looking for the tracking number, which you sent me in an image, but I couldn't figure out where the image is! Can you re-send the tracking number?

thinkyhead on 10 Apr 2016

Please help clear this up for me. Are you, @AnHardt and @Blue-Marlin the same individual?

thinkyhead on 10 Apr 2016

😄1

development team of Marlin haven't RepRapDiscount Full Graphic Smart Controller?

I'm building and testing with my one and only RepRap, a custom-built Prusa i3.

Mega2560 + RAMPS 1.4
G3D_PANEL
Mk2 PCB Heated bed
No added sensors

This week I will be hooking up with a local 3D printing startup, to do some custom firmware and hopefully get access to more test hardware.

thinkyhead on 10 Apr 2016

The image is in the Google hangout

On Sun, 10 Apr 2016 at 09:32, Scott Lahteine [email protected]
wrote:

@emartinez167 https://github.com/emartinez167 I have been watching my
mailbox but it has not arrived. I was looking for the tracking number,
which you sent me in an image, but I couldn't figure out where the image
is! Can you re-send the tracking number?

—
You are receiving this because you were mentioned.

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

emartinez167 on 10 Apr 2016

Well, what shall I do...
I've thought that Marlin Project is operated by a corporation, but it seems to be wrong.
I think that Marlin is most powerful about developing in RepRap world,
by contrast, backbone of development system is extremely vulnerable.

Anyway, It looks like that RepRapDiscount Full Graphic Smart Controller was sent out by @emartinez167(this?),
I've offered $30 by GoFundMe for the present, for @thinkyhead's food.
I don't need any praising.

And this is meddling entirely,
I think that development team of Marlin open an official account for donation(it needs to be incorporated?),
and maybe the link should be put the top page of the site and README.md, like the Blender and Repetier.
OSS isn't synonymous with "don't make money".

Chaplin said "All it takes is courage, imagination and a little dough",
but to put it the other way around, minimum dough is needed for everything.

esenapaj on 10 Apr 2016

@thinkyhead is still waiting for the graphic controller to arrive (snail
mail so expect delays).
On Sun, 10 Apr 2016 at 12:08, esenapaj [email protected] wrote:

Well, what shall I do...
I've thought that Marlin Project is operated by a corporation, but it
seems to be wrong.
I think that Marlin is most powerful about developing in RepRap world,
by contrast, backbone of development system is extremely vulnerable.

Anyway, It looks like that RepRapDiscount Full Graphic Smart Controller
was sent out by martinez167(this?)
https://github.com/MarlinFirmware/Marlin/issues/3129#issuecomment-195334307
,
I've offered $30 by GoFundMe https://www.gofundme.com/zmh9h9vc for the
present, for @thinkyhead https://github.com/thinkyhead's food.

And this is meddling entirely,
I think that development team of Marlin open an official account for
donation(it needs to be incorporated?),
and maybe the link should be put the top page of the site or README.md,
like the Blender nation https://www.blender.org/.
OSS isn't synonymous "don't make money".

Chaplin said "All it takes is courage, imagination and a little dough",
but to put it the other way around, minimum dough is needed for everything.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/3373#issuecomment-207913651

emartinez167 on 10 Apr 2016

I see...
Then, I think that it's better to halt fixing about the problems in this thread until @thinkyhead recieve the GLCD.
He is walking blindfolded now, and it's wasting his limited time and preeminent skill of coding in vain.
It's not what I want.

esenapaj on 10 Apr 2016

Whew! My pessimism has been at an all-time high, so thank you for brightening my day with reassurances. A lot of equipment has been promised over the year, and this may be the first to actually arrive! Very excited to get into the graphical display side and start breaking things there too....

thinkyhead on 11 Apr 2016

That's good news, I’m so happy for you.

esenapaj on 11 Apr 2016

final report:
I've tested newest RCBugFix(PR #3596 has been merged), and I confirmed "Problem 1" has been solved.
Now, all of the problems in this thread that it was reported by me has been solved.
Thank you for your work.

I think that this thread can be closed, but we might as well wait a moment for a report by @WheresWaldo.

esenapaj on 23 Apr 2016

👍1

I will take time to test this today.

On Sat, Apr 23, 2016 at 12:05 AM, esenapaj [email protected] wrote:

final report:
I've tested newest RCBugFix
https://github.com/MarlinFirmware/Marlin/commit/d28db67ca9952ca8f315c1020c9708893cdc4074(PR

3596 https://github.com/MarlinFirmware/Marlin/pull/3596 has been

merged), and I confirmed "Problem 1" has been solved.
Now, all of the problems in this thread that it was reported by me has
been solved.

I think that this thread can close, but we might as well wait a moment for
a report by @WheresWaldo https://github.com/WheresWaldo.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/3373#issuecomment-213661593

WheresWaldo on 23 Apr 2016

👍1

Marlin: Problems of MBL menu on RepRapDiscount Full Graphic Smart Controller and RepRapDiscount Smart Controller

Problem 1:

Problem 2 (or it's in the specifications?):

Addendum: Problem 2 occurs in only case of AUX power(it's 12V usually) is being cut off.

All 45 comments

(edited at GMT Apr 14, 21:21: problem about kill button is gone on newest RCBugFix.)

About problem 2:

I become aware that this problem occurs in only case of AUX power(it's 12V usually) is being cut off.

I perceived it now...

3596 https://github.com/MarlinFirmware/Marlin/pull/3596 has been

Related issues