mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Absolutwertgeber (absolute rotary encoder) mit Arduino oder ESP32


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von ArduinoFanBoy (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Hallo zusammen,


ich bin auf der Suche nach einem Absolutwertgeber. Ich möchte mit dem 
Mikrocontroller (Arduino oder ESP32) die Drehposition bzw. den Winkel 
einer Lenkstange (ca. 3 Umdrehungen) ermitteln.

Als Spannung steht mir 5V oder 12V zur Verfügung.

Ich habe an einen Multiturn mit min. 10 Bit Auflösung oder einen 
Singleturn mit min. 12 Bit Auflösung gedacht.
Einen Singleturn würde ich dann über eine Umsetzung mit Zahnrädern so 
anbinden, dass dieser über die ca. 3 Umdrehungen eine akzeptable 
Auflösung pro Umdrehung bietet. Sehr viel lieber wäre mir aber ein 
Multiturn. Die Sensorerfassung soll möglichst robust erfolgen. Also z.B. 
optisch oder vllt magnetisch.

Für den Sensor habe ich etwa 200€ eingeplant und möchte möglichst einen 
IP64 Schutz.

Ich kenne mich mit diesen Sensoren aber überhaupt nicht aus. Daher weiß 
ich nicht worauf ich achten muss und was von meinen Kriterien vllt 
wichtig oder unsichtig ist. Ich habe z.B. Sensoren gefunden, die als 
Übertragung analog, Gray-Code, SSI / RS422 oder Bussysteme wie CanOpen, 
EtherCan verwenden. Aber was gibt es bei welcher Übertragung zu 
beachten? Wie wird z.B. bei analog der Multiturn übertragen? Wie 
funktioniert das bei SSI? Liest man da verschiedene "Register" des 
Sensors?

Ich hatte schon ein paar Kontakte mit chinesischen Firmen. Allerdings 
haben die alles Mögliche Angeboten von dem irgendwie gefühlt nichts 
passte (die haben auch Artikel angeboten die dann wieder inkr. waren :o) 
).

Für jegliche Hilfe, Tipps, Anregungen oder Typenbeispiele wäre ich sehr 
dankbar.


Grüße Daniel / ArduinoFanBoy!

von Arduino Missionar (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
ArduinoFanBoy schrieb:
> Für den Sensor habe ich etwa 200€ eingeplant und möchte möglichst einen
> IP64 Schutz.

Hallo mein Boy,
Du scheinst ja was großes vorzuhaben :-O
Ich würde dir unbedingt  IP68 empfehlen!

Die 8 am Ende steht für "Schutz gegen dauerndes Untertauchen"
Falls dein Projektle baden gehen sollte :-))

von gleich-geb-ich-dir, absolut (Gast)


Bewertung
0 lesenswert
nicht lesenswert
FRABA POSITAL

von Georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ArduinoFanBoy schrieb:
> Einen Singleturn würde ich dann über eine Umsetzung mit Zahnrädern so
> anbinden

Für 12 Bit müsste das aber völlig spielfrei konstruiert sein.

Georg

von ArduinoFanBoy (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Ja das stimmt. Evtl mit Zahnriemen. Aber das wären dann Feinarbeiten die 
ich im Nachgang noch ändern kann. Wichtig für mich wäre erstmal zu 
wissen auf welche Technik man am besten für das Auslesen setzt.

Hat niemand mit solchen Sensoren oder Gray-Code  SSI  CanBus 
Erfahrung?

von Schütze (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Was für Anforderungen hast Du denn sonst noch?
Verfügbare Spannungen?
Wie oft benötigst Du eine neue Position? (Refreshrate)
Was für eine absolute Genauigkeit benötigst Du? (Du sprichst immer nur 
von Auflösung)
Wie latenzfei brauchst Du die Position?

Für was soll die Position verwendet werden und worauf liegt der Fokus?

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
SSI mit Haidenhein oder Sick Stegmann Gebern habe ich schon gemacht und 
ist simples Bitbanging. Da das ein differentielles Signal ist, kann man 
das mit externem Inverter aus einem Ausgangspin (Clock) erzeugen.

Die Geber liefern Gray Code, der leicht in was binäres zu wandeln ist.

von ArduinoFanBoy (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Schütze schrieb:
> Verfügbare Spannungen?

ArduinoFanBoy schrieb:
> Als Spannung steht mir 5V oder 12V zur Verfügung.

Schütze schrieb:
> Wie oft benötigst Du eine neue Position?

30 mal pro Sekunde.

Schütze schrieb:
> Was für eine absolute Genauigkeit benötigst Du?

So genau kann ich das nicht sagen. Es soll eine Lenkung (Steuerrad / 
Lenkrad) digitalisiert werden und per Mikrocontroller weiterverarbeitet 
werden. Dementsprechend wird dann das Fahrzeug gesteuert 
(Außenboardmotor). Der Außenboardmotor wird per Schrittmotor "indirekt" 
gesteuert. Es ist also noch die normale Mechanik der Motorsteuerung 
vorhanden, diese wird aber zwischen Lenkstange und Mechanik per 
Mikrocontroller umgesetzt. Also Drive-by-Wire. Die Umsetzung der 
Steuerung ist kein Problem. Mir geht es an dieser Stelle "nur noch" um 
das Auslesen der Lenkung. Da die Steuerung per Außenboardmotor relativ 
ungenau ist, würde vermutlich eine Genauigkeit von 1° (360 Schritte) 
reichen. Ich möchte es aber etwas genauer und zumindest 0,5° erreichen.

Schütze schrieb:
> Wie latenzfei brauchst Du die Position?

Nach Möglichkeit < 20 ms.

Matthias S. schrieb:
> SSI mit Haidenhein oder Sick Stegmann Gebern habe ich schon gemacht und
> ist simples Bitbanging.

Das ist interessant. Ich kenne Bitbanging nur von Neopixeln bei dem die 
Daten Taktgenau rausgeschickt werden müssen. Habe das aber nicht selbst 
programmiert. Kannst du mir ein paar Infos mitteilen wie per SSI 
angebunden wird (physikalisch) und wie die Daten übertragen werden? 
Arbeitet SSI ähnlich wie eine RS232 Schnittstelle?
Nach meinem Verständnis wird Gray-Code über einzelne Adern aus dem 
Sensor ausgelesen? Also z.B. 10 Adern für 10 Bit. Oder verstehe ich das 
falsch?

Vielen Dank  schon mal für eure Beiträge.

von Harald W. (wilhelms)


Bewertung
0 lesenswert
nicht lesenswert
Arduino Missionar schrieb:

> Ich würde dir unbedingt  IP68 empfehlen!
>
> Die 8 am Ende steht für "Schutz gegen dauerndes Untertauchen"
> Falls dein Projektle baden gehen sollte :-))

Fall es sich um ein Fahrrad o.ä. handelt, fährt man damit
nur selten unterwasser. :-)

von Harald W. (wilhelms)


Bewertung
0 lesenswert
nicht lesenswert
ArduinoFanBoy schrieb:

> Ja das stimmt. Evtl mit Zahnriemen.

Da ist aber keinesegs spelfrei. Da müsstest Du schon etwas mit
vorgespannten Zahnrädern bauen.

von Schütze (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ArduinoFanBoy schrieb:
> ArduinoFanBoy schrieb:
>> Als Spannung steht mir 5V oder 12V zur Verfügung.

Sorry, habe ich übersehen.

ArduinoFanBoy schrieb:
> 30 mal pro Sekunde.

Ist ja human.

ArduinoFanBoy schrieb:
> Es soll eine Lenkung (Steuerrad /
> Lenkrad) digitalisiert werden und per Mikrocontroller weiterverarbeitet
> werden.

Ok, da kommt es wirklich nicht sonderlich auf Genauigkeit an. Der Mensch 
gleicht dann sowieso ziemlich viel mit seiner "Regelung" aus.

ArduinoFanBoy schrieb:
> Ich kenne Bitbanging nur von Neopixeln bei dem die
> Daten Taktgenau rausgeschickt werden müssen.

Mit jeder neuen Flanke legt der Geber ein neues Datenbit auf die 
Datenleitung. Ähnlich wie bei SPI. Man muss nur aufpassen dass man die 
Monoflopzeit einhält und natürlich auch schneller ist als diese.
Ziemlich einfach. Die erste fallende Flanke nach der Monoflopzeit ist 
normalerweise der Zeitpunkt wo der Geber dann die Position latcht.

Ich persönlich würde glaube ich bei diesen einfachen Anforderungen einen 
Resolver für 50 Euro kaufen. Ist zwar nicht digital, aber dann braucht 
man nur nen Mosfet um den Träger zu stellen und der ADC des uC latcht 
die zwei Analogsignale des Resolvers zum richtigen Zeitpunkt synchron 
dazu ab.
Das ist nur PWM + ADC Config im uC.
Dann noch atan2 und fertig ist der Singleturn-Winkel.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
ArduinoFanBoy schrieb:
> wie per SSI
> angebunden wird (physikalisch) und wie die Daten übertragen werden?

SSI ist bei meinen Drehencodern ein Datentransport in eine Richtung. Der 
MC gibt das Clock an den Sensor und der Sensor gibt ein differentielles 
Datensignal zurück.
Dabei sollte die Treiberleistung auf Clock ausreichen, um einen 
Optokoppler im Geber zu speisen. RS485 Bausteine z.B. können das.
die Auslesung des Sick Stegmann sieht so aus:
/* Read the Sick Stegmann Encoder AG661
 * This is done by bringing the clock low first - After rising the clock again,
 * the first bit is sent by the encoder. 24 bits are sent followed by the PF bit 
 * indicating a Power fail. A break with a minimum of 20 uS will reset the encoder to start
 * 
 */
void Read_Angle(void) {
uint8_t n;
uint32_t temp = 0;
  ENCODER_CLOCK_PORT &= ~(1 << ENCODER_CLOCK1_PIN);   // initial clock low
  _delay_us(5);
  for (n=0;n<25;n++) {
    ENCODER_CLOCK_PORT |= (1 << ENCODER_CLOCK1_PIN);  // clock high
    _delay_us(5);
    temp <<= 1;
    if (bit_is_set(ENCODER_PIN,ENCODER_RX1_PIN)) temp |= 1;
    ENCODER_CLOCK_PORT &= ~(1 << ENCODER_CLOCK1_PIN);  // clock low
    _delay_us(5);
  }
  ENCODER_CLOCK_PORT |= (1 << ENCODER_CLOCK1_PIN);  // clock high
    if (temp > 0x01ffff00) fastFlags.alarmSensor1 = TRUE; 
    else fastFlags.alarmSensor1 = FALSE;
// now convert gray to binary
  for (n=1;n<32;n=2*n){
      temp = temp ^ (temp >> n);
   }
// mask out rotation and angle and fill the globals
  rotationValue =(uint16_t) ((temp & 0x01ffe000) >> 13);
  angleValue =(angleValue + (uint16_t) ((temp & 0x00001ffe) >> 1)) >> 1;  
//  _delay_us(100);
}

: Bearbeitet durch User
von ArduinoFanBoy (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Oh super. Eure beiden Beiträge helfen mir sehr weiter. Ich komme heute 
nicht mehr dazu....schaue mir die Beispiele aber morgen an.

Daumen hoch schon mal!

von Μαtthias W. (matthias) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert

von Georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ArduinoFanBoy schrieb:
> würde vermutlich eine Genauigkeit von 1° (360 Schritte)
> reichen

Oder weniger. Da könnte man auch über ein Präzisions-10Gang-Poti 
nachdenken, das wäre maximal einfach. Aber das musst du wissen, 12bit = 
0,025% ist natürlich geiler.

Georg

von ArduinoFanBoy (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Schütze schrieb:
> bei diesen einfachen Anforderungen einen Resolver für 50 Euro

Danke für den Hinweis. Ich hatte bei meiner Recherche auch einen 
Resolver in Betracht gezogen. Vllt bin ich wegen Singleturn oder der 
extra aktiven Hardware zum Anbinden des Sensors davon ab.

Ich hatte gestern noch einige Sensoren gefunden und viele sind z.B. mit 
Modbus. Ein Bus der ebenfalls seriell arbeitet. Was mir nicht bekannt 
war: z.B. Modbus arbeitet auch seriell, aber mit anderen Pegeln. Nicht 
TTL (Transistor-Transistor-Logik) sondern differentielles Signal (wohl 
robuster gegen Interferenzen). Für Modbus soll man auf jeden Fall einen 
Treiber benötigen.

Matthias S. schrieb:
> Der MC gibt das Clock an den Sensor und der Sensor gibt ein differentielles 
Datensignal zurück.

...bedeutet?: Auch SSI gibt ein differentielles Signal zurück und ich 
benötige ebfalls einen Treiber oder kann ich die Daten direkt mit dem 
Arduino / ESP32 verarbeiten?

Unterm Strich würde ich von einem Bussystem absehen und per Gray-Code / 
SSI den "einen" Sensor auslesen wollen.

Μαtthias W. schrieb:
> Sowas? https://www.ifm.com/de/de/product/RM9003

Ja genau. Nur dann ohne CAN und nach Möglichkeit unter 200€. Aber danke 
für den Link. Endlich mal eine Seite auf welcher man auch Preise genannt 
bekommt. Ich hatte die Artikel alle durchgeschaut. Viel interessantes. 
Leider alles ab ca. 250,- aufwärts. Werde ich bei der Bestellung aber in 
die engere Auswahl nehmen.


Mich würde aktuell noch am ehesten die Anbindung per SSI interessieren. 
Viel verständnisvolles habe ich im Netz aber nicht gefunden. In einem 
Beitrag ging es um die direkte Anbindung von SSI. Jemand schrieb dort:
"Bei Arduino Mega 2560 sind die seriellen Schnittstellen durch fehlende
Clock-Anschlüsse kastriert. Da SSI-Schnittstellen den Clock benutzen, 
würde ich sagen nein."

Also benötige ich auf jeden Fall einen Treiber?

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
ArduinoFanBoy schrieb:
> ...bedeutet?: Auch SSI gibt ein differentielles Signal zurück und ich
> benötige ebfalls einen Treiber oder kann ich die Daten direkt mit dem
> Arduino / ESP32 verarbeiten?

Auf meiner Platine sind sowieso Inverter für SSI Clock Sender, da habe 
ich einen als Empfänger genommen und die Data+ ausgewertet. Aber man 
kann, wie o.a., auch RS485 elektrisch kompatible Empfänger benutzen. 
Geht dann an einen beliebigen Pin am MC, wenn man Bitbanging macht.
Dummerweise benutzen nicht alle SSI System die gleiche Anzahl von Bits, 
so das ich für Haidenhein eine andere Routine nehme als für den Sick 
Stegmann.
Insgesamt ist SSI sehr einfach gestrickt. Ich hänge mal das Datenblatt 
des Encoders an, da wird hinten SSI beschrieben.

: Bearbeitet durch User
von ArduinoFanBoy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Matthias S. schrieb:
> Auf meiner Platine sind sowieso Inverter für SSI Clock Sender, da habe
> ich einen als Empfänger genommen und die Data+ ausgewertet.

Der fehlt mir wohl. Frage ist: warum haben manche Encoder Data+ und 
Data- sowie Clock + und Clock - wenn ich doch vom Encoder nur Lese.

Wie hier z.B.:
https://idencoder.en.made-in-china.com/product/wKCEboelMpYs/China-Megnetic-Multiturns-12-13bits-Gray-Code-or-Binary-Code-Ssi-Interface-Absolute-Rotary-Encoder.html

Ich kenne das von Display's: Die werden z.B. per SPI angesprochen aber 
haben nur eine Richtung (MOSI -> Daten zum Display). Bei dem Sensor 
benötige ich ja, wie du auch schriebst, nur die Datenrichtung vom Sensor 
zum mC.

Also kann ich für mich erstmal festhalten:
Da es sich bei SSI um ein differentielles Signal handelt ist ein 
direktes auslesen per Arduino / ESP32 nicht möglich -> ich benötige 
einen Treiber.

Ich habe bei dem Hersteller "Idencoder" noch folgendes gefunden:
https://www.idencoders.net/absolute-rotary-encoders/serial-ssi-absolute-encoders/gray-interface-absolute-rotary-encoder.html

Wenn ich es richtig interpretiere, dann werden diese Encoder per 
Gray-Code ausgelesen und haben je eine Leitung pro Bit?! Meiner Meinung 
nach sollte man direkt anschließen können. Mir geht es dabei um einen 
möglichst robusten Aufbau. Jede zusätzliche Hardware ist auch eine 
zusätzliche Ausfallmöglichkeit.

von Georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ArduinoFanBoy schrieb:
> warum haben manche Encoder Data+ und
> Data- sowie Clock + und Clock - wenn ich doch vom Encoder nur Lese

Das hat damit garnichts zu tun, das sind einfach differentielle Signale, 
um Störungen zu vermeiden. Natürlich braucht man dazu einen Empfänger 
pro Kanal.

Georg

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
ArduinoFanBoy schrieb:
> Meiner Meinung
> nach sollte man direkt anschließen können. Mir geht es dabei um einen
> möglichst robusten Aufbau. Jede zusätzliche Hardware ist auch eine
> zusätzliche Ausfallmöglichkeit.

Bei automotive Anwendungen steigt aber auch mit der Anzahl der nötigen 
Kabel die Ausfallrate derselben. Parallelinterfaces sind dabei tückisch, 
weil ein fehlendes Bit erstmal gar nicht auffällt.
Wie du schon richtig bemerkt hast, ist SSI sozusagen die SPI 
Einbahnstrasse. Der Master liefert das Clock und der Sensor liefert 
synchron dazu die Daten zurück. Als Transmitter und Receiver sind z.B. 
RS485 oder RS422 kompatible Treiber möglich - die Clock muss den 
Optokoppler durchsteuern können, wie im Sick Datenblatt beschrieben.

von ArduinoFanBoy (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Matthias S. schrieb:
> Als Transmitter und Receiver sind z.B.
> RS485 oder RS422 kompatible Treiber möglich - die Clock muss den
> Optokoppler durchsteuern können

Also würde ein Treiber wie dieser hier:
https://www.amazon.de/MAX485-module-RS-485-TTL-MTS1EU/dp/B017A676EY
...inkompatibel sein da kein Clock berücksichtigt wird?

von minifloat (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ArduinoFanBoy schrieb:
> Also würde ein Treiber wie dieser hier:
> https://www.amazon.de/MAX485-module-RS-485-TTL-MTS1EU/dp/B017A676EY
> ...inkompatibel sein da kein Clock berücksichtigt wird?

Fünf Euro für des bisschen Platine und Hühnerfutter? Wucher. Ehrlich, 
zwei nackte MAX485 oder SN75176 gibt's günstiger.

Matthias S. schrieb:
> die Auslesung des Sick Stegmann sieht so aus:

Sag mal, warum benutzt du nicht die SPI-Schnittstelle? Ich dachte bei 
SSI, wenn zuviel Bits gelesen werden, zieht das Schieberegister im 
Encoder einfach Nullen nach?

mfg mf

von Mani W. (e-doc)


Bewertung
-1 lesenswert
nicht lesenswert
minifloat schrieb:
> Fünf Euro für des bisschen Platine und Hühnerfutter? Wucher. Ehrlich,
> zwei nackte MAX485 oder SN75176 gibt's günstiger.

Die fertige Platine auch?

von ArduinoFanBoy (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
minifloat schrieb:
> warum benutzt du nicht die SPI-Schnittstelle?

Moment mal. vllt habe ich da etwas noch nicht verstanden. Ich dachte SSI 
wäre wegen den differentiellen Signalen terchnisch inkompatibel. Oder 
meinst du nur eine Datenleitung (z.B. +) und ein Clock Signal (z.B. +) 
mit SPI verbinden und fertig? Quasi auf das invertierte Signal 
verzichten?

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
minifloat schrieb:
> Matthias S. schrieb:
>> die Auslesung des Sick Stegmann sieht so aus:
>
> Sag mal, warum benutzt du nicht die SPI-Schnittstelle?

Zum einen habe ich zwei solcher Encoder am Mega328 und zum zweiten 
brauchte ich für den einen Encoder 25 Bits und für den anderen 24 Bits. 
Bitbanging war da am einfachsten.

ArduinoFanBoy schrieb:
> Also würde ein Treiber wie dieser hier:
> https://www.amazon.de/MAX485-module-RS-485-TTL-MTS1EU/dp/B017A676EY
> ...inkompatibel sein da kein Clock berücksichtigt wird?

Du bräuchtest auf jeden Fall zwei solcher Platinen, da SSI gleichzeitig 
Hinweg (für Clock) und Rückweg (für Data) ist - RS485 ist aber 
Halbduplex, es geht immer nur in eine Richtung.
Es muss also ein Chip immer senden und der andere Chip immer empfangen.

von ArduinoFanBoy (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Matthias S. schrieb:
> Es muss also ein Chip immer senden und der andere Chip immer empfangen.

Vielen Dank für die Erklärung. Auf sowas hingewiesen zu werden kann bei 
der Planung und Umsetzung viel Zeit und nerven sparen! Top!

Könnte jemand mit Erfahrung auf dem Gebiet zu meinem vorherigen Post 
etwas schreiben?

ArduinoFanBoy schrieb:
> Moment mal. vllt habe ich da etwas noch nicht verstanden. Ich dachte SSI
> wäre wegen den differentiellen Signalen terchnisch inkompatibel. Oder
> meinst du nur eine Datenleitung (z.B. +) und ein Clock Signal (z.B. +)
> mit SPI verbinden und fertig? Quasi auf das invertierte Signal
> verzichten?

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
ArduinoFanBoy schrieb:
>> Moment mal. vllt habe ich da etwas noch nicht verstanden. Ich dachte SSI
>> wäre wegen den differentiellen Signalen terchnisch inkompatibel. Oder
>> meinst du nur eine Datenleitung (z.B. +) und ein Clock Signal (z.B. +)
>> mit SPI verbinden und fertig? Quasi auf das invertierte Signal
>> verzichten?

Nö. Du benutzt die Pins am AVR (CLK und MISO) und dann wird an CLK ein 
differentieller Sendechip wie z.B. der MAX485 angeschlossen - 
vergleichbar mit einem MAX232 für RS232 Pegel.
Ein zweiter MAX485 dient als dauerhaft auf Empfang gesteller 
differentieller Receiver, dessen TTL Ausgang auf MISO geht.
Allerdinga habe ich die SPI Hardware im Mega328 nicht benutzt, denn ich 
bitbange ja.

: Bearbeitet durch User
von ArduinoFanBoy (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Soweit verstanden. Ich werde ein paar MAX485 bestellen. :-)

Ich habe nun schon mit dem Hersteller des Drehgebers in China Kontakt 
aufgenommen. Allerdings muss ich noch folgende Angaben haben:
Output Code | Output Form | Logic

Diese kann ich aus dem "Selection Guide" entnehmen welcher unter
https://www.idencoders.net/absolute-rotary-encoders/serial-ssi-absolute-encoders/bus-based-ssi-gray-encoder.html
zu finden ist. Allerdings kann ich mit den Optionen nichts anfangen. Wer 
kann ggf. etwas zu den Angaben sagen bzw. kann ich die im MAX485 
Datenblatt finden?

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
ArduinoFanBoy schrieb:
> Allerdings kann ich mit den Optionen nichts anfangen. Wer
> kann ggf. etwas zu den Angaben sagen bzw. kann ich die im MAX485
> Datenblatt finden?

Die haben auch nix mit dem MAX485 zu tun. Du musst auf die Option 
"Output Form" = S wie SSI achten. Output Code G wie im Beispiel wird 
nicht erwähnt, scheint dann wahrscheinlich Gray zu sein(?). Kurz, die im 
Beispiel genannte Bestellnummer scheint schon ziemlich die richtige zu 
sein, wobei z.B. 4096/4096 auch reichen sollte.

von ARduinoFanBoy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
So, war ein paar Tage mit Kindergeburtstag und wieder klar kommen 
beschäftigt. :o)

Also als RS485 Treiber (glaube SSI ist eher RS422) werde ich einen 
"MAX490" verwenden. Der ist Vollduplexfähig und hat einen Sende- und 
einen Empfangskanal (Clock und Daten).

Damit wäre das Problem schonmal erledigt.

Matthias S. schrieb:
> wobei z.B. 4096/4096 auch reichen sollte

Voll und ganz. Hätte ich auch gewählt. Aber ich denke, dass der Body mit 
Sensorik immer identisch ist und nur Anschlüsse, Übertragung und 
Controller variieren. Zumindest sind die Angaben für "Number of 
turns/Resolution per turn" immer fix.

Die Chinesen haben sich auch schon gemeldet. Ich werde meine 
Anforderungen nochmal formulieren und dann bestellen.

Matthias S. schrieb:
> Output Code G wie im Beispiel wird
> nicht erwähnt, scheint dann wahrscheinlich Gray zu sein(?).

Zu Gray-Code muss ich noch eine Frage stellen. Nach meinem Verständnis 
ist Gray-Code nur die Art der Verarbeitung (ähnlich wie eine BitMaske 
welche eine Zahl repräsentert). Diese kann zwar auch aus dem Sensor 
herausgeführt werden (z.B. 12 Adern bei 12 Bit), aber i.d.R. wird diese 
doch nur vom Schieberegister des Sensors "intern" verwendet um die 
entsprechenden Bits zu ermitteln!?!

von Noti (Gast)


Bewertung
0 lesenswert
nicht lesenswert
drive by wire = Sicherheitsrelevant

Bevor du zu sehr in tech. Details gehst empfehle ich dir das 
grundsätzliche Konzept zu überlegen. Einen Winkel zu messen ist ja nicht 
die Herausforderung, eher ihn zuverlässig zu messen. Wie stellst du 
sicher, dass das Signal richtig ist? Z.B. defekte Stecker, Kabel, 
fehlender Magnet (magnet. Encoder), verschmutzte Encoderscheibe (opt. 
Encoder)...

Gute Komponenten (wie Haidenhain-Encoder) zu verwenden heißt nicht 
automatisch ein gutes Konzept zu haben!

Schau mal Infineon TLE50xx Sensoren an, diese werden z.B. Automotive für 
elektr. Lenkhilfen verwendet.

von ARduinoFanBoy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Noti schrieb:
> Einen Winkel zu messen ist ja nicht
> die Herausforderung, eher ihn zuverlässig zu messen....Z.B. defekte Stecker, 
Kabel...

Absolut. Meiner Meinung nach kann man 100% nicht erreichen. Wenn man 
99.9% erreichen möchte, muss man auf komplett dedizierte Systeme 
(Sensoren  Leitungen  Computer  mC  Motorik / etc) setzen wie z.B. 
bei Tesla's Autopilot bei denen sich dedizierte Computer gegenseitig 
überprüfen und gegenseitig bewerten. Aber auch da: Was ist wenn sich 
zwei Systeme gegenseitig als "ungültig" beschimpfen.
Wie dem auch sei. Das Thema ist definitiv bereits auf der Liste. 
Allerdings bin ich noch in der "Machbarkeitsphase".

Danke für die Info.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
ARduinoFanBoy schrieb:
> Zu Gray-Code muss ich noch eine Frage stellen. Nach meinem Verständnis
> ist Gray-Code nur die Art der Verarbeitung (ähnlich wie eine BitMaske
> welche eine Zahl repräsentert). Diese kann zwar auch aus dem Sensor
> herausgeführt werden (z.B. 12 Adern bei 12 Bit), aber i.d.R. wird diese
> doch nur vom Schieberegister des Sensors "intern" verwendet um die
> entsprechenden Bits zu ermitteln!?!

Der serielle Datenstrom aus dem Sensor ist Gray-codiert. Hast du dir 
denn überhaupt mal die Ausleseroutine von mir oben angeschaut? Nach der 
Ausleserei wandle ich den empfangenen Gray-Code auf binär.

von Holger D. (hodoe)


Bewertung
0 lesenswert
nicht lesenswert
ArduinoFanBoy schrieb:
> ich bin auf der Suche nach einem Absolutwertgeber.

Moin,

ich habe vor einigen Jahren zwei AFS60A Absolutwertgeber von Sick 
eingekauft, die ich als Transferstandards einsetze. Der Geber hat 262144 
Schritte. Das Programmiergerät hat Klemmbuchsen, bei dem die einzelnen 
Adern nach Außen geführt werden.

Das Oszi zeigte aber alles andere als SSI. Es läuft auch, wenn man ein 
bestimmtes Timing beachtet, ein ganz simples serielles Protokoll im 
Polling-Betrieb.

Vielleicht machen andere Hersteller so etwas ja auch. Der AFS60A dürfte 
nicht im Wunsch-Preissegment liegen und die Schutzart nach Datenblatt 
ist IP67 (Gehäuse), IP65 (Welle).


Holger

: Bearbeitet durch User
von ArduinoFanBoy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Matthias S. schrieb:
> Hast du dir
> denn überhaupt mal die Ausleseroutine von mir oben angeschaut?

Na klar. Aber den Part habe ich als normales Bitshifting verstanden. 
Habe mir den Quelltext nun nochmal angeschaut und etwas zum GrayCode 
gelesen. Jetzt verstehe ich auch dass GrayCode nicht rein elektrisch ist 
sondern auch die Art der Daten definiert. Kein Hexenwerk aber muss man 
berücksichtigen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.