12864 LCD Encoder not working anymore

[lavato]

I have installed 12864 LCD with RAMP 1.4 but the Encoder button does not work. However the same HW setup works with Marlin 1.0.2

[thinkyhead]

Thanks for bringing this to our attention. Check out these issues: #3007 https://github.com/MarlinFirmware/Marlin/issues/2681#issuecomment-147735504 and see if they have any connection to yours.

I'm investigating the issues discussed in these threads, but so far I see nothing at least logically wrong about the code for handling "slow buttons." I am also comparing how 1.0.2 does things differently from the current version, so hopefully that will turn up some clue – or at least we can revert the behavior.

Incidentally, do you have a Viki or a Makrpanel, or just a generic one? And, what version of Arduino IDE are you compiling with?

[lavato]

I think it is Makrpanel. I provided the link below.

It is definitely not #3007 & #2681, as the button does not respond at all, so nothing happens when you push or rotate. It is stuck in the home screen.I cannot even get to the menu. The only time the push button works is for a brief moment, 100ms, when I can push and rotate just after Marlin reboots, but after this it does not work at all.

I have compiled Marlin with 1.6.7 & 1.6.8 Arduino. The only other thing I noticed is that the 1.0.2 uses different u8glib ()

FYI: I used vanilla RC4 and vanilla 1.0.2 to ensure I can reproduce. The only thing I changed in the Configuration.h. is the Motherboard to 33 and LCD entry to "discounted full".

Here is the link for the LCD I use:

http://www.aliexpress.com/item/Free-shipping-3D-printer-smart-controller-RAMPS-1-4-LCD-12864-control-panel-blue-screen/1966418671.html?spm=2114.01010208.3.2.0AtDjb&ws_ab_test=searchweb201556_9,searchweb201602_1_10036_10035_301_10034_507_10032_10020_10001_10002_10017_10010_10005_10006_10011_10003_10021_10004_10022_10009_401_10008_10018_10019,searchweb201603_8&btsid=6e1c84b0-970c-4aab-9c36-1e801b560421

[thinkyhead]

Be sure to use the latest RCBugFix so we know you have the latest code. Just in case we fixed this by mistake already.

[lavato]

I tried it, unfortunately it is still the same, reverted back to 1.0.2 again and it works.

FYI: the RCBugFix has its default motherboard set to RAMP EBF

[thinkyhead]

EBF? Hmm... I'll make sure that's patched ASAP. I'm going to try and track down this issue for you today. I wonder if you could try the older u8glib from 1.0.2 with RCBugFix and see if it helps. If it's a library conflict that would be useful to know.

[G-Forge]

I am sure that the default mother board is EFB From configuration.h

#ifndef MOTHERBOARD
  #define MOTHERBOARD BOARD_RAMPS_14_EFB
#endif

This is 43 in boards.h Works OK here with the same controller

[thinkyhead]

@lavato I'll keep staring at the code, but we may need to ask you to do some testing if we're going to find this bug. It's good to know that the bug doesn't exist in 1.0.2. How about 1.1.0-RC2 or 1.1.0-RC3? Does the bug exist in those? If not, I can provide you with branches from different points in time, so we can narrow the bug down to a particular week or day when it started.

[Roxy-3D]

@thinkyhead You have mail...

[Blue-Marlin]

I think it is Makrpanel.

The link shows a REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER

[thinkyhead]

@lavato Is this the LCD you have selected in your configuration – – REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER?

[lavato]

1) Yes the setting is: "REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER" 2) NP , I Will try RC2 & RC3 tonight and get back. 3) For default motherboard: I meant to highlight that in 1.0.2 the default board is BOARD_ULTIMAKER and in the new release it is BOARD_RAMPS_14_EFB. (EBF was a typo :( )
BTW, I agree with a change as I think more people use RAMPS.

[lavato]

OK, I recompiled below and:

• RC 1 works
• RC 2,3 & 4 does not work.

I used u8glib => 2015-07-14 - v1.18 Oliver Kraus olikraus@gmail.com

[Grogyan]

I suggest looking at your Full Graphic Display board for solder shorts. If you have a multimeter, you can do a continuity check on the encoder when the printer is switched off. Also, try swapping the cables over, it may be possible that you have bung cable.

As I and many others use the same setup as you do, and not have any problems.

There was a brief time when RCbugfix, and the display wouldn't work, but it has since been fixed.

[lavato]

@Grogyan Not sure I agree with that, as the card works with 1.0.2 and RC 1. ... but I did look, it is a new card and has no defects nor breaks as far as I can see. Don't forget, it worked great with 1.0.2 for 2 months until I wanted to try RC4.

[jbrazio]

@Grogyan @lavato which boards are you using ?

[lavato]

I use RAMPS 1.4 & Arduino Mega 2560

[Roxy-3D]

@thinkyhead You are a popular guy! You have more mail.

[thinkyhead]

We continue to patch bugs, some related to LCD. So please try the latest RCBugFix when you get a chance and let us know if we fixed this issue yet.

[lavato]

@thinkyhead

I did, as this is what you suggested before, however, I though you were to send cuts of code from different periods between the two RCs, which I was to test? (i.e. time periods between RC1 & RC2)

I hope this is not affecting majority of 12864s but I would imagine people don't often change the firmware, which is why this may not have been highlighted before. If this proves to be more common, people with same config may not be able to use the new release.

I would have though my config was pretty standard?

[thinkyhead]

@Roxy-3DPrintBoard Sorry, my internet access has been somewhat limited lately. I will get to your email shortly…

[thinkyhead]

@lavato I'm still unable to reproduce the issues you're seeing, but I don't have your exact display. Anyway, more bugs have been getting patched in RCBugFix, and some of them are around the LCD menus, so please give the latest code a try when you get a chance. Be sure to copy the u8glib that comes with Marlin into your Sketchbook folder. Otherwise Arduino might be using a version we haven't tested with. (It's stored in the ArduinoAddons/Arduino_1.6.x/hardware/marlin/avr/libraries/U8glib folder).

[Blue-Marlin]

U8GLIB has NOTHING to do with the encoder.

I'm not convinced it's a error with the encoder at all. With about the same likelihood it's a ignored MINTEMP and killed therefore.

What does the display/log tell you.

[thinkyhead]

U8GLIB has NOTHING to do with the encoder.

Certainly. But it would be lax not to make sure we're all using the same libs for testing. I also want to eliminate the possibility of any unrelated components stepping on stack or buffers and causing such strange behavior in the LCD menus. (Lately buffer corruption has been more of a worry on my mind, because we saw buffer corruption in the command queue recently –– but only for one user so far - whew!)

With about the same likelihood it's a ignored MINTEMP and killed

If there's a temperature error, that is usually flagged on the LCD screen. If it isn't, then that would be another bug to look into.

[Blue-Marlin]

@thinkyhead REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER is about the second most installed display out there. RAMPS 1.4 & Arduino Mega 2560 is about the most common combo out there. In the encoder handling we have not had relevant changes between 1.0.2 and now. If so, the changes (to RC1) would be about a year old now.

The likelihood he is the only one who discovered that "encoder" problem is extremely small. Much more likely is, that he's missing to tell us an important detail of his story.

Killed, would be a good (and likely) reason for a death knob/RAMPS/MEGA/Marlin.

[thinkyhead]

Perhaps we might helpfully suggest a test that he can do to confirm or refute this possibility.

[lavato]

@Blue-Marlin I agree, the chance is small - but this particular version of the Ramps is widely sold on eBay & AliExpress so the market is folded with this stuff.

also

I have now reproduced this many times moving from 1.0.2 to RC4\RCBugFix and changing the same points in the config, the MBO and the LCD. I also removed all HW and only left the LCD. (to make sure)

Sadly RC4/RCBugFix still does not work but 1.0.2 does.

I thought the idea that thinkyhead had to test cuts of code between 1.0.2 and RC1 is a good one but I need help obtaining the source code for these time periods.

Also, tonight, I will compile with the version of u8glib that comes with Marlin and use the latest RCBugFix and come back with results to this thread.

But I suggest we go with thinkyhead's approach.

[Blue-Marlin]

Is there any reason for not telling us about your status line or the last 10 rows of the serial connection?

[lavato]

@Blue-Marlin Not sure what you are implying here.

What do you mean by "status line" and "10 rows of the serial connection"?

[Blue-Marlin]

What does the lowest line on your display show?

What does the terminal window of your host program show?

[lavato]

@thinkyhead OK. I don't know what the problem is exactly but I can confirm that encoder does not work when all the hardware is removed. ( so the only thing connect to RAMPS is 2560, PSU & LCD),

however

when the stepper motors, hot end and the rest are attached, the encoder works. I tested with RC4, RC5 and RCBugFix.

But as per above, 1.0.2 works regardless. Not sure if you want to investigate further but I am happy with this "feature".

@Blue-Marlin _Last status line says: _ 3d Printer ready.

Serial last 10 lines: echo:Home offset (mm): echo: M206 X0.00 Y0.00 Z0.00 echo:Material heatup parameters: echo: M145 S0 H180 B70 F0 echo: M145 S1 H240 B110 F0 echo:PID settings: echo: M301 P22.20 I1.08 D114.00 C100.00 L20 echo:Filament settings: Disabled echo: M200 D3.00 echo: M200 D0

[Blue-Marlin]

Thanks for the feedback. Instead of connecting all the periphery it would be completely sufficient to use 999 as thermistor type, to avoid the ERR: MINTEMP and the kill for that.

[thinkyhead]

Sounds like a result of our tightening up on issues like disconnected thermistors at startup. If the encoder works (and the printer is not in kill state) under normal conditions, then this is closed.

[lavato]

@Blue-Marlin Thanks for the suggestion.

I need to print some stuff before I take out all HW again but I will try it next week, as I will be doing some more upgrades.

So I understand, are you are saying that after the "ERR: MINTEMP" event occurs, the framework will prevent encoder from working in RCs 1-5 but not in 1.0.2?

@thinkyhead As above I will try next week

[Blue-Marlin]

I can't remember on 1.0.2 really. But since about a year we kill the machine when we see a MINTEMP error - or any other potentially disastrous condition.. That means - you can't do anything but reset. And before you ask - yes, that's wanted to be exactly this way.

[lavato]

you said it. ;)

The only thing I would do is just add a comment in the code to clarify it (the 999 point), so when people hook up just the LCD they know if works.

[lavato]

I can confirm that "Killed" event, which was caused by "MINTEMP" is a reason for LCD encoder not working.

[OmurCeran]

Hi.I have a problem which is almost similar this.There is a photo which is mine lcp smart controller.After ı upload rc7 firmware for my 3d printer, I go through this problem.Can you solve this problem ?

[Blue-Marlin]

"KILLED." is printed in 3 situations

• You called it with M112
• "trying to call sub-gcode files with too many levels. MAX level is:"
• INVALID_EXTRUDER_NUM

The serial log will show you the details.

[OmurCeran]

I don't understand clearly. Can you explain more clearly?

[Blue-Marlin]

No.

[OmurCeran]

What? Why?

[Blue-Marlin]

Please look up the reason in the serial output. Please report the output here. Then, when we know the reason, we can try to give you advice what to do.

[thinkyhead]

@OmurCeran If you connect Pronterface or some other host, then you should see a more detailed error message in the console when this kill screen appears.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.