-
        

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 12

Thema: RS485-Sensor oder doch lieber RS232-Sensor an Laptop andocken?

  1. #1
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    17.02.2009
    Ort
    Aachen
    Beiträge
    1.059

    RS485-Sensor oder doch lieber RS232-Sensor an Laptop andocken?

    Anzeige

    Hallo,

    ich wüsste gerne mal, was ihr als einfachste Variante anseht, einen RS485-Sensor an einen Rechner anzudocken, der nur USB bietet.

    Meine Ideen wären soweit:

    - Sensor über einen Adruino auslesen, den man über USB unter Linux ausliest (falls das möglich ist? Vllt. hat ja jemand einen aufschlußreichen Link dazu parrat - ich hab bisher nur über GRBL Daten von Linux an den Arduino gesendet).

    - Sensor an einen AdTiny/AtMega anschließen und über eine virtuelle USB-Schnittstelle USB simulieren, um die Daten zu übergeben (z.B. http://www.obdev.at/products/vusb/index-de.html).

    - Sensor an einen Raspberry Pi anschließen und hier ne Lösung finden, wie man RS485 auswerten kann.

    Ich muss dazu auch fairerweise sagen, dass ich bisher keine Erfahrung mit RS485 habe und dementsprechend nicht genau weiß, was es da zu beachten gibt.
    Wäre denn eine Anbindung über RS485 oder über RS232 sinnvoller und einfacher zu realisieren?

    Die einfachste Variante wäre vermutlich ein Raspberry Pi, da er bereits RS232 über die GPIOs unterstützt...allerdings habe ich grade keinen hier.

  2. #2
    Benutzer Stammmitglied
    Registriert seit
    21.03.2013
    Beiträge
    86
    Hallo,

    wir haben mit folgenden Teil sehr gute Erfahrungen gemacht:

    http://www.cti-shop.com/RS485-Konverter/USB-Nano-485

  3. #3
    Erfahrener Benutzer Roboter Genie Avatar von robocat
    Registriert seit
    18.07.2006
    Beiträge
    935
    Wenn man den Entwicklungsaufwand nicht scheut (bzw was dabei lernen möchte), sollte das mit einem Attiny und einem dieser FTD-USB Chips machbar sein. Recht viel billiger als die bereits fertigen RS-485 Interface Konverter Adapter: USB auf RS485 bei Ieh-bäh wirds aber nicht werden. Such mal dort nach "RS485 usb". Ich habe mit den dort angebotenen kleinen Interface Platinen bisher keine Erfahrung, habe aber auch noch nichts schlechtes darüber gehört.

    Bei dem obdev.at Lösung wäre der µC wohl mit dem USB Protokoll schon so ausgelastet, dass es schwierig wird, die RS485 Daten schnell genug zu übertragen (Vermutung).

    Grüße von der Katze

  4. #4
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    17.02.2009
    Ort
    Aachen
    Beiträge
    1.059
    @Indeas und Robocat: Und wie werden die Daten vom Rechner aus abgerufen?
    Im Endeffekt muss die Datenübertragung (in diesem Fall) nicht so schnell wie möglich stattfinden. Ich könnte mir vorstellen, dass ich über einen µC etwas auswerte und nur 1-2 Mal in der Sekunde einen Messwert an den Rechner sende, bzw. von da abrufe.

  5. #5
    Benutzer Stammmitglied
    Registriert seit
    21.03.2013
    Beiträge
    86
    In der Regel holt der Rechner (Master) die Daten vom Sensor (Slave) ab.
    Z.B. Der PC schickt ein String "*?<CR>" und dann antwortet der Sensor mit dem Datenstring.
    Da RS485 oft als Halbduplex ausgeführt wird, kann ohnehin immer nur ein Teilnehmer reden.

    Wie sieht denn Dein Sensor aus?

  6. #6
    Erfahrener Benutzer Roboter Genie Avatar von robocat
    Registriert seit
    18.07.2006
    Beiträge
    935
    Das von mir verlinkte Interface Modul stellt PC seitig einen virtuellen COM Port bereit. Bei der OBDEV Lösung gibt es LibUSB Treiber, die man in ein selbstgestricktes Programm einbinden kann. Die Lösung mit dem virtuellen COM Port dürfte für weniger geübte Programmierer die einfachere sein.

  7. #7
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    17.02.2009
    Ort
    Aachen
    Beiträge
    1.059
    Ich hab bzgl. der obdev-Lösung mal ne Anfrage gesendet.
    Probleme gibt's nur, wenn man einen Bulk endpoint (eigentlich nicht unterstützt auf low speed devices) konfiguriert. Dann braucht v-usb so um die 80% der CPU-Zeit.

    Eine weitere Einschränkung ist die Interrupt-Latency. Weitere Interrupts (zum USB Interrupt) müssen innerhalb von ca. 15 bis 20 Instructions die globalen Interrupts wieder aufdrehen und kein Code darf die Interrupts für länger als 15 bis 20 Instructions abdrehen.

    Ausserdem müssen andere Interrupts damit rechnen, dass der USB Interrupt für um die 120 Mikrosekunden lang läuft und sie um so viel später drankommen.
    Wenn ich mir das so durchlese, versteh ich...noch nicht so viel
    Was ist ein "Bulk endpoint" im USB-Sinne?

    Wenn der Messrechner über USB lediglich ein oder zwei Sensoren angeschlossen hat, dürfte die Interrupt-Latency doch keine große Rolle spielen, oder etwa doch?


    Am interessantesten finde ich die Lösung "mit einem Attiny und einem dieser FTD-USB Chip". Ich hab mal ein wenig in der Bucht nach den Chips gesucht, aber auf Anhieb keine gefunden.
    Ich wollte schon immer mal ein eigenes USB-Gerät basteln...von daher finde ich das Thema schon sehr interessant.
    Ich hatte mich mal auf USB.org umgeschaut und als ich gesehen hatte, dass man sich für eigene USB-Sachen ne PID etc. zulegen muss, was kostenpflichtig ist, wars uninteressant.
    Gibts zur FTD-Lösung hier vielleicht irgendwo ein Tutorial?

    Noch gibts keinen konkreten Sensor, den ich damit nutzen möchte. Aber ich könnte mir einen Beschleunigungssensor, einen Temperatursensor oder sonstiges vorstellen. Ich hab halt bisher wenig Ahnung von den verschiedenen Anbindungen (I2C, RS232, RS485), wehalb ich da endlich mal reinschnuppern möchte

  8. #8
    Erfahrener Benutzer Robotik Einstein Avatar von 021aet04
    Registriert seit
    17.01.2005
    Ort
    Niklasdorf
    Alter
    29
    Beiträge
    4.566
    Mit FTD Chips werden vermutlich das http://www.ftdichip.com/ gemeint sein. Die haben USB Wandler zu sehr vielen anderen Schnittstellen (RS232/UART, RS485,....) aber auch andere Chips zum Thema USB (USB Host,...)

    Beim USB AVR Lab wird der USB Datenverkehr auch nur mit dem µC bewerkstelligt. http://www.ullihome.de/wiki/USBAVRLab/index

    Wie das gemacht wird könntest du bei Christian Ulrich nachfragen wie er es beim AVR Lab gemacht hat.

    MfG Hannes

  9. #9
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    17.02.2009
    Ort
    Aachen
    Beiträge
    1.059
    Ah, die FTD-Chips kosten ja gar nicht so viel. Ne Direktverbindung USB-I2C ist damit ja möglich.
    Aber nen Chip Usb-RS485 hab ich nicht so auf Anhieb gefunden. Nur n Konverterkabel, das gleich mit ~30 Steinen zu Buche schlägt.
    Aber da wäre es vermutlich sinnvoller, den RS485-Sensor an nen AtTiny/Mega zu klemmen und den auszulesen.
    Aber welches Protokoll wäre dafür am sinnvollsten? I2C? RS232?

    Da ist ja einiges möglich mit den FTDIs:
    http://de.rs-online.com/web/c/?searc...t-option=Preis

  10. #10
    Erfahrener Benutzer Robotik Einstein Avatar von 021aet04
    Registriert seit
    17.01.2005
    Ort
    Niklasdorf
    Alter
    29
    Beiträge
    4.566
    Das kommt auf deine Bedürfnisse an. Wieviele Bausteine sollen möglich sein, welche Geschwindigkeit wird benötigt, wie sicher soll die Verbindung sein (gegen Störungen => z.B. Industrie),....


    MfG Hannes

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. Verkaufe Räumung:US-Sensor, IR-Sensor,Displays,MTreiber,Servorboard, Pan&Tilt Köpfe
    Von kellerkind im Forum Kaufen, Verkaufen, Tauschen, Suchen
    Antworten: 3
    Letzter Beitrag: 18.06.2012, 18:42
  2. Datenübertragung (Rs232 oder RS485)
    Von elkokiller im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 6
    Letzter Beitrag: 03.10.2006, 14:22
  3. 74HC 165 oder doch lieber was anderes?
    Von coCo im Forum Elektronik
    Antworten: 18
    Letzter Beitrag: 24.09.2006, 01:30
  4. C-Control 1 oder doch lieber die CCII zur Zeitmessung
    Von kai100 im Forum Controller- und Roboterboards von Conrad.de
    Antworten: 3
    Letzter Beitrag: 01.06.2005, 17:37
  5. Temp-Sensor KT130 (PTC-Sensor) an C-Control
    Von Thomas im Forum Sensoren / Sensorik
    Antworten: 1
    Letzter Beitrag: 02.12.2003, 13:53

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •