Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When the encoder adjusts the fan speed, the fan speed and print speed are changed together #757

Closed
Moreman73 opened this issue Jun 4, 2020 · 17 comments
Labels
bug Something isn't working

Comments

@Moreman73
Copy link

Hello, if you go into the fan speed settings of the model blowing fan and start adjusting its speed with the encoder, this causes a change in print speed along with a change in the fan speed, everything works fine with the touch buttons.

<TFT Firmware Version 26.x Main Board Firmware Marlin-bugfix-2.0.x

@Moreman73 Moreman73 added the bug Something isn't working label Jun 4, 2020
@radek8
Copy link
Contributor

radek8 commented Jun 4, 2020

Unfortunately, it's not a mistake, it's a feature
read here
#680

try pressing 1 briefly before using the encoder.
This will take you to a menu in the marlin menu where there is no change in speed.
But more presses can be a problem :-)

@Moreman73
Copy link
Author

Unfortunately, it's not a mistake, it's a feature

The fix that you suggested does not work? "Fixed encoder behavior in touch mode. #718"

@radek8
Copy link
Contributor

radek8 commented Jun 4, 2020

It's not working, so I closed it

@AnHardt
Copy link

AnHardt commented Jun 4, 2020

I suppose the contacts of the encoder, the pins on the ext port to the mainboard where Marlin runs and the inputs of the displays processor are hard wired together. In that case there is no satisfying solution. The encoder signals will always be received by the display and the mainboard. So either one can use the encoder with the display - then Marlin should be configured to nut use its display. Or Marlin can use the display but the touch screen firmware has to ignore the encoder. Else both of the systems react independently on the encoder and do different things.
A proper hardware solution would be to route the encoder signals only to touchscreens processors input pins and connect the pins to the mainboard only to some outputs of the touchscreens processor. Then the touchscreen firmware had to mirror the inputs to the outputs only when in Marlin mode. An other way, saving some pins, could use some hardware AND-gates to block the signals to Marlin when not in Marlin mode.

@radek8
Copy link
Contributor

radek8 commented Jun 5, 2020

You're saying that right.

But this would be a big HW and SW intervention in the display.

The solution is to make sure that before you turn the encoder, Marlin is not in the home screen, where he changes the print speed.
If it is in the menu, turning the encoder will only move the menu but will not change the speed. you must not press the encoder, otherwise you will start the function you are standing on in Marlin.

Another option is to disconnect the EXP2 connector if I don't want to use the Marlin transmitter. EXP2 transmits encoder movement data to Marlin. If I switch to Marlin, you'll plug in the connector. :-)

@AnHardt
Copy link

AnHardt commented Jun 5, 2020

You'll never know if Marlin is still in Menu-mode or if already returned to status-screen via timeout. This will never work reliably.

Adding a g-code to Marlin to enable/disable the display-panel-inputs? Kind of 'keylock'?

@radek8
Copy link
Contributor

radek8 commented Jun 5, 2020

When I disable the option
#define LCD_TIMEOUT_TO_STATUS
does the return to the status screen turn off?

@radek8
Copy link
Contributor

radek8 commented Jun 5, 2020

This option will only increase the time to return to the status screen.
after disabling it, the default value of 15s is used
A change would have to be made to the Marlin code

@radek8
Copy link
Contributor

radek8 commented Jun 5, 2020

Option -1 turns off the automatic return of the Marlin setting screen
#define LCD_TIMEOUT_TO_STATUS -1
If I set Marlin like this, just 1 press of the encoder, the next turn of the encoder will no longer change the print speed in Marlin.
This does not solve the problem, but allows you to use the encoder in touch mode without changing the print speed.

@radek8
Copy link
Contributor

radek8 commented Jun 5, 2020

If pressing the encoder were emulated when the printer was connected, further rotation of the encoder would no longer affect the printing speed.

Currently, the first time you switch from the touch screen to Marlin, one turn and one press of the encoder is sent, but I don't know why.

image

@Tygrys-1
Copy link
Contributor

Tygrys-1 commented Jun 5, 2020

Maybe to force the Marlin to refresh the display?
However, this does not work.

And why no longer can select modes using the knob?

@kind3r
Copy link
Contributor

kind3r commented Jul 1, 2020

I was wondering why the speed display went crazy when trying to adjust it using the knob, and also why the speed changed by itself all the time.

In Marlin there is an option that should disable feedrate multiplier change on the status screen in Configuration_adv.h called ULTIPANEL_FEEDMULTIPLY. Haven't tested yet but I will in a couple of hours. While not perfect it should solve most of the issues (unless you really need to change the feedrate from the Marlin status screen), just make sure you are on the status screen when switching to TFT mode.

Update: well, that worked, but still there are issues when adjusting speed or flow via the rotary encoder.

@kind3r
Copy link
Contributor

kind3r commented Jul 6, 2020

Before the 41a11fa adjusting fan speed, speed and flow using the knob in the BTT default firmware worked, now if you turn the knob fast it glitches. I was using @guruathwal 's branch when I noticed this, switched to the BTT and it worked fine. Now the glitch has propagated in the main fw. I tried to investigate the issue but can't figure it out. It could be related to the new larger fonts cause everything else seems to work the same and that is the only obvious change (except for the code split).

@kind3r
Copy link
Contributor

kind3r commented Jul 6, 2020

Made a short video about the issue: https://youtu.be/u0Gz-jvzVVs

The changes are also sent to the printer and the glitch persists until reboot.

@oldman4U
Copy link
Contributor

oldman4U commented Sep 5, 2020

@Moreman73

This issue is now described in the pinned ticket #1047

Please close this ticket

@oldman4U
Copy link
Contributor

@Moreman73

Close this ticket

Copy link

github-actions bot commented Apr 5, 2024

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.

@github-actions github-actions bot locked and limited conversation to collaborators Apr 5, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

6 participants