Hallo allerseits, Im Rahmen meiner Masterarbeit bin ich gerade auf der Suche nach einem Absolutwertgeber, den ich mit einem TI TMS320F28335 auslesen kann. Mit Microcontrollern, sowie mit deren Schnittstellen habe ich bislang nur wenig Erfahrung, aber soweit ich mich bisher eingelesen habe, kann ein Geber mit SSI-Schnittstelle über die SPI-Schnittstelle des Controllers ausgelesen werden. Das macht für mich auch soweit Sinn, da ich jeweils einen Takt vorgebe, mit dem ich quasi die Positionsdaten aus dem Geber "harausziehe". Hierfür reicht meines Erachtens nach die unidirektionale Kommunikation über SSI aus. Allerdings ist mir noch nicht ganz klar, wie ich den SSI-Ausgang des Gebers mit der SPI-Schnittstelle des Controllers zusammenbringe. Hat hierzu schon jemand konkrete Erfahrungswerte bzw. Beispiele, wie ich das mit genanntem uC realisieren kann?
Um den Level zu konvertieren schau dir mal gängige RS485 Treiber an. Die Frage ist nur ob der TI Controller sich flexibel genug ist was die Anzahl Bits angeht. Eine andere Alternative wäre noch ein Hiperfacegeber. Da ist allerdings das Protokoll etwas aufwändiger.
Achso, SCLK kommt vom uC uber den RS485 Treiber an den CLK des Gebers. Data vom Geber geht dann über einen anderen RS485 Treiber an den MISO des uC. MOSI des uC bleibt offen. CS des uC brauchst Du nicht. Dann brauchst Du nur noch die Anzahl CLKs senden und das Register mit den Empfangsdaten auslesen und richtig zusammensetzen. Aufpassen mit der maximalen CLK Frequenz, der Monofloptime, der Anzahl Single/Multiturns, evtl noch Fehlerbits bzw. Powerfailbit berücksichtigen.
@ runtastic Vielen Dank erstmal für deine Antwort! Also wenn ich dich richtig verstehe, brauche ich zwei externe RS485 Treiber-ICs, die ich zwischen Geber (SSI-Schnittstelle) und Contorller (SPI-Schnittstelle) "hänge"? Grüße
Marc H. schrieb: > Also wenn ich dich richtig verstehe, brauche ich zwei externe RS485 > Treiber-ICs, die ich zwischen Geber (SSI-Schnittstelle) und Contorller > (SPI-Schnittstelle) "hänge"? So ist es. Der eine RS485 Treiber liefert die differentiellen CLK Signale an den Geber und der andere empfängt die Daten. Eine simple Lösung ist auch mit Invertern denkbar, sowas habe ich mal bei kurzen Leitungen zu den Gebern machen können. Da es hier lediglich in eine Richtung auf jedem Kabelpaar geht, sind Tranceiver (kombinierte Sender/Empfänger) nicht nötig. runtastic schrieb: > Aufpassen mit der maximalen CLK Frequenz, der Monofloptime, der Anzahl > Single/Multiturns, evtl noch Fehlerbits bzw. Powerfailbit > berücksichtigen. .. und das die Geber meistens Gray Code liefern.
:
Bearbeitet durch User
Ja, aber Signalfluss beachten! Clk von uC zu Geber. Data von Geber zu uC. Also Senderichtung richtig festlegen/einstellen.
Matthias Sch. schrieb: > .. und das die Geber meistens Gray Code liefern. Stimmt, habe ich vergessen. Manche Geber, gerade Lasergeber kann man heutzutage aber auch parametrieren. Also wieviel Positionsbits, bei was für einer Auflösung, mit was für Fehlerbits.
> So ist es. Der eine RS485 Treiber liefert die differentiellen CLK > Signale an den Geber und der andere empfängt die Daten. Blödsinn. Ein Treiber von TTL zu RS 422 und ein Empfänger RS 422 auf TTL sind hier gefragt. Ein geeigneter Kandidat wäre also ein SN 75 LBC 179. Die RS422-Enden gucken in Richtung Drehgeber. Nix RS485.
Bürovorsteher schrieb: > Die RS422-Enden gucken in Richtung Drehgeber. > > Nix RS485. Vorschlag zur Güte: Es geht beides. Sowohl ein RS422 als auch ein RS485 Treiber lassen die LED leuchten. Ich hab mal die CLK Eingangsschaltung eines Sick-Stegmann SSI Drehgebers angehangen. Da sieht man auch, das eine simple Inverter Schaltung auch geht. Ich benutze z.B. 3 Inverter eines 74HC14 als Sender.
Vielen Dank für eure Anregungen!
In die Treiber-Geschichte muss ich mich jetz erstmal einlesen, da hab
ich noch zu wenig Ahnung.
Aber nur damit ich nicht völlig in die falsche Richtung marschiere, das
Ganze geht dann schon über die SPI-Schnittstelle des Controllers, oder?
> .. und das die Geber meistens Gray Code liefern.
Habe auch Geber gefunden (Bsp.: Hengstler AC36 - BiSS/SSI) die ihre
Daten Binär über SSI ausgeben, die kann ich ja dann direkt verrechnen.
Ach ja, ich habe noch vergessen zu erwähnen, dass es hierbei um einen Laboraufbau geht, d.h. ich werde recht kurze Leitungen im Bereich von 1m verwenden.
Marc H. schrieb: > Aber nur damit ich nicht völlig in die falsche Richtung marschiere, das > Ganze geht dann schon über die SPI-Schnittstelle des Controllers, oder? Ähh, mal ne kleine Frage. Machst du auch irgend etwas selber an deiner MASTER-Thesis? Mal davon abgesehen dass das absoluter Kindergarten ist so nen SSI Geber auszulesen. Das bisschen solltest Du eigentlich schon selber raus- bzw hinbekommen. > Habe auch Geber gefunden (Bsp.: Hengstler AC36 - BiSS/SSI) die ihre > Daten Binär über SSI ausgeben, die kann ich ja dann direkt verrechnen. Oder einfach gleich beides vorsehen? Das hat ja auch nen Grund warum es Gray gibt. Marc H. schrieb: > Ach ja, ich habe noch vergessen zu erwähnen, dass es hierbei um > einen > Laboraufbau geht, d.h. ich werde recht kurze Leitungen im Bereich von 1m > verwenden. Wenn Du richtige Treiber verwendest sind auch 100m kein Problem!
Hans schrieb: > Mal davon abgesehen dass das absoluter Kindergarten ist so nen SSI Geber > auszulesen. So isses. Dafür braucht man nicht mal Hardware-SPI, sondern simples Bit-Banging geht genauso. Marc H. schrieb: >> .. und das die Geber meistens Gray Code liefern. > > Habe auch Geber gefunden (Bsp.: Hengstler AC36 - BiSS/SSI) die ihre > Daten Binär über SSI ausgeben, die kann ich ja dann direkt verrechnen. Auch das Umrechnen von Gray in Binär ist Kinderkrams und in C eine Sache von ein paar Zeilen. Tipp: Schau mal in Wikipedia. Wäre das EnDat, gäbs ein bisschen mehr zu tun, aber SSI ist wirklich simpel.
Matthias Sch. schrieb: > Hans schrieb: >> Mal davon abgesehen dass das absoluter Kindergarten ist so nen SSI Geber >> auszulesen. > > So isses. Dafür braucht man nicht mal Hardware-SPI, sondern simples > Bit-Banging geht genauso. Und wenn man nicht die Anzahl Bits genau einstellen kann, könnte man auch auf die Idee kommen einfach mehrfach mit der HW-SPI zu senden. Also bei 12Bit Single-Turn + 12Bit Multiturn + 1x Powerfail einfach einmal 16Bit und dann 9Bit senden und dann die Werte richtig aus dem Empfangsregister zusammensetzen. Vllt auch 3 Mal senden. Also 12Bit, 12Bit, 1Bit. Dann hätte man es sogar gleich richtig sortiert und braucht es nur in die richtige Variable schreiben. Ist mit Sicherheit nicht so super von den Timings wie wenn man direkt 25Bits zusammenhängend rausclockt, aber da es synchron ist ist das ja auch egal ;-)
Hi Marc, eine Beschreibung die Deine Problemstellung eigentlich umfassend beschreibt und lösen sollte findest Du hier : http://www.posital.com/media/posital_media/documents/AbsoluteEncoders_Context_Technology_SSI_AppNote.pdf eine Beschreibung zum der SSI Schnittstelle : http://www.posital.com/de/produkte/schnittstelle/ssi/ssi.php Gruss CWA
Bitte 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.