ENCODER BUG? Fysetc 12864 G32 MBL screen Builtin function

alankilian

@leckietech Do you happen to have an oscilloscope at work?
Seeing those signals would help a ton.

Scope traces from right at the user Interface connector and also from where you plug into the Duet board would show if there are pullup issues or other signal interference.

(Attach the scope ground to the same board you are attaching the probes for the two measurements.)

dc42

@leckietech what length cables do you have between the Mini 12864 display and the Duet?

Are they genuine Fysetc displays? It sounds to me that they have very poor encoders.

There is a parameter in the M918 command to specify the number of pulses per click that the encoder produces. Common values are 2, 4, -2 and -4.

Topher

@dc42 said in ENCODER BUG? Fysetc 12864 G32 MBL screen Builtin function:

@leckietech what length cables do you have between the Mini 12864 display and the Duet?

There is a parameter in the M918 command to specify the number of pulses per click that the encoder produces. Common values are 2, 4, -2 and -4.

Ive set the M918 so there is no double step to achieve a single increment of the printer. The cable length is roughly 10".

@alankilian said in ENCODER BUG? Fysetc 12864 G32 MBL screen Builtin function:

@leckietech Do you happen to have an oscilloscope at work?
Seeing those signals would help a ton.

Scope traces from right at the user Interface connector and also from where you plug into the Duet board would show if there are pullup issues or other signal interference.

(Attach the scope ground to the same board you are attaching the probes for the two measurements.)

I will connect my Oscope to it and see what the signal is doing and report back.

alankilian

@dc42 Are you using an encoder-counter peripheral or are you doing something with interrupts on the encoder inputs?

If you'd point in the right direction in the source, I can find it myself also.

It sounds like when one phase is switching very quickly between two states that the firmware thinks counts are happening even though it should just be counting +1 and -1 back and forth.

I've done encoder counting many times, and it's always hard for me to get it right if I don't have an actual peripheral helping me.

dc42

Neither, the encoder inputs are polled and a transition table inserts hysteresis. For it to count continuously, BOTH inputs must be transitioning. So I think there is something seriously wrong with the encoders or the wiring. Nobody else has reported a similar issue.

alankilian

@dc42 I just reviewed the code and I see now.

I agree that for slowly-changing/UI-style encoders (compared to your polling rate) this code is well-suited to the task..

(I would quibble with the +2/-2 in the table, but that's for drinks sometime )

I'm still guessing the signals are going to be noisy enough to fool the code.
Experiments/data will tell.

dc42

@alankilian are you using especially long ribbon cables between the Duet and the LCD? Or some other wiring scheme?

It's normal for these encoders to have contact bounce. It's not normal for both the A and B contacts to bounce at the same time.

You are the only person reporting this issue, yet you have it on multiple machines. So I think there must be something different about either the displays you are using or the way you have connected them.

Topher

@dc42 I went by the office today and brought some gear home. Something does seem odd about the signals coming from the encoder. With oscope leads on A + B, there is noise on the rising and falling edges as to be expected, but it seems there are some missing pulses! I'm not an expert on encoders and what the signals should look like but I know the signal pulses should be consistent. Here are some screenshots with a long acquisition turning the knob average speed in the same direction.

@alankilian said in ENCODER BUG? Fysetc 12864 G32 MBL screen Builtin function:

@leckietech Do you happen to have an oscilloscope at work?
Seeing those signals would help a ton.

Scope traces from right at the user Interface connector and also from where you plug into the Duet board would show if there are pullup issues or other signal interference.

(Attach the scope ground to the same board you are attaching the probes for the two measurements.)

as you can see from the photos, there doesn't appear to be any pullup issues with the signal. Im consistently getting 3.3volts on the rise.

alankilian

@leckietech Right here is your problem.

Both phase A and phase B are jumping around at the same time.

That will cause the Duet to see the encoder as being rotated at a rapid rate.

I don't know what can cause that other than a poor-quality encoder.

alankilian

This page shows what normal quadrature-encoder signals look like when turning an encoder in one direction.

Topher

@alankilian I added some 0.01uf ceramic caps between gnd and signal then a pull up resistor from signal to 3.3v and it didnt make a difference at all. so maybe you guys are right and its just bad encoders. I order from digikey all the time, is there an encoder that you can recommend?

dc42

@leckietech it's a while since I bought encoders, but I remember looking at the specifications and choosing Bourns in preference to Alps.

alankilian

@leckietech I haven't purchased encoders for a while, but I think most enything from DigiKey should be OK.

It's interesting that this one shows a recommended filter arrangement on page 2
https://www.digikey.com/en/datasheets/cuiinc/cui-inc-acz11

Also, on page 2, they imply that the switches are going to bounce for up to 5 milliseconds when they change state. I didn't do the math, but with 20 pulses-per-rev I don't think you'll have a problem with that unless you try to spin the encoder REAL fast. (Probably you should do the math)

For less then US$6 each, I would get one or a few when you next order from DigiKey.

Topher

@dc42 thanks for the tip - ive found one i think will work. Ill order it and report back!

@alankilian Thanks for the suggestion. I was looking at this one here:

https://www.digikey.ca/en/products/detail/bourns-inc/PEC11R-4015K-S0024/4699187?s=N4IgTCBcDaIAoFEDCBGFAlAtAFgAwoFYBpTAZV1zGxAF0BfIA

The measurements check out and it has only 2ms bounce time @ 18rpm. Seems ok to me. I noticed they suggested the same debounce filter, too. There is some noise on mine but I am certainly missing some pulses as you so kindly confirmed. Ill order a few. Ive got 60 of these screens so its kinda a bummer I have to repair all of them...

Topher

@dc42 Im running a few of these on Duet 2 wifi, I noticed the M300 only triggers a 0 or 1 state based on P*** whereas the Duet 3 actually oscillates a tone based on the S***? Is there a way to address this or should I replace it with a piezo speaker that will make a constant tone with 5 volts?

Topher

@alankilian @dc42 Sorry guys. looks like I made a mistake testing and must have been moving the leads too much while turning the encoder so I put some pins right into the header at the duet board. It's not the encoder after all. Here is the scope while turning the encoder left slow then right fast. every pulse is accounted for. during this time I had selected 521 baby-stepping on the 12864 display and I can confirm, it is still giving me erratic responses even though these are clean pulses.

Topher

@dc42 Here is another example in my home menu. If the knob is turned so it lands between bumps in the encoder, it will actually somewhat oddly select 2 items at once. During this time the scope is flat-lined, so I can 100% confirm there is no noise with the switch in that position.

dc42

@leckietech those are still not normal encoder pulses. A normal encoder produces pulses with a mark:space ratio of around 1:1 and the two signals are 90deg out of phase. Those pulses are much shorter and overlap only slightly, which means the encoder needs to be polled much faster in order to detect all the states that it goes through.

My guess is that the combination of pulses that only overlap slightly coupled and a known issue with inefficiency of how the ST7567 display is updated are causing RRF to miss some state changes. The display update issue is scheduled to be fixed in RRF 3.4.

Topher

@dc42 Ok, well I already ordered a few encoders from bourns. Ill try that out and report back.

Topher

@dc42 I just finished installing the new encoder. annnnnnd... It works perfectly! The new bourns encoders use 4 pulses and found it corrects the overlap issue I pointed out as well with the Fysetc encoder. When you're right, you're right, thanks. You've saved me a lot of trouble.