Closed wrchasesims closed 3 years ago
LCD knob has an issue, but it's a material issue.
Interesting. I'm not too sure that on my ender it's a material issue tho. The knob consistently works totally fine until I try to take one of the above mentioned actions. And has never ever had an issue with slipping until now.
@Chaseums0967
I was planning to report this issue as well as i have noticed this too also.
I would like to report also that this misbehavior happens usually when you rotate the encoder very fast as Christopher said. Honestly i do not know if it's faulty material or code related
I was planning to report this issue as well as i have noticed this too also.
I would like to report also that this misbehavior happens usually when you rotate the encoder very fast as Christopher said. Honestly i do not know if it's faulty material or code related
The reason I believe it's code related is that I don't feel any physical mechanical slippages, and it only happens after certain actions are taken, and those actions consistently cause the issue.
Are you also experiencing the live adjustment problems?
@Jyers any idea what may resolve these issues? Wonderful work, by the way. Thanks so much!
The only way this would be a firmware bug is if somehow the encoder was getting put into rate adjust mode (increase encoder difference reports when spinning faster) I'll look into it but it seems unlikely. The note of "Eventually causes screen to reset itself which usually clears any unsaved configurations." really makes me think this is a hardware issue, as full reboot generally means a fatal error of some kind has occurred.
@Jyers Copy that and thank you! Not trying to step on your toes here or make it seem like what you've done is faulty. It's almost certainly something on my end, I just don't know what that something is.
Is there any possible chance it's that new LCD FW needs to be flashed? Sorry for any silly questions but this side of 3D printing is so new to me it's making my head spin. Just trying to spend the least amount of time troubleshooting/finding a fix action so I can just get back to printing, LOL. Haven't been able to for almost two weeks now.
@Chaseums0967 Sorry if it seemed like I was annoyed, this was like # 8 of 12 notifications I was running through so I was just getting to the point 😅 You could try different screen firmware and see if it helps. At the moment I don't really have anything to go off besides checking the encoder rate, so feel free to update if you get any new information and I'll do whatever I can to help get this fixed.
Any updates on this?
Just wanted to add on my experience- The LCD knob response issue only seems to happen on the home menu with the four blocks; it doesn't occur in sub menus (EDIT: I've started noticing it occur everywhere). It also seems sporadic, most of the time the knob responds with 1 detent per menu item. I also noticed that even when the knob is responding properly the main menu responds to rotation slower than stock marlin firmware.
I was not making a criticism of the code- I was simply adding on my experience with this issue.
I'm also experiencing the LCD knob response issue, mostly on the home screen.
I am also experiencing similar encoder wheel issues on 3 separate printers. Two Ender 3v2's and a Voxelab Aquela (E3v2 clone) with extremely similar hardware, So much so that is can run the same firmware. It's defiantly related to acceleration to some extent. After some testing when scrolling at a steady state in any menu the cursor will accelerate or slow down on it's own and at times even reverse direction or not respond at all for one or two detent's on the knob. Whats the chances of all 3 having bad hardware? I have changed out the display on one of them with a spare display and ribbon cable with the same results. This all started happening with 1.3.0 rev and has gotten worse with each new revision since. Flash back to stock or any of the 1.2.x rev's and the issues are gone. I could see if it was just lagging in response but it's glitching much more than that. Also the enter function seems to be a bit overly sensitive. Whatever it is seems to be issues in general interpreting the encoder wheel inputs.
Forgot to add when all this is happening my screen never reboots.
I don't want to be rude but your comments are coming off as very condescending and dismissive. The people commenting on this issue are simply sharing their experience with this issue.
I don't believe this issue is caused by lack of processing power. I'm not saying I know what the fix is, but simply saying fixing it is not possible is not conducive to the resolution of the issue.
Your comments are the type of comments that drive people away from open source development.
@tititopher68 First off let me preface this reply with the fact that it is in no way directed toward you or your work personally. I very much appreciate all the hard work you and the other dev's do.
I totally 100% understand exactly what you are saying. Correct I am not a programmer and don't claim to be one. So no I have not analyzed the individual rev's code for differences. However I am in IT (network engineer) for the past 25 years (data center design and implementation) so I have a decent knowledge of hardware in general and also for almost 40 years since the IBM 8080 days as a hobbyist. While your hypothesis is certainly plausible and makes sense to a point it still leaves some unanswered questions. I think some of these display related issues deserve further investigation. You still may be 100% correct and I am not interested in debating just for the sake of who is right or wrong as it's not important at all. Just merely seeking a possible solution as in it's current state the display is rapidly becoming unusable. It's glitching all the time for me not just specific areas/tasks or sub menus. Even just scrolling the main menu at idle.
Like I said even something as simple as scrolling the main menu while idle without entering any sub menu causes glitching for me on any 1.3x rev. It's not isolated to access of a particular feature set. Is the processor so anemic that it can't scroll the main menu without issue with the current firmware rev? Also if scrolling in a single direction at a steady state it speeds up, slows down and also changes direction from time to time. I can see the rest as issues with lack of processing power but where does the change of direction come from if the command to move in another direction is not issued? This is present on all 3 printers. One V2 with a 4.2.2 board and the other with a 4.2.7. The Aquila with a slightly different display but with the better 512k ST32 processor. I don't know if there are any differences between the three display processors as I haven't gotten that far. The Voxelab and Creality encoder wheels are a bit different though and I wounder if there is a difference in reporting rates between the two?
I also tried another trouble free v2 running the same firmware and hardware as one of the troubled ones with no display issues and then swapped out displays and ribbon cable between the two . The one with trouble still had issues and the one that didn't still had no issues.
If it is a feature vs processing power issue with the 1.3.x releases then I would think more people would be having problems and reporting them? The issues would be much more wide spread no?
Just to clarify...Do you think the issue lies with the display processor, motherboard processor or a combination of both? I get the impression you are saying a combination of both?
As previously stated I appreciate all the work you and the other dev's have done to greatly advance the capability's of this printer in such a short time. Thank you for also talking the time to reply and provide some insight on the issue. However I would think there could be some solutions deployed to mitigate to some extent the problems and not just dismiss it as lack of processing power and call it a day. I do believe that some of the display issues may well be related to lack of processing power and feature creep. However at least in my case there seems to be more to the issue. Hopefully they can at least be mitigated to some extent if it is just a processor issue by identifying the biggest resource hogs and providing either a lite version or a way to toggle on and off a feature or two and free up some resources. In it's current state it's almost unusable for me. I don't know how much code optimization is possible either as I am most defiantly not a programmer but work with them on a daily basis. I know the struggle between hardware and software groups to find balance between feature set and hardware requirements.
Any updates on this? Is it still occuring with the latest release?
@Jyers So sorry I haven't responded earlier!!!
So, I haven't tried the latest release and more than likely will just stick with the v1.3.2.
I never got live adjustment working, and the knob issues never went away, I've just been overlooking both issues (not using live adjustment and basically just doing as little navigation on screen as necessary to print). Haven't had time to continue to mess about with the issues unfortunately.
@firecrafty Have you tried the newest release by chance?
I have not, I've been away for a few days but I should be able to test it tomorrow evening
Any improvement with more recent builds?
Closing due to inactivity, if we get any more info, or something new arises this can be reopened
Description
1) Live Adjustment causing axes to stutter back and forth when commanded to only flow in a single direction (AKA sending Z up so I can clean my bed.) Does not have the same issue when live adjust is off. Happens EVERYTIME I turn on live adjust.
2) When LCD knob is used to navigate screen, menu options often won't change until after the wheel has rotated a single 'click' twice. Seems only to happen after saving configuration and attempting live adjustments. Eventually causes screen to reset itself which usually clears any unsaved configurations.
Getting the same issues with both v1.3.1 and v1.3.2
Tthis is likely a "me" problem as I don't see anyone else talking about these issues. Curious as to whether or not there's some conflict between my LCD firmware and the printer firmware as my LCD is NOT running on standard Creality FW. Tho I did see on Reddit, Jyers commented that no LCD FW flash should be required for usage. Just scratching my head on what else it could be.
Steps to Reproduce
Select Live Adjustment, move any axis any direction (in a single direction). Expected behavior: Axis smoothly moves that direction in real-time. Actual behavior: Axis begins moving that direction, then will move a bit in the opposite, stuttering back and forth until it painstakingly reaches its destination.
Save config and/or select live adjustment. Check LCD knob for responsiveness. If not moving to other menu items from a single rotation 'click' then continue trying to adjust offsets and other menu items, saving config multiple times. Z home, autohome, level bed, basic machine setup in general. See if LCD screen ever errors out and resets itself. Expected behavior: Config saves or live adjustment goes off without a hitch. LCD knob moves between menu items with a single rotational 'click' of the dial. No LCD reset. Actual behavior: Knob becomes unresponsive to single 'clicks.' must move two 'clicks' before moves to next menu item. Issue persists until machine is rebooted. Goes back to normal after reboot.
Additional Information
Printer: Stock Ender 3v2 with stock LCD. 4.2.2 board. BLTouch v3.1 installed to mainboard. Printer FW: .bin from Jyers repo, tried both v1.3.1 and v1.3.2 (current). LCD FW: Honestly, can't remember at this point. Tried many different options in hopes it would allow me to live babystep my Z while printing, which wouldn't happen on standard Creality BLTouch firmware (the whole reason I embarked on this journey to begin with). Which is just one more good reason to believe it may be the LCD FW.
Can provide videos and additional info upon request.
More than willing to help out with this wonderful build of Marlin, just so new to all of it that I'm nearly positive it's user error due to my lack of knowledge.