Quadratur Decooder/Zähler als eigenständiges IC - heutzutage (2021) erhältlich?

Falk B. schrieb:
> Sowas kann man in einem kleinen Mikrocontroller nachbauen, der dann per
> UART oder I2C die Daten zur Verfügung stellt.

Dafür sind z.B. die dsPIC-Mikrocontroller sehr gut geeignet, da sie 
einen Quadratur-Decoder in Hardware besitzen. Damit habe ich schon 
mehrfach Projekte mit Drehgebern realisiert. Die dsPICs gibt's in 
verschiendenen Gehäuseformaten und Pincounts, sogar bastlerfreundlich in 
DIP. Einige PIC24EP-Typen haben dieses Feature auch, kann man hier 
leicht herausfiltern: 
https://www.microchip.com/maps/Microcontroller.aspx

Falk B. schrieb:
> Sowas kann man in einem kleinen Mikrocontroller nachbauen, der dann per
> UART oder I2C die Daten zur Verfügung stellt.

Das kommt wohl auf die (noch unbekannte) maximale Drehzahl an.

> Das kommt wohl auf die (noch unbekannte) maximale Drehzahl an.

Das wuerde ich auch so sagen. So macht es keinen Sinn ueber sowas 
nachzudenken.

> Dafür sind z.B. die dsPIC-Mikrocontroller sehr gut geeignet, da sie
> einen Quadratur-Decoder in Hardware besitzen.

Es duerfte kaum eine MCU Familie geben wo es sowas nicht gibt.

Olaf

So, ein paar Salamischeiben bin ich ja noch schuldig...

Hab ein Oszi aufgetrieben.
Frequenz an einem der beiden Encoder-Ausgänge A oder B: max. 300Hz.
Hertz, nicht kHz!
Lächerlich niedrig.

Das soll der Programmierer mal schön in Software machen.

Das kann ich ihm als proof-of-concept sogar in Arduino vorlegen.

Die interne Interpolation des AEDR8712 ist auf 8fach gestellt.
Die Frequenz könnte sich also noch höchstens verdoppeln, immer noch 
lächerlich niedrig.

Tut mir leid, daß ich die Frage nach dem externen IC überhaupt gestellt 
habe.

Viele Grüße
Tom.

TomH schrieb:
> wer's schnell braucht, nimmt einen
> STM32.

Aber nur dann, wenn er Scheuklappen trägt und sich nicht dafür 
interessiert, daß die Chips von anderen Herstellern ebenfalls sowas 
gelegentlich eingebaut haben.

W.S.

TomH schrieb:
> das A/B-Encodersignale
> und das Indexsignal in einem Auf-Ab-Zähler zählt

Das kommt sehr auf den Verwendungszweck an, es gibt im Wesentlichen 2 
Sorten:

1. Eingabelement als Potentiometer-Ersatz - niedrige Auflösung, 
Zähl-Frequenz im kHz-Bereich, Zuverlässigkeit ziemlich egal

2. Positionserfassung für NC/CNC-Maschinen - hohe Auflösung, Frequenz 
bis MHz, Schrittverluste dürfen nicht passieren

Mit hier empfohlenen Zählern für max 25 kHz kann man keine 
Bearbeitungsmaschine betreiben. Für manuelle Eingaben sind andrerseits 
1400 Schritte stark übertrieben. Es ist also nicht klar was der TO will 
und braucht.

Georg

Georg schrieb:
> Mit hier empfohlenen Zählern für max 25 kHz kann man keine
> Bearbeitungsmaschine betreiben. ...

Es sind max. 300 Hz (dreihundert Hertz).
Nix mit "... bis MHz" - kannst dich wieder hinlegen ;-)

Ich will die Diskussion nicht verlängern oder erst richtig lostreten - 
andererseits möchte ich die fehlenden Salamischeiben nicht schuldig 
bleiben und beschreibe die Anwendung.

Es ist keine Privat-Bastelei, sondern ein Neben-Produkt in unserer 
Firma. Die Firma ist sehr klein, das Entwicklungsteam auch: Einer, der 
die Elektronik designt, einer, der programmiert, und ich, der die 
Mechanik designt und das Gesamtkonzept verbrochen hat. Das Produkt hat 
auch schon Entwicklungsstufen hinter sich, und es müssen Aufträge in 
gewissem Zeitrahmen erfüllt werden. Vorschläge wie "laß es bleiben" oder 
"fang das doch ganz anders an" werde ich nicht umsetzen können.

Es handelt sich um einen Stellantrieb.
Eine Art "Zeiger" mit einer 3mm-Scheibe vorndran bewegt sich knapp über 
der lichtempfindlichen Fläche von 64x64mm einer Kamera an einem 
Elektronenmikroskop. Die Scheibe fängt den Nullstrahl bei 
Beugungsaufnahmen. Sie soll aus dem Bild gefahren werden können, aber 
auch wiederholgenau in die Bildmitte zurückgefahren werden können. Wie 
wiederholgenau? Naja, so 0,1mm...
Der Zeiger ist ca. 60mm lang, seine Achse muß deutlich außerhalb des 
Bildes sein, und nach einer ca.45°-Drehung dürfen weder Scheibe noch 
Zeiger das Bild stören. Das diktieren die Platzverhältnisse.

Die momentane Lösung:
Ein Schneckenantrieb, dessen Lagerspiel überall durch Federdruck 
rausgenommen ist. Wirklich am Endabtrieb, auf dem Schneckenrad, sitzt 
die Encoderscheibe mit 1400CPR, und wird von der AEDR8712 abgetastet.
Dieser Endantrieb bewegt sich mit geschätzten 2-3 Sekunden für die 
Vierteldrehung. Wie gesagt, max. Frequenz eines Encoder-Kanals 300Hz. 
Wie schon von jemand anders bemerkt, das sind 1,2kHz, mit denen 
Phasenwechsel zu verarbeiten sind.

Nun noch einige Erkenntnisse aus den Diskussionen hier in der Firma:
- Der Programmierer, jetzt nochmal auf die Software-Lösung angesprochen, 
verwehrt sich heftig dagegen. Das hätte er in der Vergangenheit schon 
probiert, und es kam nur Sch...e dabei raus. Der Controller hat auch mit 
der USB-Kommunikation einiges zu tun. Ich weiß jetzt natürlich nicht, ob 
Interrupt oder Polling oder irgendwas...
- Der weiter oben erwähnte IC LS7366 scheint doch lieferbar zu sein. Der 
Preis von gut 5€ schockt uns nicht.
- Ich hab natürlich  doch gleich mal mit dem Arduino rumgestöpselt. Aber 
so trivial ist es nicht. Hatte sofort mit Schrittverlust zu kämpfen. 
Aber da kann ich noch ein bißchen weiterspielen, und eigentlich möchte 
ich niemanden die x-te Diskussion um die Programmierprinzipien für 
Drehgeber-Auswertung zumuten...

So, morgen hab ich erstmal Urlaub und bin zuhause auch mit dem 
Geburtstag meiner kleinen Tochter beschäftigt. Werde also wohl den 
ganzen Tag hier nicht reinschauen und antworten.

Also bis übermorgen!
Tom.

TomH schrieb:
> Hatte sofort mit Schrittverlust zu kämpfen

Das kann bei 300 Hz einfach nicht sein. Ein Timer, der die Eingänge alle 
ms oder etwas weniger abfragt muss absolut zuverlässig zählen.

TomH schrieb:
> Das hätte er in der Vergangenheit schon
> probiert, und es kam nur Sch...e dabei raus

Das sehe ich als Problem eurer Firma, nicht als technische 
Undurchführbarkeit. Aber was richtig ist: wenn ihr etwas einfach nicht 
beherrscht solltet ihr tatsächlich die Finger davon lassen, da gibt es 
mit einem externen Zähler-IC weniger Fehlermöglichkeiten, das kann man 
ja höchstens falsch auslesen, Verzählen passiert nicht. Ich habe solche 
ICs angefangen beim 74LS2000 bei hundert mal höheren Frequenzen für 
Messmaschinen in der Autoindustrie eingesetzt und die haben den ganzen 
Arbeitstag lang korrekt gezählt.

Georg

> Das soll der Programmierer mal schön in Software machen.

DAs wuerde ich ja wohl auch so sehen. Ich hab im Mega8 mal eine 
komplette
Achsensteuerung (Geschwindigkeit, Position, Rampen) eines Motors 
gemacht. TimerIRQ fuer die Abstastung lief mit 40khz.

Wobei mir deine 300Hz etwas niedrig vorkommen. Wenn das die Frequenz 
eines A oder B Kanals ist dann brauchst du 1.2khz im Timer. Also alles 
vollkommen lachhaft.

Kacke an den AVRs in dem Zusammenhang ist aber das man keine 
Interruptprioritaeten vergeben kann. Da muss man sich dann je nach dem 
was da sonst noch drin laeuft schonmal einen abbrechen.

Olaf

Z.B. TMC424 von Trinamic: 
https://www.trinamic.com/products/integrated-circuits/details/tmc424/. 
Verfügbar aber teuer.

Harald W. schrieb:
> Bei der von
> Dir geforderten hohen Präzision sollte auf jeden Fall eine Zustands-
> auswertung und keine Interruptauswertung gemacht werden

Da kommt man sich hier im Forum vor wie ein Prediger in der Wüste, der 
die Felswände überzeugen will. Forum für alternative Elektronik eben, 
natürlich auch LEDs ohne Vorwiderstand, Busse ohne GND usw. usw.

Georg

Peter D. schrieb:
> Der Pin-Change Interrupt erkennt nur, daß ein Phasenwechsel auf einer
> der beiden Leitungen erfolgte

Der erkennt genauso, wenn das Signal an der Taktflanke "prellt" oder der 
Encoder am Übergang rumeiert.

Axel G. schrieb:
> Um mal auf die Anfangsfrage zurück zu kommen. Git es schon:
>
> https://www.ichaus.de/product/iC-MD

Der Link ist ein schönes Beispiel dafür, die Anforderungen des TO 
überhaupt nicht beachtet oder verstanden zu haben. Warum soll er denn 
LVDS oder 40 MHz bezahlen, mit welchen Lieferzeiten, zu welchem Preis?

Sofern es der hausinterne Programmierer nicht in Software gebacken 
bekommt, reicht doch ein kleiner 8-pol. µC (ATtiny, s.o.), um eine 
externe Zählerlösung zu erhalten. Kosten < 1 Euro, Aufwand für 
Platinenlayout minimal.

Ich will mal nochmal abrunden und versuchen, die Gemüter zu beruhigen. 
Wird nicht gelingen, es gibt immer welche, die sich streiten wollen.

1. Externer IC

Danke für die Vorschläge.
Wir werden zunächst versuchen, den LS7366 in SSOP zu bekommen. Der hat 
handliche 14 Beine. Selbst wenn wir nur auf abenteuerlichen Wegen 
einmalig  ca. 20 Stück davon beschaffen können, das beschriebene Produkt 
ist ein absolutes Nischen-Ding, das reicht uns.
Die beiden anderen Vorschläge sind deutlich komplexer, man kann sagen 
Overkill. Selbst wenn das Argument "teuer" bei uns nicht so schlimm 
wäre...

Kleine Anekdote am Rande:
Das Vorgängerprodukt arbeitete mit dem Avago HCTL-2032. Weil der vor 
Jahren auch schon schwierig zu beschaffen war, wurde panisch ein Vorrat 
beschafft. Leider irrtümlich in DIL-40 statt in SSOP... davon haben wir 
jetzt ca. 40 Stück herumliegen... können wir irgendwann handverlesen auf 
ebay vergolden...

2. Programmierer

Hört auf, auf dem herumzuhacken. Der Umgang mit ihm ist ganz normaler 
Umgang mit Kollegen. Ich muß ihm ja die Aufgabenstellung nahebringen, er 
macht sich seinen Reim drauf. Der macht sein Zeug super, und ich kann 
nicht beurteilen, ob er mit den negativen Erfahrungen mit 
Polling/Interrupt in seinem Gesamt-Setting recht hat oder einem Irtum 
aufgesessen ist.
Nur wenn man alles selber macht, hat man die Schnittstelle zwischen den 
Kollegen nicht, aber man ist trotzdem nicht gegen Holzwege und Irrtümer 
gefeit.

3. Arduino-Spielerei

Bitte keine Pickel bekommen, es ist ja nur eine "Demo", die ich da für 
den Programmierer zusammenstöpsle.

Übrigens funktioniert es mittlerweile ziemlich gut.
Problematisch ist bei mir sicher die Rückmeldung der Position über die 
serielle Schnittstelle. Vor allem bei Erreichen des Index-Signals wurde 
zunächst ständig das Wort "Index" rausgerattert, in der vollen Frequenz 
der Main Loop. Das hat alles gestaut und durcheinandergebracht. Seit ich 
nur noch ein bescheidenes "I" neben der gelegentlichen Positionsmeldung 
anzeige, ist es ziemlich fehlerfrei geworden.

Das Konstrukt ist ungefähr so:

1

void loop() 

2

{

3

  static int encoderTimeout;

4

5

  Position_alt = Position;

6

  Position = Position + encoderImpuls();

7

8

  if (Position == Position_alt) encoderTimeout++;

9

10

  if (encoderTimeout > 1000)

11

  {

12

    encoderTimeout = 0;

13

    Serial.print(Position);

14

    if (digitalRead(ENC_I) == HIGH) Serial.print(" I");

15

    Serial.println();

16

  }

17

18

  MotorSteuern(JoystickLesen());

19

}

20

21

int encoderImpuls()

22

{

23

  static byte state=0;

24

  state= state<<2;    // Bits um zwei Stellen nach links schieben

25

  if (digitalRead(ENC_A)) bitSet(state,1);  // Eingang A abfragen und Bit1 setzen

26

  if (digitalRead(ENC_B)) bitSet(state,0);  // Eingang B abfragen und Bit0 setzen

27

  state= state & 0xF;   // Nur die unteren 4 Bits behalten

28

  switch(state)

29

  {

30

    case 0b0000:

31

    case 0b0101:

32

    case 0b1010:

33

    case 0b1111: return 0; // keine Änderung an den Eingängen

34

    case 0b0001:

35

    case 0b0111:

36

    case 0b1110:

37

    case 0b1000: return 1; // links Impuls an den Eingängen

38

    case 0b0010:

39

    case 0b1011:

40

    case 0b1101:

41

    case 0b0100: return -1; // rechts Impuls an den Eingängen

42

  } 

43

}

Die Sache mit dem Timeout ist natürlich unsauber (und eigentlich eher 
für das Auswerten von handbetätigten Drehgebern gedacht). Es wird immer 
irgendeinen Moment geben, in dem die Taktsignale langsam genug kommen, 
um die serielle Ausgabe zuzulassen, und dennoch so schnell, daß während 
der seriellen Ausgabe was verschluckt wird. Aber tatsächlich 
funktioniert es so schon ganz gut.

> Das Vorgängerprodukt arbeitete mit dem Avago HCTL-2032. Weil der vor
> Jahren auch schon schwierig zu beschaffen war, wurde panisch ein Vorrat
> beschafft.

Hm..ich hab noch eine Handvoll HCTL-2000. Bin ich jetzt reich? :-)

Olaf

TomH schrieb:
> Die beiden anderen Vorschläge sind deutlich komplexer, man kann sagen
> Overkill.

Was ist denn an einem ATtiny25 oder 202 komplex oder Overkill? Das 
Programm dafür muß nur aufgespielt werden. AVR wird bei euch ja schon 
verwendet.

TomH schrieb:
> Selbst wenn wir nur auf abenteuerlichen Wegen
> einmalig  ca. 20 Stück davon beschaffen können,

Kurz gesucht. ATtiny25/45/85 gibt es bei Reichelt; ATtiny212 zum 
Beispiel bei Farnell 835 Stk. ab Lager < 50 ct.

Neueste Erkenntnis:
LS7366 ist tatsächlich nur auf extrem abenteuerlichen Wegen beschaffbar. 
Eigentlich gar nicht.

Ein Punkt mehr für die Software-Lösung.
Oder meinetwegen, wenns gar nicht anders geht, ja, einen ATtiny.

Falk B. schrieb:
> Entwicklungskosten 99,9% der Gesamtkosten.

Du tust so, als ob man da irgendetwas neu erfinden müsste.
Auch bei einem Chip, der von sich aus zählen kann, muss Layout und 
Softwareanbindung umgesetzt werden.

TomH schrieb:
> Ein Punkt mehr für die Software-Lösung.
> Oder meinetwegen, wenns gar nicht anders geht, ja, einen ATtiny.

Als ob man den nicht programmieren müsste. Wer das mit einem AT90 nicht 
hinkriegt, schafft das auch nicht mit einem ATtiny - eher noch weniger. 
Und Geld ist wohl auch nicht dafür verfügbar.

Georg

Georg schrieb:
> Als ob man den nicht programmieren müsste.

SPI-Prommer für AVRs gibt es doch wie Sand am Meer und ist wohl schon 
längst vorhanden.
Die paar Byte sind doch in 2 s im Chip.