I have modified ultralcd.cpp to switch the LED case lights on/off:
static void lcd_main_menu() {
START_MENU();
MENU_BACK(MSG_WATCH);
MENU_ITEM(gcode, MSG_LIGHTS_OFF, PSTR("M42 P11 S0")); //Lights Off
MENU_ITEM(gcode, MSG_LIGHTS_ON, PSTR("M42 P11 S255")); //Lights On LED Strip on PIN D11
#if ENABLED(BLTOUCH)
if (!endstops.z_probe_enabled && TEST_BLTOUCH())
MENU_ITEM(gcode, MSG_BLTOUCH_RESET, PSTR("M280 P" STRINGIFY(Z_ENDSTOP_SERVO_NR) " S" STRINGIFY(BLTOUCH_RESET)));
#endif
if (planner.movesplanned() || IS_SD_PRINTING) {
MENU_ITEM(submenu, MSG_TUNE, lcd_tune_menu);
}
else {
MENU_ITEM(submenu, MSG_PREPARE, lcd_prepare_menu);
#if ENABLED(DELTA_CALIBRATION_MENU)
MENU_ITEM(submenu, MSG_DELTA_CALIBRATE, lcd_delta_calibrate_menu);
#endif
}
MENU_ITEM(submenu, MSG_CONTROL, lcd_control_menu);
#if ENABLED(SDSUPPORT)
if (card.cardOK) {
if (card.isFileOpen()) {
if (card.sdprinting)
MENU_ITEM(function, MSG_PAUSE_PRINT, lcd_sdcard_pause);
else
MENU_ITEM(function, MSG_RESUME_PRINT, lcd_sdcard_resume);
MENU_ITEM(function, MSG_STOP_PRINT, lcd_sdcard_stop);
}
else {
MENU_ITEM(submenu, MSG_CARD_MENU, lcd_sdcard_menu);
#if !PIN_EXISTS(SD_DETECT)
MENU_ITEM(gcode, MSG_CNG_SDCARD, PSTR("M21")); // SD-card changed by user
#endif
}
}
else {
MENU_ITEM(submenu, MSG_NO_CARD, lcd_sdcard_menu);
#if !PIN_EXISTS(SD_DETECT)
MENU_ITEM(gcode, MSG_INIT_SDCARD, PSTR("M21")); // Manually initialize the SD-card via user interface
#endif
}
#endif //SDSUPPORT
#if ENABLED(LCD_INFO_MENU)
MENU_ITEM(submenu, MSG_INFO_MENU, lcd_info_menu);
#endif
END_MENU();
}
This makes the main menu look like this
When i click "Licht an" the display behaves as expected.
When i click "Licht aus" the display becomes faulty and stays like this until i turn the encoder knob.
Clicking on any other entry behaves normal.
Can confirm this happens on several items in the LCD menu in vanilla Marlin as well.
Which version of Marlin are you running?
RCBugfix as of 10.11.2016
I can also confirm that this happens on other items:
@thinkyhead Any idea on this?
@Kaibob2 @petrzjunior Interesting behavior. Unfortunately I have no equipment to debug on, so I'm afraid someone else will have to do the legwork to figure this out.
Note: Instead of M42
, in RCBugFix
you may now define CASE_LIGHT_PIN
in Configuration_adv.h
and use M355 S1
(on) and M355 S0
.
@thinkyhead I already found this case light lines. Didn't know it was accesible via M355. Maybe this should be mentioned in the comment.
// Define a pin to turn case light on/off
to
// Define a pin to turn case light on/off
//Use M355 S1 to switch on or M355 S0 to switch off
By having this case light function, wouldn't it be great to have a menu entry to toggle the light? The way i did it is due to limited coding skills. A "Toggle case light" would be much more convenient than one ON and one OFF line.
@thinkyhead Quick observation report: bug appears when you click on MENU_ITEM
of type gcode
like Auto home, Steppers release or Kaibob's LED controls. If the clicked item is on the first line, then the second line and half of the third one disappears. If you click on the second line, then only the third line's top half is blank. If the item is on third or lower line, nothing strange happens.
Actually this happens to me as well. Somethings I know for sure trigger it are: refresh sd card, on off for volumetric extrusion. I haven't really though about it before now. I'll let you guys know if I notice anything else.
I wish I could explain it. Invoking a gcode command through the menu doesn't do anything special. The screen simply gets redrawn in response to the click. I'm guessing this only affects graphical displays.
@petrzjunior Good observation! It's exactly the same here (like expected). I always wanted to dig into finding a red line to when exactly it happens, but there where always "more important" things to fix at the moment.
I see that the handling of LCDVIEW_CLEAR_CALL_REDRAW
needs to be tweaked for parity with the updated click handling. Perhaps that will help.
Try this: in ultralcd.cpp
after the line that calls lcd_quick_feedback()
add next_lcd_update_ms = millis();
.
When it comes down to it, most commands don't need to redraw the screen, but only those where a value needs to be redrawn or the page changes, so maybe that should not be set on every lcd_quick_feedback
.
next_lcd_update_ms = millis();
Seams logical, as a turn of the encoder refreshes the screen and this fixes the blanked lines too.
I will test it this evening.
Doesn't seem to do anything, still the same.
Thanks for giving it a try @petrzjunior. If you have some time to experiment with lcd_quick_feedback
and get rid of the unnecessary screen redraws that would be helpful. I won't have access to my machines for a few weeks, at least.
I'm trying to play around now, if I'll come across anything interesting, I'll let you know.
The affected screen is definitely getting an update, maybe some bug in MENU_ITEM
? Also bug doesn't appear when the problematic line is selected.
Went all through the code and didn't find a single wrong line. All seems just perfect. Meanwhile I found out, the most problematic are the SD directories. If you click on one, the whole upper half of the screen doesn't get an update and the middle (3rd) line is half-updated. With encoder move, everything fixes up like a charm. The problem is probably not in ultralcd.cpp
nor in lcd_implementation
. Seems well hidden in u8glib's usage to me.
I don't know if this is clear to everyone, but this issue is quite new. I can't say exactly, but with a RCBugFix version from approx. 3 weeks ago everything was fine. Maybe this helps.
Found the PR! I kept checkout-ing all PR's affecting ultralcd.cpp
and found the problematic one: #5089. After 47ad97c everything was fine, but with 50ee749 the bug appeared.
I gave next_lcd_update_ms = millis();
a try too, but, like expected no luck here too.
@petrzjunior Amazing! This sounds good!
Btw. like I mentioned above i would like to have a Case light toggle implemented. I tried it by myself by copying the Powersupply On/Off function. No luck on this side too. The display says "Case light on" and when i click it the light comes on. Thats it. The menu entry doesn't change to "Case light off" and clicking again doesn't turn the light off.
I think my coding skills are worse than i thought :( Maybe someone can take a look at my attempt. (There is also a grammar correction in language_de.h, but nervermind this)
https://github.com/MarlinFirmware/Marlin/compare/RCBugFix...Kaibob2:patch-8
@Kaibob2 You initialize bool caselight
, show the correct menu item depending on the variable, but you forgot to update the variable, it's always on! Probably somewhere in M355
...
@petrzjunior Thanks, this was the hint i needed 👍
Now it would be great if the refresh of the upper half of the display would work again. Right now the case light toggle works, but it looks crappy :)
@petrzjunior Any news on this one?
I was thinking @thinkyhead will think about it. But maybe he is heaving a busy day. I did so-called legwork, I even read through the commit, but didn't find anything suspicious. At the weekend I may have some time to test it line-by-line, but maybe some reverting could fix that? Not sure...
Quick update: Just tried cherry-unpicking (reverting) that problematic 50ee749, which was conflicting with all other commits from #5089, additional work in f418e82, follow-up c8c1a28 and code reduction in cad792e and after all that work, it was all working again! Almost latest RCBugFix with removed commits written above. So the problem is definitely somewhere in here: 50ee749 :boom:
Oh oh, this was a follow up to #5052 which i opened some time ago. I did a lot of testing in this time and somewhere around this time i first recognized the "not refreshing" issue. So, this correlates fine.
Maybe @thinkyhead can take another look at 50ee749 (please :) )
It looks to me like the clearing of lcd_clicked
after every call to (*currentScreen)()
could be involved. Perhaps some screens are skipping redraw because of this.
My thinking with that change at https://github.com/MarlinFirmware/Marlin/commit/50ee74908254b486536a90d720711a5148722822#diff-34f7cdd618621ae7d8c113cf0b86a2f4R2743 was that the lcd_clicked
flag should only invoke an action on the current screen, and we don't want that action to be invoked twice. Or, if the action happens to change the value of currentScreen
then we don't want the new screen to respond to the previous click (because lcd_clicked
is still set).
Try removing the , lcd_clicked = false
from #define CURRENTSCREEN() (*currentScreen)(), lcd_clicked = false
, and adding lcd_clicked = false;
to the lcd_goto_screen()
function instead, and see if it makes any difference.
I'm not highly confident in this as the solution, so I'll keep looking at https://github.com/MarlinFirmware/Marlin/commit/50ee74908254b486536a90d720711a5148722822.
Hmm, that actually might solve it, because of the way that https://github.com/MarlinFirmware/Marlin/commit/50ee74908254b486536a90d720711a5148722822#diff-34f7cdd618621ae7d8c113cf0b86a2f4R2314 uses the click state.
@thinkyhead Where exactly do i have to add lcd_clicked = false;
I tried a few positions within the lcd_clicked = false;
function but when i click the button on "Light on" it toggles Light on and off rapidly until i turn the encoder
@Kaibob2
The only place it makes _total_ sense to have lcd_clicked = false;
is in lcd_goto_screen
.
But, yes, for a light toggling function, also clear it in that function. Use MENU_ITEM(function, …)
instead of MENU_ITEM(gcode, …)
.
Damn, this was a copy/paste typo. I meant i tried it at different position inside of:
/**
* General function to go directly to a screen
*/
static void lcd_goto_screen(screenFunc_t screen, const uint32_t encoder = 0) {
if (currentScreen != screen) {
currentScreen = screen;
encoderPosition = encoder;
if (screen == lcd_status_screen) {
defer_return_to_status = false;
screen_history_depth = 0;
}
lcd_implementation_clear();
#if ENABLED(LCD_PROGRESS_BAR)
// For LCD_PROGRESS_BAR re-initialize custom characters
lcd_set_custom_characters(screen == lcd_status_screen);
#endif
lcdDrawUpdate = LCDVIEW_CALL_REDRAW_NEXT;
}
}
Was this correct. Where would be the correct place?
Anywhere inside the if (currentScreen != screen)
block will do.
Regarding the light toggling function, rather than making it into a MENU_ITEM(function, …)
as I suggested in the other thread, you could insert lcd_clicked = false; \
into:
#define _MENU_ITEM_PART_2(TYPE, ...) \
menu_action_ ## TYPE(__VA_ARGS__); \
return; \
} \
} \
++_thisItemNr
…just before return
.
Regarding our other topic with the screwy screen update, perhaps it's still fine for lcd_clicked
to be cleared after the call to (*currentScreen)()
— I'm only theorizing so far that it could be involved with the screen glitch. I don't have high confidence in that hypothesis. However, I think it does make the most sense to clear lcd_clicked
in the two places I suggested (in _MENU_ITEM_PART_2
and in lcd_goto_screen
), rather than after each screen segment (i.e., u8g.nextPage()
) is drawn. (Because it will save a couple of cycles in the screen redraw.)
Okay,
with this
static void lcd_goto_screen(screenFunc_t screen, const uint32_t encoder = 0) {
if (currentScreen != screen) {
currentScreen = screen;
encoderPosition = encoder;
lcd_clicked = false;
if (screen == lcd_status_screen) {
defer_return_to_status = false;
screen_history_depth = 0;
}
lcd_implementation_clear();
#if ENABLED(LCD_PROGRESS_BAR)
// For LCD_PROGRESS_BAR re-initialize custom characters
lcd_set_custom_characters(screen == lcd_status_screen);
#endif
lcdDrawUpdate = LCDVIEW_CALL_REDRAW_NEXT;
}
}
everything stays as it was.
With
static void lcd_goto_screen(screenFunc_t screen, const uint32_t encoder = 0) {
if (currentScreen != screen) {
currentScreen = screen;
encoderPosition = encoder;
lcd_clicked = false;
if (screen == lcd_status_screen) {
defer_return_to_status = false;
screen_history_depth = 0;
}
lcd_implementation_clear();
#if ENABLED(LCD_PROGRESS_BAR)
// For LCD_PROGRESS_BAR re-initialize custom characters
lcd_set_custom_characters(screen == lcd_status_screen);
#endif
lcdDrawUpdate = LCDVIEW_CALL_REDRAW_NEXT;
}
}
and
#define _MENU_ITEM_PART_2(TYPE, ...) \
menu_action_ ## TYPE(__VA_ARGS__); \
lcd_clicked = false;\
return; \
} \
} \
++_thisItemNr
too. No update after Button press.
For debugging this screen glitch, let's try this…
First, restore this line https://github.com/MarlinFirmware/Marlin/commit/50ee74908254b486536a90d720711a5148722822#diff-34f7cdd618621ae7d8c113cf0b86a2f4L260 so that it uses the new flag instead of the LCD_CLICKED
macro:
bool wasClicked = lcd_clicked, \
_skipStatic = true; \
…and change https://github.com/MarlinFirmware/Marlin/commit/50ee74908254b486536a90d720711a5148722822#diff-34f7cdd618621ae7d8c113cf0b86a2f4R289 so that it uses wasClicked
:
if (wasClicked && encoderLine == _thisItemNr) {
And if that doesn't fix it, we can try reverting something else within that commit.
Should i leave all the lcd_clicked = false;
stuff from above in there or should i revert to a "clean" ultralcd.cpp?
Revert! Revert!
I reverted the lcd_clicked = false; stuff and changed the two lines.
Now i can enter the main menu and thats it. I can move the selection line and when i click the encoder it beeps but nothing happens. I'm stuck in the Main menu.
FYI: Because i was waiting for an answer i inserted the lcd_clicked = false;
stuff from above again and this made it work. BUT extremely unreliable and randomly, like on every 5th click it toggled and refreshed. The other times it just beeped.
Assuming we have the right commit, try undoing some of the other things that were done in https://github.com/MarlinFirmware/Marlin/commit/50ee74908254b486536a90d720711a5148722822. Eventually you'll find the change that broke it.
I'm sorry, i think this exceeds my Coding skills. Somehow everything relates to everything and i don't get it. I can test whatever you want but whatever i undo in 50ee749 leads to compile errors or malfunction. :(
I see the problem. It's because of this macro:
#define _MENU_ITEM_PART_2(TYPE, ...) \
menu_action_ ## TYPE(__VA_ARGS__); \
return; \
} \
} \
++_thisItemNr
The return
causes the screen handler to exit, which it should really only do in the case when the screen needs to change. If you remove return
from that macro it will fix the glitch. But you will need to test other menu items to make sure everything does as it should. I believe that it will have no ill effect.
PR #5313 should fix the issue. It only does the return
if the screen actually changes.
I also patched the case light code to ensure that the "Case Light On/Off" menu item updates properly in response to the case light state, both on graphical and character-based LCDs. Please test when you have a chance. If this is fixed then I just have to confirm that Dual-X issues are also fixed, and we'll be all set to release 1.1.0-RC8.
If you remove return from that macro it will fix the glitch.
@thinkyhead I did a very quick test this morning and it worked perfect. No glitch, no problems in other menu items. As far as i can say this did fix it. I will test the complete fixup #5313 later when i come back home.
@thinkyhead Everyone shouting for help, red label "verified bug" and nothing's happening. And one day I look at github and it's fixed, silently :D Everything works like charm, good work Scott!
Funny how the bug jumped out at me and was obvious once I had enough sleep. 😁
Seems it is not fixed in any config. Works only if #define MENU_HOLLOW_FRAME
is defined in the ultralcd_impl_DOGM.h
. If it is commented - to display black line of the selected menu (same as in RC7) the first line of new page is everytimes empty. Try Prepare-MoveAxis-Move 10mm-MoveX -> empty screen OR Control-Temperature-Nozzle -> again empty screen but Bed item is OK. Seems that the screen cleaning clear current menu line AND next one. But the next one is already painted. If I start not on the first menu line, but second or next it is OK.
@vprheli Try changing to the most recent RCBugFix. The hollow frame defines moved to configuration_adv.h
I just tested all combinations and they all work as intended. So no bug here.
Hi, thanks, I will check it today evening.
2016-12-19 22:06 GMT+01:00 Kai notifications@github.com:
@vprheli https://github.com/vprheli Try changing to the most recent
RCBugFix. The hollow frame defines moved to configuration_adv.h
https://github.com/MarlinFirmware/Marlin/blob/RCBugFix/Marlin/Configuration_adv.h#L483
I just tested all combinations and they all work as intended. So no bug
here.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/5194#issuecomment-268078495,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ASpRDzZfEbzLcAsOK9Z6n2y0YObPAxCGks5rJvHigaJpZM4KuaPo
.
Hi, I am sorry, the bug is still there. I downloaded the ZIP file from the
https://github.com/MarlinFirmware/Marlin/tree/RCBugFix and changed only
couple of parameters in configuration files - see attachment.
Menu-Control-Temperature-Nozzle - empty screen.
Arduino IDE 1.6.12, ArduinoMEGA2560, RAMPS1.4,
REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER
and the inverted selected menu and X-Y-Z in the status screen
// Enable to save many cycles by drawing a hollow frame on the Info Screen
//#define XYZ_HOLLOW_FRAME
// Enable to save many cycles by drawing a hollow frame on Menu Screens
//#define MENU_HOLLOW_FRAME
This is only one chenge in the Configuration_adv.h I changed only some
parameters only to test this bug.
Vladimir
2016-12-19 22:06 GMT+01:00 Kai notifications@github.com:
@vprheli https://github.com/vprheli Try changing to the most recent
RCBugFix. The hollow frame defines moved to configuration_adv.h
https://github.com/MarlinFirmware/Marlin/blob/RCBugFix/Marlin/Configuration_adv.h#L483
I just tested all combinations and they all work as intended. So no bug
here.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/5194#issuecomment-268078495,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ASpRDzZfEbzLcAsOK9Z6n2y0YObPAxCGks5rJvHigaJpZM4KuaPo
.
Should be fixed now with #5567 merged.
Most helpful comment
Funny how the bug jumped out at me and was obvious once I had enough sleep. 😁