-         
Seite 3 von 4 ErsteErste 1234 LetzteLetzte
Ergebnis 21 bis 30 von 37

Thema: Kabelfernbedienung mit Arduino?

  1. #21
    Anzeige

    Hallo,

    wie stellst Du dir die Verkabelung vor? Hast Du eine strukturierte Verkabelung die Du nutzen kannst/willst oder willst Du mit der Kabeltrommel rumrennen bei 100m Kabellänge. Und zw. 2 Bedienpulten via "Empfänger" sind das dann schon im ungünstigsten Falle 200 m Leitungslänge. Da kommt schon was an Leitungsverlusten zusammen.

    hasta

  2. #22
    Benutzer Stammmitglied
    Registriert seit
    31.03.2014
    Beiträge
    49
    Die Kabel werde ich legen, da muss ich nicht mit der Kabeltrommel rumrennen...
    Und 100m sind mit viel Reserve. Aktuell ist die weiteste Entfernung vom Empfänger zu einem der Sende-Bedienpulte ca. 18m. Da man aber nie weiss, was noch kommt, nenne ich mal 100m, um damit auch zukünftig arbeiten zu können. Meines Wissens wäre das z.B. für RS485 unproblematisch, ob nun 15 oder 100m.
    "...im ungünstigsten Fall 200m..." Wieso? Sternförmig verkabelt (wie auf der Zeichnung zu sehen) würden es niemals mehr als eben (max) 100m pro Sendepult.

    Andi

  3. #23
    Erfahrener Benutzer Roboter Genie Avatar von Moppi
    Registriert seit
    18.03.2018
    Beiträge
    1.399
    Blog-Einträge
    7
    Meines Wissens ist RS485 ist eine Punkt zu Punkt Verbindung. Stern geht damit nicht. Jedes Bedienpult bräuchte also drei RS485 Schnittstellen. Zu jedem Bedienpult eine und jeweils zu dem Empfänger. Das wären für jedes Bedienpult 3x3 Adern. Richtig oder falsch? Das würde Dein Problem nicht lösen. Wird dann wohl nur I2C bleiben. Das ist aber nicht für so lange Leitungen, mit mehreren Metern Länge, ausgelegt. Verlängert werden könnte das wohl, aber irgendwie haben andere User in anderen Foren, dafür geschirmte Leitungen CAT5 genommen (Stärke ca. 5mm). Ob das eine Verbesserung für Dich, zum jetzigen Zustand, darstellt? Dann muss es jemand realisieren können. Da habe ich gerade was vom P82B96 gelesen. Ob das funktionieren kann? Da muss sich jemand finden, der das ausprobieren kann oder direkt weiß, wie man so etwas baut. Für mich wäre das auch Neuland und daher scheide ich dann wohl aus. Habe auch kein Oszilloskop, um da irgendwas überprüfen zu können.



    MfG

  4. #24
    Benutzer Stammmitglied
    Registriert seit
    31.03.2014
    Beiträge
    49
    I2C hatte ich auch schon im Visier, aber da waren/sind besonders die Unsicherheiten mit der Kabellänge ein Hindernis. Insofern ist Dein Link zu dem Beitrag auf microcontroller.de sehr interessant, vielen Dank dafür. Diesen Beitrag kannte ich bisher noch nicht. Ich habe allerdings schon viele Erfahrungen gesammelt hinsichtlich Kabel und Kabelqualität. Das ist ein Aspekt, der jedenfalls nicht zu unterschätzen ist.
    Was RS485 betrifft, so habe ich dessen Prinzip anders verstanden, als Du schreibst. Meine vorangegangene Formulierung war da möglicherweise irritierend, indem ich "sternförmig" schrieb. Wenn ich es aber richtig verstehe, so ist RS485 ein Bussystem, auf das man sich an jedem Ort (innerhalb der möglichen Kabellängen) einklinken kann, und es werden keine Signale durchgeschliffen durch eines der angeschlossenen Geräte siehe z.B. https://www.wut.de/e-6wwww-11-apde-000.php). Insofern betrachte ich den Bus dort als "sternförmig", denn ob der Bus nun 100m lang ist oder 20cm, dürfte dann keine Rolle spielen. Bitte mich korrigieren, wenn ich das falsch verstanden habe. Allerdings ist die Kabellänge vom Bus zu den einzelnen Geräten dann eingeschränkt (zumindest im Halbduplex), und das könnte für meine Anwendung wiederum Auswirkungen haben, da ich diesen 2-Draht-Bus verwenden wollte, um das Kabel aus bereits genannten Gründen schmal und flexibel zu halten. Wenn CAT-Kabel ins Spiel kommt (zumindest solches mit Abschirmung), kann ich "eigentlich" auch bei meiner bisherigen SubD-25-Varinte bleiben, denn gut geschirmte CAT-Kabel sind prinzipbedingt nicht wirklich flexibel.
    Ich grüble nun schon eine Weile an diesem Vorhaben und muss zunehmend feststellen, dass es wohl keine wirklich einfache Lösung dafür gibt. Da schaue ich neidisch auf meine USB-Tastatur, die auf einem 4-adrigen Kabel locker über 100 verschiedene Tastensignale überträgt und auf der Empfängerseite erkennt und bin der Meinung, da sollten meine 8 läppischen Tasten doch auch möglich sein. Wird es vermutlich auch, aber die physikalische Grenze bzw. Hürde wird wohl die Kabellänge sein. Symmetrische Verkabelung kenne ich z.B. aus der Musikecke oder DMX und weiss von dort, dass es einen erheblichen Unterschied in der Signalqualität gibt, wenn man ein Line-Signal über 30m Kabel schickt. Daher der Gedanke an RS485...

    Andi

  5. #25
    Erfahrener Benutzer Roboter Genie Avatar von Moppi
    Registriert seit
    18.03.2018
    Beiträge
    1.399
    Blog-Einträge
    7
    Ich glaube aber, ich hatte einen Denkfehler. Jeder Sender benötigt nur eine RS485. Das sollte machbar sein. Anscheinend kann man mehrere RS485 sternförmig zusammenschalten: https://www.mikrocontroller.net/topic/372367
    Bloß das Handling ist dann wohl nicht so einfach. Allerdings kann ich mich nicht erinnern, so etwas schon angewendet zu haben. Ich kenne RS485 nur als Verbindung zwischen zwei Geräten.
    Unmöglich scheint es jedenfalls nicht zu sein:
    Klicke auf die Grafik für eine größere Ansicht

Name:	262917.jpg
Hits:	6
Größe:	8,2 KB
ID:	34502

    Hier gibt es z.b. die RS485 Boards für Arduino.

    Wer sucht, der findet ... irgendwann. Im RN-Wissen steht es auch noch mal: https://rn-wissen.de/wiki/index.php/RS485

    Muss sich jemand finden, der sich damit auskennt.



    MfG
    Geändert von Moppi (19.11.2019 um 23:08 Uhr)

  6. #26
    Erfahrener Benutzer Robotik Einstein Avatar von 021aet04
    Registriert seit
    17.01.2005
    Ort
    Niklasdorf
    Alter
    31
    Beiträge
    4.823
    RS485 ist ein Bussystem. Alle Teilnehmer sind an 2 differenziellen Adern angeschlossen (Ader A und B). Dadurch kann immer nur 1 Teilnehmer senden.

    Ich würde das mit einem Master-Slave System an einem RS485 Bus lösen. Da du nur einen Empfänger hast, würde ich den als Master nehmen. DMX basiert auf dem RS485 System und ist ein spezielles Protokoll. Profibus (Bussystem in der Industrie zur Kommunikation in Anlagen) basiert ebenfalls auf RS485.

    Ich würde es so lösen:
    Master (es wird eingestellt wieviele Slaves es maximal gibt) => Empfänger, Slave => Terminal mit eindeutiger Adresse (einmal einstellen z.B. über Dipschalter oder fix programmiert)
    Wichtig ist das nur ein Teilnehmer auf Senden geschalten ist.

    Master sendet an Adresse 1 ein Komanndo um zu prüfen ob es ihn gibt (z.B. Startbyte, Adresse, Stoppbyte)
    Slave vorhanden (z.B. Slave sendet Startbyte, Adresse, Status der Tasten, Stoppbyte zurück) => Master sendet Status der Relais an Slave, nächste Adresse wählen
    Slave nicht vorhanden (keine Antwort für eine gewisse Zeit) => nächste Adresse wählen
    Gleich wie oben mit Adresse 1, den Ablauf wiederholen bis die letzte Adresse erreicht ist und dann wieder bei Adresse 1 starten

    MfG Hannes

  7. #27
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    09.10.2014
    Beiträge
    4.852
    mit allem nötigen Vorbehalt:
    ich habe von RS485 oder evtl. auch UART Protokollen gehört, bei denen mehrere Teilnehmer an RX/TX aufgereiht sind.
    Alle Nachrichten per TX erreichen daher alle RX.

    Man kann unterscheiden, welcher RX Slave Nachrichten beachtet, indem man einen"Adress-ID-Header" mit verschickt, und nur derjenige RX Slave beachtet die msg, dessen Adress-ID damit identisch ist.
    ·±≠≡≈³αγελΔΣΩ∞ Schachroboter:www.youtube.com/watch?v=Cv-yzuebC7E Rasenmäher-Robot:www.youtube.com/watch?v=z7mqnaU_9A8

  8. #28
    Erfahrener Benutzer Robotik Einstein Avatar von wkrug
    Registriert seit
    17.08.2006
    Ort
    Dietfurt
    Beiträge
    2.051
    RS 485!
    Wenn man das so machen will müsste dann wohl der Empfänger der Master sein.
    ( Nur ein Controller im System kann Master sein ! )
    Der verschickt dann einen Token mit der Adresse der jeweiligen Tasteneinheit.
    Diese und nur diese darf dann seinen Sender einschalten und Steuernachrichten verschicken.
    Kommt nicht innerhalb einer bestimmten Zeit eine Antwort wird der Token an die nächste Steuereiheit weitergegeben.
    Um das Ganze flexibel zu Halten wären wohl 16 Adressen sinnvoll.
    Eventuell kann der Master auch nur bei jedem x-sten Durchlauf alle möglichen Adressen abfragen.
    Ansonsten nur die bereits aktiven, das beschleunigt das System.
    Noch mehr mögliche Adressen verlangsamen aber zunehmend das ganze System.
    Auf der Tastenseite könnte man die Adresse per DIP Fix Schalter, oder Lötbrücken einstellbar machen.
    Dann kann für alle Tastenteile die gleiche Software verwendet werden.
    Es darf immer nur ein Sender aktiv sein. Dann würde das Ganze auch mit nur 2 Drähten funktionieren.
    Als Treiberbausteine könnten hier die "üblichen Verdächtigen" verwendet werden ( MAX 485, SN75176 ).
    Als Ansteuerung für die Bausteine wäre der ganz normale USART + 1 bis 2 Steuerleitungen möglich.
    Das Bussystem muss an beiden Enden mit Abschlusswiderständen abgeschlossen werden.
    Bei DMX verwendet man hierzu Terminatoren ( Einfach in einen Stecker eingelöteter Widerstand. ).

    Das System entspricht in etwa dem, was auch HaWe und 021aet04 vorgeschlagen haben.

    Ich würde hier noch mal ein anderes Bussystem in den Ring werfen.
    Wäre das nicht eine klassische Anwendung für einen CAN Bus?
    Hier sendet jeder Teilnehmer seine Nachrichten in einem festgelegten Frame, die Kollisionserkennung passiert hier ja auf dem Bus ( Der Teilnehmer der eine Buskollision feststellt schatet seinen Sender ab ! ).
    Der Bus arbeitet Nachrichtenbezogen.
    Das bedeutet ein Sender gibt nur eine Nachricht auf den Bus und nur die Teilnehmer die diese Nachricht "interessiert" werten diese aus.
    Damit liesse sich so ein System auch problemlos mit mehreren Sendern und Empfängern erweitern.
    Die Geschwindigkeit auf dem Bus bestimmt hier die Reichweite.
    Ich kenn jetzt die Lösung mit 2 Chips. Einer für den Protokollstack ( MCP 2515 ) ein weiterer als Bustreiber ( MCP 2551 ).
    Librarys sollten sich für den Arduino finden lassen.
    Es gibt auch Controller mit integrierter CAN Schnittstelle, aber es soll ja ein Arduino verwendet werden!
    Wobei das CAN Protokoll doch relativ komplex ist.

    Meines Wissens ist RS485 ist eine Punkt zu Punkt Verbindung. Stern geht damit nicht.
    Stern geht nicht, das stimmt.
    Aber die Leitung darf ohne weiteres von einem Teilnehmer zum nächsten, ohne Abzweigungen, gelegt werden.
    Die Bustreiber sind dabei für max. 32 Teilnehmer ausgelegt.
    Geändert von wkrug (21.11.2019 um 23:35 Uhr)

  9. #29
    Erfahrener Benutzer Roboter Genie Avatar von Moppi
    Registriert seit
    18.03.2018
    Beiträge
    1.399
    Blog-Einträge
    7
    Wir haben das aus dem RN-Wissen:

    Klicke auf die Grafik für eine größere Ansicht

Name:	rs485-2leiter.jpg
Hits:	8
Größe:	30,5 KB
ID:	34523

    Da ist doch das, was gebraucht wird. Es waren doch 3 Bedienungen und ein Empfänger, nicht?

    Dann haben wir diese MAX485-Module für Arduino (ATmega328P bspw.).

    Müssen diese 120Ohm-Widerstände etxra angeschlossen werden?

    Hier habe ich ein Anschlusschema gefunden. Verbunden werden R0 mit Rx, DI mit Tx, DE+RE gebrückt und mit einem beliebigen anderen Pin (damit wird wohl das Modul enabled/disabled, nehme ich an).

    Dann müssten die Geräte (Arduinos) nur noch programmiert werden. Fehlt noch was?





    MfG

  10. #30
    Erfahrener Benutzer Robotik Einstein Avatar von wkrug
    Registriert seit
    17.08.2006
    Ort
    Dietfurt
    Beiträge
    2.051
    Dann haben wir diese MAX485-Module für Arduino (ATmega328P bspw.).

    Müssen diese 120Ohm-Widerstände etxra angeschlossen werden?
    Der Bus ist recht stabil, es wird bei 18m sicher auch ohne diese Widerstände funktionieren.
    Von der reinen Lehre her müssen aber die Widerstände an beiden Enden der Leitung eingebaut werden.
    Wie man das technisch löst ist auch vom verwendeten Stecksystem abhängig.
    Jeder Busteilnehmer bekommt 2 Stecker. Ob man da 1*männlich 1* weiblich oder gleiche Stecker verwendet ist erstmal egal.
    Natürlich geht auch fixe Verdrahtung mit Schraubklemmen.
    Die Abschlusswiderstände kann man ja auch in jeden Busteilnehmer einbauen und über einen Jumper zuschaltbar machen.
    Oder man macht das eben in einen Stecker rein ( wie bei DMX 512 ) .

    Hier habe ich ein Anschlusschema gefunden. Verbunden werden R0 mit Rx, DI mit Tx, DE+RE gebrückt und mit einem beliebigen anderen Pin (damit wird wohl das Modul enabled/disabled, nehme ich an).
    Das mit den Enable Leitungen hast Du richtig erkannt.
    Alle Empfänger können aber trotzdem fix aktiv geschaltet werden.
    Das ist eventuell sogar ein Vorteil, weil der aktive Sender sein eigenes Signal wieder empfängt und man somit auch gleich eine Busüberwachung mit integrieren kann.
    Die Sender müssen aber auf jeden Fall abschaltbar sein, weil das Protokoll differentielle Signale verwendet und damit 2 Sender gleichzeitig mit unterschiedlichen Signalzuständen einen Quasi Kurzschluss produzieren könnten.

Seite 3 von 4 ErsteErste 1234 LetzteLetzte

Ähnliche Themen

  1. Arduino: Die IoT Cloud richtet Arduino-Boards aus der Ferne ein
    Von Roboternetz-News im Forum Neuigkeiten / Technik-News / Nachrichten / Aktuelles
    Antworten: 8
    Letzter Beitrag: 08.02.2019, 10:56
  2. STM32 contra ARM Cortex M3 (Arduino Due, Teensy): Performance per Arduino vs. nativ C
    Von HaWe im Forum ARM - 32-bit-Mikrocontroller-Architektur
    Antworten: 14
    Letzter Beitrag: 22.11.2017, 12:53
  3. Arduino vs. Arduino: Marke und Produktion wieder unter Kontrolle der Gründer
    Von Roboternetz-News im Forum Neuigkeiten / Technik-News / Nachrichten / Aktuelles
    Antworten: 0
    Letzter Beitrag: 29.07.2017, 11:00
  4. Antworten: 13
    Letzter Beitrag: 07.11.2015, 02:21
  5. Rosenkrieg: Arduino zahlt Arduino keine Lizenzgebühren
    Von Roboternetz-News im Forum Neuigkeiten / Technik-News / Nachrichten / Aktuelles
    Antworten: 0
    Letzter Beitrag: 20.03.2015, 09:00

Berechtigungen

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