Encoder Signal Spikes

Nutze die Timer-Pollmethode zum Verarbeiten von Encodern.

Siehe Peda (Peter Dannegger) im begleitenden Artikel auf MC Forum.


Der original Code von Peter Dannegger (peda) ist dieser:
# Beitrag "Drehgeber auslesen"
# Beitrag "Drehgeber/Encoder 1-, 2- oder 4-schrittig"


Alles in einem Artikel gibt es hier:
# 
https://www.mikrocontroller.net/articles/Drehgeber#Solide_L.C3.B6sung:_Beispielcode_in_C

Karl M. schrieb:
> Nutze die Timer-Pollmethode zum Verarbeiten von Encodern.

Für handbediente Encoder ok.

Für Motor Encoder dürften die Timer der ARM (z.B. STM32) besser geeignet 
sein. Die können in Hardware dekodieren.
Die kommen quasi ohne Prozessorlast klar.

Arduino Fanboy D. schrieb:
> Die kommen quasi ohne Prozessorlast klar.

Ja was jetzt quasi? Kommen die mit oder ohne Last klar? Oder mit ohne?

Jacko91 schrieb:
> Anregungen wie ich die Encodersignale entstört bekomme?

Bei einer korrekten Auswertung des Encoders machen solche Stör-Impulse 
kein Problem.

Dein Problem ist also deine Auswertungsmethode, wohl flankenbasiert.

MaWin schrieb:
> Oder mit ohne?
Auslesen der Timer und Über-/Unterläufe abhandeln wird Prozessorzeit 
kosten.

Aber das weißt du doch genau!
Warum fragst du so doof?

> Für handbediente Encoder ok.
> Für Motor Encoder dürften die Timer der ARM (z.B. STM32) besser geeignet

Quatsch mit Sosse. Ich hab schon solche Motorencoder in Software mit dem 
Mega8 gemacht. Da lief der Timer mit 40khz fuer den Encoder. Ausserdem 
waren Stromregelung, Geschwindigkeitsregler und Lageregler auch noch 
drin. Damit konnte man so mit 1m/s auf 0.1mm positionieren

Olaf

Wow, danke für den vielen Input.


So Oszi Bild eines Channels im Anhang. Die Encoder habe ich derzeit an 
3.3V VCC betrieben. Zusätzlich habe ich 4.7k Widerstände pro Channel auf 
GND angeschlossen. Daher auch nicht 3.3V Amplitude sondern ca 2.2V beim 
Bild des Oszis.

Um den Störungen bei der Auswertung entgegen zu wirken haben ich statt 
Interrupt basierte Zählung auf abtasten der Digitalen Pins zu festen 
Frequenzen gewechselt. Dazu nutze ich die Lib Altencoder. (hier noch der 
Thread: https://forum.pjrc.com/threads/38736-Encoder)


Ein händischer Schaltplan ist auch angehängt.

Danke

Lothar M. schrieb:

> Du hast da gleich 6 von den Encodern dran?

Sorry, das war der sample sketch zu der library.
Ich nutze derzeit nur einen Encoder.

dann zeichne doch mal eben beide Kanäle gleichzeitig auf. Das Oszi wird 
ja zwei Kanäle haben...
Wofür sind denn die 4.7K gegen GND? Ich hätte eher 1K gegen 3V3 gelegt.

Jacko91 schrieb:
> Dort ist eine Störung zu erkennen die leider zu einem
> flaschen Erkennen eine Flanke führt

Das spielt keine Rolle: bei korrekter Auswertung führt der Spike (der ja 
aus 2 ! Flanken besteht) entweder dazu, dass der Zähler sich um 1 ändert 
und sofort wieder zurück, oder der Spike wird komplett übersehen weil zu 
kurz. Daher arbeiten Positioniersysteme mit Quadratur-Encodern auch im 
industriellen Umfeld Stunden und Tage ohne sich zu verzählen, wovon man 
sich an Millionen CNC-Maschinen überzeugen kann.

Für eine Eingabe als Poti-Ersatz ist das Verzählen zwar ziemlich egal, 
aber es spricht ja auch nichts dagegen, die Encoder-Signale so 
auszuwerten wie es dem Stand der Technik seit Jahrzehnten entspricht. 
Und zusätzlich spricht auch nichts dagegen solche Störungen zu 
vermeiden, z.B. durch passende Verkabelung.

Übel wird es natürlich, wenn sowohl die Hardware als auch die Auswertung 
(egal ob durch Hard- oder Software) fehlerhaft entworfen sind, was hier 
wohl der Fall ist.

Georg

Jacko91 schrieb:
> encoder.ino (762 Bytes, 7 Downloads)

Oh, eine Salamischeibe mehr.

Die Encoderlib von luni verliert wohl Impulse.

https://forum.pjrc.com/threads/45672-Can-a-teensy-3-5-handle-5-encoders-and-5-PIDs

Er versteht ja nichtmal, warum man 16 bit volatile Werte auf 8 bit 
Prozessoren nicht ohne locking lesen und schreiben darf.

georg schrieb:
> Jacko91 schrieb:
>> Dort ist eine Störung zu erkennen die leider zu einem
>> flaschen Erkennen eine Flanke führt
>
> Das spielt keine Rolle: bei korrekter Auswertung führt der Spike (der ja
> aus 2 ! Flanken besteht) entweder dazu, dass der Zähler sich um 1 ändert
> und sofort wieder zurück, oder der Spike wird komplett übersehen weil zu
> kurz. Daher arbeiten Positioniersysteme mit Quadratur-Encodern auch im
> industriellen Umfeld Stunden und Tage ohne sich zu verzählen, wovon man
> sich an Millionen CNC-Maschinen überzeugen kann.
>
> Für eine Eingabe als Poti-Ersatz ist das Verzählen zwar ziemlich egal,
> aber es spricht ja auch nichts dagegen, die Encoder-Signale so
> auszuwerten wie es dem Stand der Technik seit Jahrzehnten entspricht.
> Und zusätzlich spricht auch nichts dagegen solche Störungen zu
> vermeiden, z.B. durch passende Verkabelung.
>
> Übel wird es natürlich, wenn sowohl die Hardware als auch die Auswertung
> (egal ob durch Hard- oder Software) fehlerhaft entworfen sind, was hier
> wohl der Fall ist.
>
> Georg

Die verwendete Lib. (AltEncoder.h) ist an 
https://www.mikrocontroller.net/articles/Drehgeber#Solide_L.C3.B6sung:_Beispielcode_in_C 
angeleht. Würden Sie das nicht als gute Auswertung einstufen? Sonst 
Alternative Quellen?

MaWin schrieb:
> Jacko91 schrieb:
>> encoder.ino (762 Bytes, 7 Downloads)
>
> Oh, eine Salamischeibe mehr.
>
> Die Encoderlib von luni verliert wohl Impulse.
>
> 
https://forum.pjrc.com/threads/45672-Can-a-teensy-3-5-handle-5-encoders-and-5-PIDs
>
> Er versteht ja nichtmal, warum man 16 bit volatile Werte auf 8 bit
> Prozessoren nicht ohne locking lesen und schreiben darf.

Versteh ich leider nicht ganz, die variable counter in der AltEncoderlib 
ist doch int, also 32bit. Oder was meinst du genau?

äxl schrieb:
> dann zeichne doch mal eben beide Kanäle gleichzeitig auf. Das Oszi
> wird
> ja zwei Kanäle haben...
> Wofür sind denn die 4.7K gegen GND? Ich hätte eher 1K gegen 3V3 gelegt.

Dies hatte ich aus 
(https://electronics.stackexchange.com/questions/271869/removing-digital-noise-on-quadrature-encoder-signals). 
Die Idee ist es etwas mehr Last auf die Leitung zu bringen. Wozu wäre 
der pullup gedacht?

Lothar M. schrieb:
> Jacko91 schrieb:
>> Ich nutze derzeit nur einen Encoder.
> Dann zeig doch mal deinen Code, der deinen Fehler produziert...

Ich nutze den BeispielCode, eben nur mit einem Encoder angeschlossen.

Danke

Hey,
this is the code I use:

1

#include "AltEncoder.h"

2

3

AltEncoder::Encoder* encoderList[] =

4

{new AltEncoder::Encoder(34,33),

5

  nullptr

6

};

7

8

void setup() 

9

{

10

  Serial.begin(0);

11

  AltEncoder::Controller::begin(encoderList, 5/*µs*/);   // choose a sampling period which is at least a factor of two smaller than the shortest time between two encoder signal edges. 

12

13

}                                            

14

void loop() 

15

{

16

  for(int i = 0; i<1; i++) 

17

  {

18

    Serial.println(encoderList[i]->counter);

19

  }

20

  delay(5);

21

}

Falk B. schrieb:
> Jacko91 schrieb:
>
>>> Er versteht ja nichtmal, warum man 16 bit volatile Werte auf 8 bit
>>> Prozessoren nicht ohne locking lesen und schreiben darf.
>>
>> Versteh ich leider nicht ganz, die variable counter in der AltEncoderlib
>> ist doch int, also 32bit. Oder was meinst du genau?
>
> Man muss die Variable atomar lesen und schreiben.
>
> https://www.mikrocontroller.net/articles/Interrupt#Atomarer_Datenzugriff
>
Das Teensy 3.5 nutzt einen ARM Cortex M4, 32Bit CPU. Memory Access ist 
32Bit. Dürfte also kein Problem darstellen.

Lothar M. schrieb:
> Es kommt auf den Ausgang deines Gebers an. Wenn das ein Open-Collector
> Ausgang ist, dann zieht der Ausgang nur nach GND. Und für den High-Pegel
> ist ein (externer) Pullup zuständig.

Es ist kein Open-Collector. Der IC am Encoder ist push pull.

Michael B. schrieb:
> Nein, du hast immer noch nicht verstanden, daß der verlinkte Artikel
> darauf hindeutet, daß IN der Library ein bug ist.

Okay, könntest du bitten etwas konkreter werden?

Lothar M. schrieb:
> Welcher denn? Und wie ist der versorgt?

Ist ein 24V China Motor 
https://de.aliexpress.com/item/32860097307.html?spm=a2g0x.search0104.3.30.548962f94j05WD&ws_ab_test=searchweb0_0%2Csearchweb201602_5_10065_10068_10547_319_317_10548_10696_10084_453_10083_454_10618_10304_10307_10820_10821_537_10302_536_10843_10059_10884_10887_321_322_10103%2Csearchweb201603_52%2CppcSwitch_0&algo_expid=74d9e7aa-981f-4ca1-aa23-49657c5f5099-4&algo_pvid=74d9e7aa-981f-4ca1-aa23-49657c5f5099.
24V für den Motor, 3.3V oder 5V für den Hall.

Michael B. schrieb:
> 5 dürfte zu kurz sein.

Das Encodersignal liegt bei ca 2kHz. Dann ist doch eine Abtastfrequenz 
von 200kHz deutlich ausreichend. Dürfte auch mit deutlich weniger 
fuktionieren.

Jacko91 schrieb:
> Der IC am Encoder ist push pull.

Dann ist jegliche Diskussion über Pullup/-down für die Katz!
Der Gedanke daran ist flüssiger als Wasser. Überflüssig.

Falk B. schrieb:

> Sicher, aber deine CPU wird bei 200kHz Interruptfrequenz arg ins
> Schwitzen kommen. Oder macht das dort eine reiner Hardwaredecoder?
>
>> Dürfte auch mit deutlich weniger fuktionieren.
>
> Dann probier das mal!

ja hab es mit 5khz betrieben. Funktioniert soweit gut. Ne ist ein 
Softwareinterrupt. Unnötig so eine hohe Interruptfrequenz zu haben. 5-10 
mal schneller als die Encodersignale sind sollte ausreichend sein. 
Absolut richtig. Erste Tests zeigen eine deutliche Verbesserung

Lothar M. schrieb:
> Arduino Fanboy D. schrieb:
>> Dann ist jegliche Diskussion über Pullup/-down für die Katz!
> Und die knapp 2,5V als Eingangspegel unerklärlich...

Dieser Pegel entsteht nur wenn ich den 4.7k anhänge. Ohne zusätzlichen 
Widerstand ist der Pegel auf 3.3V.

> Jacko91 schrieb:
>> 3.3V oder 5V für den Hall.
> Die Frage war aber nicht, wie kann der versorgt werden, sondern eben
> wie ist der versorgt? Ich weiß nicht, ob du da 5V oder 3,3V anlegst.

Stimmt wohl. Ich hab 3.3V dran.

> Jacko91 schrieb:
>> Ist ein 24V China Motor
>>
> 
https://de.aliexpress.com/item/32860097307.html?spm=a2g0x.search0104.3.30.548962f94j05WD&ws_ab_test=searchweb0_0%2Csearchweb201602_5_10065_10068_10547_319_317_10548_10696_10084_453_10083_454_10618_10304_10307_10820_10821_537_10302_536_10843_10059_10884_10887_321_322_10103%2Csearchweb201603_52%2CppcSwitch_0&algo_expid=74d9e7aa-981f-4ca1-aa23-49657c5f5099-4&algo_pvid=74d9e7aa-981f-4ca1-aa23-49657c5f5099
> Genau der hat aber die an dieser Stelle ganz üblichen Open Collector
> Ausgänge mit 10k Pullups. Und dann ist klar, warum da so ein lausiger
> Pegel rauskommt. Sorg da mal für anständige Verhältnisse.
>
> Mannmannmann, dass man sich jedes Salamischeibchen rausbetteln muss, das
> macht das Helfen echt schwer....  :-/

Sorry, du hast recht, das ist ein open collector.

Jacko91 schrieb:
> Sorry, du hast recht, das ist ein open collector.

Dann hängt man da evtl. einen stärkeren Pullup mit dran, wenn es nötig 
wird.
Aber keinen Pulldown.
Oder?

Falk B. schrieb:
> Lothar M. schrieb:
>> annmannmann, dass man sich jedes Salamischeibchen rausbetteln muss, das
>> macht das Helfen echt schwer....  :-/
>
> Dann sollte man es ab und an auch mal lassen und den Kandidaten
> weiterwurschteln lassen. Er muss gescheite Informationen liefern. Wenn
> er das nicht kann oder will, Pech gehabt!

Danke euch für die Hilfe, und sorry wenn ich nicht den vollen 
Informationsgehalt geliefert habe. Bitte um Nachsicht. Wird nächstes Mal 
voll umfänglich gemacht.

Falk B. schrieb:
> Jacko91 schrieb:
>> Dieser Pegel entsteht nur wenn ich den 4.7k anhänge. Ohne zusätzlichen
>> Widerstand ist der Pegel auf 3.3V.
>
> Das würde MIR zu DENKEN geben!

Hmmm. Also eigentlich hat man da ja dann einen Spannungsteiler. 10k 
Pullup und 4.7k Pulldown. Teilt die Spannung in ca 2.3V (zwischen 
Messpunkt und 3.3V) und 1V (zwiscchen Messpunkt und GND).