ENCODER BUG? Fysetc 12864 G32 MBL screen Builtin function

Topher

I'm having some trouble with the encoder wheel with regards to making fine incremental adjustments during G32 MBL from the 12864 screen. A single click of the encoder is too coarse to make proper adjustments and the increments are inconsistent as each click encoder wheel can result in a different value applied to the Z. It's also a little dangerous too; If the encoder wheel lands between a click, the Z will jog at full speed in any direction potentially crashing into the bed. The Z will jog until the encoder wheel is centered on a click again. This happens when trying to adjust baby-stepping during a print, as well. During all other operations, the encoder otherwise works as it should.

I'm thinking this is a firmware bug, if so until it's addressed, Is there any way to add or alter the contents of the bed leveling screen (see photo) for 12864 screens? I have solved this issue for the baby-stepping by adding M290 increment buttons in my menu, if I can just add some buttons to increment the Z up or down by G1 commands now.

Running RRF 3.3.0 on Duet3 mini5 wifi

dc42

@leckietech it sounds to me that either you have a very poor encoder on that display, or the cable is picking up interference. Is the cable routed close to any stepper motor cables?

Topher

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

@leckietech it sounds to me that either you have a very poor encoder on that display, or the cable is picking up interference. Is the cable routed close to any stepper motor cables?

I'm not thinking so. Even while testing before I built these machines, with only 1 z motor connected on the bench, this was still a problem. The encoder seems to only struggle with live rotary adjustments on an active print but works perfectly otherwise. I'm running 6 of these identical printers with more to come and so far all 6 have the same issue. I do have the switches wired for normally closed (was your recommendation, thank you) and my chassis is grounded as well.

alankilian

@leckietech Do you know the part number of the encocder used?

The schematic shows the encoder outputs connected directly to the connectors.

I wonder if they require with pullup resistors?

Topher

@alankilian there is no part number on the encoder that I can see. I suppose it would be easy enough to solder a few 10k resistors to the A and B legs pulled up to 5v or 3.3. Ill give it a try once I get to work!

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?