AMT103 Rotary Incremental Encoder connected with Bricklet

[AMT103 Encoder - Bricklet]

Hello!

I recently procured an AMT103 rotary incremental encoder for a brushless motor.

The outputs of the encoder are the A, B, and X channels, as shown in this photo and the corresponding CMOS voltage square waveforms are presented in this photo. For my project, I use 2048 PPR.

I want to connect the outputs of the encoder on a Bricklet. What bricklet would you suggest for this application? I was thinking of the IO-4 Bricklet 2.0 as a choice. Would this work?

 

Thanks a lot!

bearbeitet June 22, 2024 at 12:03 von AMT103 Encoder - Bricklet

[MatzeTF]

I’m only getting an error when trying to view those photos, but I see no reason why the IO-4 Bricklet 2.0 shouldn’t be able to read a rotary encoder’s signals. The bricklet’s API has a function to read all four inputs at the same time, so you shouldn’t have a problem with signals changing while reading them.

[photron]

The Industrial Counter Bricklet has a mode to read quadrature encoders like yours:

https://www.tinkerforge.com/en/doc/Hardware/Bricklets/Industrial_Counter.html

But it requires a higher voltage range that your encoder can provide. You could us a transistor at the outputs of your encoder to match the voltage level required by the Industrial Counter Bricklet.

[fridolin11]

@photron I am using the Industrial Counter Bricklet to read an AB Encoder and it works okayish but the position tends to drift over a longer time. I am not sure if too many pulses are registered or if some are skipped. I am using a linear encoder with a resolution of 0.005 mm (full AB period is 0.02 mm) and with speeds of max. 10 mm/s. So the max frequency is with 2 kHz well below the specified 4 Mhz. In my application I constantly drive back and forward with an amplitude of about 10 mm and I need the encoder to keep track of the location.

Could it be that the bouncing of the signal causes errors? I found the following solution to bouncing on wikipedia, sorry that it is in german:

"Wenn der Inkrementalgeber genau auf der Grenze einer Flanke steht, so können durch kleinste Erschütterungen oder andere Effekte (Tastenprellen, elektromagnetische Störungen) zusätzliche Impulse auftreten. Sogenannte Schritttabellen eliminieren Fehler durch Mehrfachimpulse an den Schaltzeitpunkten: Angenommen, B stehe auf 1 und A wechsele von 1 auf 0 und prelle dabei: A_mem und B_mem sollen die gespeicherten Werte vor einer neuen Flanke sein. Beim ersten Wechsel von A auf 0 wird anschließend A_mem = 0 und B_mem = 1 gespeichert. Wechselt jetzt A wieder auf 1 so wird kein Impuls gezählt, weil das Aktuelle B = B_mem ist. Solange sich B nicht verändert hat, dürfen Flanken bei A nicht mehr gezählt werden. Kurz gesagt: Die Logik setzt das Apriori-Wissen, dass nach einem Wechsel von A erst ein Wechsel von B kommen muss (und umgekehrt) um. Dies gilt auch bei der Drehrichtungsumkehr."

If something like that is already implemented than I suspect, that I need to upgrade to another more premium Encoder. I already changed from one with a 0.001 mm resolution to the 0.005 mm one and the drifting got better but has not completely vanished.

[borg]

There should be no drift(*). How did you connect the encoder and how did you configure the Bricklet?

(*): The only way you should be able to introduce drift is if the signal is not unambiguous anymore. For example if the high voltage is normally 24V, but if it starts to bounce back and force with high frequency the high voltage only goes up to 5V or so. In that case it can easily happen that the Bricklet starts to miss transitions.