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!
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 :-))
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
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?
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?
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.
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.
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. :-)
ArduinoFanBoy schrieb: > Ja das stimmt. Evtl mit Zahnriemen. Da ist aber keinesegs spelfrei. Da müsstest Du schon etwas mit vorgespannten Zahnrädern bauen.
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.
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:
1 | /* Read the Sick Stegmann Encoder AG661
|
2 | * This is done by bringing the clock low first - After rising the clock again,
|
3 | * the first bit is sent by the encoder. 24 bits are sent followed by the PF bit
|
4 | * indicating a Power fail. A break with a minimum of 20 uS will reset the encoder to start
|
5 | *
|
6 | */
|
7 | void Read_Angle(void) { |
8 | uint8_t n; |
9 | uint32_t temp = 0; |
10 | ENCODER_CLOCK_PORT &= ~(1 << ENCODER_CLOCK1_PIN); // initial clock low |
11 | _delay_us(5); |
12 | for (n=0;n<25;n++) { |
13 | ENCODER_CLOCK_PORT |= (1 << ENCODER_CLOCK1_PIN); // clock high |
14 | _delay_us(5); |
15 | temp <<= 1; |
16 | if (bit_is_set(ENCODER_PIN,ENCODER_RX1_PIN)) temp |= 1; |
17 | ENCODER_CLOCK_PORT &= ~(1 << ENCODER_CLOCK1_PIN); // clock low |
18 | _delay_us(5); |
19 | }
|
20 | ENCODER_CLOCK_PORT |= (1 << ENCODER_CLOCK1_PIN); // clock high |
21 | if (temp > 0x01ffff00) fastFlags.alarmSensor1 = TRUE; |
22 | else fastFlags.alarmSensor1 = FALSE; |
23 | // now convert gray to binary
|
24 | for (n=1;n<32;n=2*n){ |
25 | temp = temp ^ (temp >> n); |
26 | }
|
27 | // mask out rotation and angle and fill the globals
|
28 | rotationValue =(uint16_t) ((temp & 0x01ffe000) >> 13); |
29 | angleValue =(angleValue + (uint16_t) ((temp & 0x00001ffe) >> 1)) >> 1; |
30 | // _delay_us(100);
|
31 | }
|
:
Bearbeitet durch User
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!
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
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?
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
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.
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
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.
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?
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
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?
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?
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.
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?
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
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?
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.
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!?!
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.
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.
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.
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
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.
So, für den Fall dass jemand ebenfalls einen verhältnismäßig "günstigen" absoluten Multiturn-Rotary-Encoder sucht und über diesen Thread stolpert: Ich habe den Sensor aus China Anfang Januar bekommen. Sehr schnelle Expresslieferung von nur 2 Tagen. Der MAX490 ist zwischenzeitlich ebenfalls angekommen um den Drehgeber bidirektional (clock+data) auslesen zu können. Allerdings muss ich noch ein Projekt abschließen bevor ich mit diesem beginne. Ein Test steht also noch aus. Wichtig: Zumindest bei den chinesischen Abs.Multi. Encodern findet man teils sehr günstige Angebote für weniger als 200 USD. Problem ist jedoch, dass diese nur so halbe vollwertige Abs.Multi. Encoder sind. Folgende Typen gibt es: For Multi-turn Absolute encoder, we have three types: 1)Type A: Electronic Multi-turn Absolute encoder, this type of encoder can not remember the laps when the power is off, the cost performance for this one is not adviced to you; 2)Type B: Battery Type Multi-turn Absolute encoder, this type of encoder can remember the turns(needs the battery supplying the power, the life for the battary is 5 years); 3)Type C: Mechanical Multiturn Absolute encoder，this type of encoder can remember the turns by its copper gear set structure; Man muss also schon darauf achten, dass man den richtigen Typen wählt. Sonst hat man einen Encoder der nicht den Erwartungen entspricht. Ich habe den "Type C" bestellt und geliefert bekommen. Der Encoder kostet 425 USD + 95 USD Versand. Allerdings kommen auch noch 19% MwSt. und etwa 18€ Bereitstellungsentgelt (DHL) oben drauf was in Summe rund 620 USD sind. Es lohnt sich aber definitiv mit den Chinesen zu handeln!!! Hat bei mir auf jeden Fall gut geklappt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.