Hallo, ich habe vier Geräte, die miteinander Kommunizieren sollen. Sie
haben eine RS232 Schnittstelle. Daran möchte ich nichts ändern. (Hier im
Forum wurde z.B. Umbau auf RS485 vorgeschlagen.)
Es ist quasi wie ein Chat. Einer der vier sendet, die anderen drei
Empfangen. Senden soll nur möglich sein, wenn eben gerade nichts über TX
herein kommt. Der Buffer soll 256 Zeichen betragen. Jeder der vier soll
immer an die jeweiligen drei anderen senden können. Es gibt keinen
Master. Alle gleichberechtigt. Baudrate bis 115k wäre nicht schlecht.
Die Leitungslängen sind maximal zwei Meter lang.
Overflow
Overflow schrieb:> Es ist quasi wie ein Chat. Einer der vier sendet, die anderen drei> Empfangen. Senden soll nur möglich sein, wenn eben gerade nichts über TX> herein kommt. Der Buffer soll 256 Zeichen betragen. Jeder der vier soll> immer an die jeweiligen drei anderen senden können. Es gibt keinen> Master. Alle gleichberechtigt.
Das wird m.E. mit RS232 nicht funktionieren, wie vermutlich schon
im anderen Thread (wie wärs mit einem Link?) stand.
Es gibt Wandler von RS-232 auf RS-485.
Die Sende/Empfangsumschaltung kann man mit einem retriggerbaren Monoflop
realisieren,
Den Buszugriff (CSMA/CD) muss dann die Software realisieren.
Versuch es doch mal, ich binn gespannt was da passieren soll !
Ein tip : Wen 1 Rx parallel an 4 Tx geschaltet werden, functioniert ess
nicht mehr. So wenn nicht gesendet werd, mussen den ausgagn Tx auch
"frei" geschaltet werden. Noch einen tip : GND von alle 4 Teilnehmer
mussen verbunden werden. Oder du muss mit optocoupler alles galvanisch
trennen.
Overflow schrieb:> Hallo, ich habe vier Geräte, die miteinander Kommunizieren sollen. Sie> haben eine RS232 Schnittstelle. Daran möchte ich nichts ändern.
Um die RS232-Schnittstellen busfähig zu machen, musst du an der
bestehenden Hardware gar nichts ändern, sondern nur etwas hinzufügen,
nämlich jeweils einen RS232-RS485-Konverter. Auf Softwareseite brauchst
du natürlich ein darauf abgestimmtes Kommunikationsprotokoll.
Ganz ohne zusätzliche Elektronik geht es mit einer Ringtopologie
(ähnlich dem Token-Ring, aber mit Weiterleitung der Nachrichten per
Software). Du brauchst dafür lediglich eine spezielle Verkabelung und
natürlich ein entsprechendes Kommunikationsprotokoll. Ein möglicher
Nachteil dabei ist, dass eine Nachricht nicht ohne Zeitversatz an
mehrere andere Teilnehmer geschickt werden kann. Das geht nur in
Bussystemen.
Eine weitere Möglichkeit wäre eine Sterntopologie mit zentralem
Vermittler auf RS232-Basis. Für den Vermittler brauchst du aber
mehr Hardware als bei den beiden anderen genannten Verfahren.
Overflow schrieb:> Der Buffer soll 256 Zeichen betragen.> Senden soll nur möglich sein, wenn eben gerade> nichts über TX herein kommt.> Es gibt keinen Master. Alle gleichberechtigt.
Das ist eine Frage der Software. Da aber auch diese nicht in die Zukunft
schauen kann, müssen alle Teilnehmer Kollisionen erkennen und ggf. nach
einem zufälligen Delay wiederholen. Wie im echten Leben, wenn sich Leute
unterhalten.
Die Schaltung würde so aussehen:
Am Ende geht alles.
Einer sendet, alle hören geht mit dominatem Pegel (per Diode oder open
Kollektor) oder tristate.
Kollisionserkennung und -Vermeidung geht auch "irgendwie" (Zeit,
mehrfach, mithören, Token passing,
Du kannst jedes Rad neu erfinden, von jedem beliebigen Startpunkt.
Und es ist lehrreich, also nur zu!
Also einfach zusammenstricken geht nicht. Da muss schon etwas den
Datenverkehr steuern.
Ich würde eine µC-Lösung nehmen. Vier Hardware-UART haben ja die z.B.
ATMegas der Serie 640. SDRAM haben die auch genug für größere Buffer.
Also ein vierfach 232-Chip dran und den Rest macht dann der µC mit
geringem Softwareaufwand.
Overflow schrieb:> ...Sie haben eine RS232 Schnittstelle. Daran möchte ich nichts ändern...> ...es gibt keinen Master. Alle gleichberechtigt...
Ziemlich dumme Idee das ganze.
Die Ausgänge sind in der Regel Pull/Push und somit knallt es sowie du
versuchst zwei davon zusammen zu schalten. Du musst dir erstmal eine
Schaltung bauen die bei Bedarf nur einen Sender durchschaltet. Eine
Kollision Erkennung gibt es bei RS232 von Hause aus auch nicht, auch
hier musst du dir eine entsprechende Schaltung erstmal selbst
zusammenbauen. Eine Menge Aufwand blos um krampfhaft an einem
Designfehler festzuhalten...
- https://en.wikipedia.org/wiki/Push%E2%80%93pull_output
-
https://en.wikipedia.org/wiki/Carrier-sense_multiple_access_with_collision_detection
Overflow schrieb:> Hallo, ich habe vier Geräte, die miteinander Kommunizieren sollen. Sie> haben eine RS232 Schnittstelle.
Eigenlich ganz einfach. Du verschaltest die quasi zu einem Ring. TX vom
erstenGerät wird mit RX vom 2. Gerät verunden. Dann immer so weiter. TX
vom letzten Gerät wird mit RX vom 1. Gerät verbunden womit sich der
Kreis schließt.
Der Rest ist dann ein passendes Protokoll, also im Endeffekt Software.
Jedes Gerät bekommt eine ID. Diese wird dann als erstes gesendet. Wird
die ID von einem der Geräte erkannt dann werden alle folgenden Daten bis
zu einer Endkennung verarbeitet. Nachrichten mit einer nicht passenden
ID werden einfach durchgereicht.
Nachteil der Methode ist halt, das die Laufzeiten der Nachrichten von
der Position der Geräte in der Kette abhängig sind.
Stefan ⛄ F. schrieb:> Das ist eine Frage der Software. Da aber auch diese nicht in die Zukunft> schauen kann, müssen alle Teilnehmer Kollisionen erkennen und ggf. nach> einem zufälligen Delay wiederholen. Wie im echten Leben, wenn sich Leute> unterhalten.>> Die Schaltung würde so aussehen:
Overflow schrieb:> Hallo, ich habe vier Geräte, die miteinander Kommunizieren sollen. Sie> haben eine RS232 Schnittstelle.
Dann baut man sich einen Master: RPi Zero oder vergleichbar (lies: PC)
mit einem FT4232H für die 4 UARTs (plus RS232 Wandler falls RS232 Pegel
benutzt werden).
RS232 ist nicht ernsthaft busfähig, daher benutzt man besser was
"intelligentes" in der Mitte.
Alles andere bräuchte Änderungen auch auf den Geräten am Bus.
Hallo,
das geht nicht mit mehr als zwei Teilnehmern gleichzeitig, da alle
sendenden Teilnehmer ihren definierten (Ruhe)Pegel auf die Leitung
legen.
RS485 hat open colector Ausgänge, da kann mehr als ein Teilnehmer
nacheinander senden.
Overflow schrieb:> Hallo, ich habe vier Geräte, die miteinander Kommunizieren sollen. Sie> haben eine RS232 Schnittstelle. Daran möchte ich nichts ändern.Kannst du nichts oder willst du nichts daran ändern?
Wenn du nichts daran ändern kannst, dann schalte fertige kommerzielle
RS232-RS485-Schnittstellenwandler dazwischen.
Wenn du nichts daran ändern willst, dann schalte fertige kommerzielle
RS232-RS485-Schnittstellenwandler dazwischen.
> Senden soll nur möglich sein, wenn eben gerade nichts über TX> herein kommt.
Über TX kommt sowieso nichts rein, weil das T von transmit (= senden)
kommt. Aber auch an RX ist eigentlich nach jedem einzelnen Byte erst mal
"Schluss", bis mit einem neuen Startbit die Übertragung des nächsten
Zeichens startet.
> Es gibt keinen Master. Alle gleichberechtigt.
Das funktioniert ja schon im echten Leben nicht. Selbst Gruppen mit
vielen "gleichberechtigten" Diskussionsteilnehmern müssen sich
organisieren, damit man den versteht, der gerade "das Wort hat".
Fazit: es gibt immer einen (temporären) Master. Das ist der, der gerade
eine Kommunikation initiiert. Wenn der nicht alleiniger "Chef" sein
darf, dann quatscht ihm ein anderer zweiter gleichberechtigter "Chef"
einfach dazwischen und alle anderen hören nur Müll.
Das Problem, den nächsten Master zu bestimmen, nennt sich
"Arbitrierung".
> Es ist quasi wie ein Chat. Einer der vier sendet, die anderen drei> Empfangen.
In einem "Chat", wie du ihm kennst (z.B. von Foren oder FB oder
WhatApp...) sorgt die Software dafür, dass du die Botschaften der
anderen unverstümmelt am Stück erhältst. Denn sonst würde eine "Ja,
Nein, Weiß nicht" Antwort von 5 Teilnehmern so aussehen: "WjeineaßN
jniniecahtin".
Und jetzt ist das Entschlüsseln dieser Antworten ja noch relativ
einfach. Im realen Leben mit ausführlicheren oder variablen Antworten
käme nur Müll raus, auf die Frage "Wie alt seid ihr?" lautet die Antwort
"3154378352" --> ?? Ende Gelände.
Wenn du also auch die Software nicht ändern "kannst", "willst" oder
"möchtest", dann ist Schicht im Schacht.
> Baudrate bis 115k wäre nicht schlecht.> Die Leitungslängen sind maximal zwei Meter lang.
Diese Parametern sind erstmal nicht dein Problem.
Und noch ein Nachtrag: eine der simplen Nutzungsbedingungen lautet
pro Thread nur 1 Nutzername
Das gilt auch für alteingesessene User!
Das geht ganz problemlos.
Auch Stefanus hat das Anfangs schon gezeigt.
Die Empfangsroutine muß sowieso zwischen richtigen Daten und Störungen
unterscheiden, da kann sie auch dem Sender sagen das er seine Nachricht
wiederholen muß.(Und natürlich das er nicht losplappert solange
gesprochen wird.) Vielleicht verschiedene Wartezeiten einstetzen sonst
gehts wie bei den Diskusionen im TV: alle quatschen gleichzeitig. 485
hätte die selben Einschränkungen wäre aber besser für lange Leitungen.
Stefan ⛄ F. schrieb:> Die Schaltung würde so aussehen:> 10kΩ> TxD 1 o----|>|----+----[===]----0 -12V> |> RxD 1 o-----------+> |> |> TxD 2 o----|>|----+> |> RxD 2 o-----------+
Man braucht keine negative Versorgungsspannung, wenn man über die Dioden
je einen Widerstand 3k3 - 4k7 legt. Die passiven Teilnehmer ziehen die
Leitung dann auf negativen Pegel.
Ach was! Rs232-Teilnehmer sind von Natur aus geduldig und vor Allem
neugierig, was die Gegenseite zu sagen hat. Das funktioniert wie beim
Doppelkopf, da hat auch nur immer Einer den Hut auf.
hallo
ich schlage folgendes vor. Ein Arduino Mega hat 4 RS232 Schnittstellen.
Diese sind zu einen Ring zur schalten. Also mit einen, wie oben
erwähnten Token arbeien.
Es wird das Programm einfacher als mit rs485. Bei diesen muss
noch berücksichtigt werden, wer am Buss senden darf.
Falls man über das
Protokoll wissen würde,könnte man vielleucht noch Vereinfachungen
finden.
Resüme: Software nicht unterschätzen!
Nachdem nun wahrlich genug Vorschläge gemacht worden sind, wäre es doch
interessant zu wissen, ob der TO sich schon entschieden hätt. Und wenn
ja, wie es denn mit dem Erfolg aussieht!!
Gruß Rainer
Man kann auch CAN-Transceiver nehmen, dann entfällt die
Richtungsumschaltung. Die Kollisionserkennung muß man ja eh in Software
machen.
Die einfachste Lösung ist natürlich, man nimmt gleich MCs mit CAN.
Rainer V. schrieb:> Nachdem nun wahrlich genug Vorschläge gemacht worden sind, wäre es> doch interessant zu wissen, ob der TO sich schon entschieden hätt.
Overflow hat sich nicht mehr gemeldet? Ja sowas aber auch!
Ihr sitzt aber auch jedem Troll auf ...
Harald W. schrieb:> Das wird m.E. mit RS232 nicht funktionieren, wie vermutlich schon> im anderen Thread (wie wärs mit einem Link?) stand.
Mit etwas Geschick geht das schon. Einer meiner Kunden setzt das genau
so ein. Wurde von mir in meiner Anfangszeit als Selbständiger
entwickelt. Man kann bis zu 16 Geräte einsetzen, was am Ende durch die
minimale Bandbreite begrenzt ist.
a) Die analoge Lösung:
Es funktioniert mit einer Arbitrierungsphase, Kollisionserkennung und
vorgeschriebenen time slots. Jeder Sensor, der sich anmeldet, muss
mithören, ohne zu RX zu bestätigten, also TX zu bedienen. Es gibt immer
einen freien TimeSlot, in dem sich nichts tut. Diese werden
durchgezählt, indem sich die Sensoren melden und eine Nummer funken.
Bestätigen tut es nur der nächste / oder der der angefunkt wird. Erkennt
ein neuer Sensor, dass er einen freien time slot hat, macht er einfach
mit, was die anderen merken und sich einen neuen Teilnehmer in ihre
Tabelle eintragen. Nötig dafür ist eine Steuerung der TX-Leitung per
Tristate-Buffer oder einem wired "or".
Nutzbar ist das für teilinstallierte Strecken mit einer nicht änderbaren
Verkabelung im token-style, wie es früher für Busse gerne benutzt wurde,
die man aber beschleunigen möchte. Faktische Geschwindigkeit: 230bps
über bis zu 30m, mit rund rund 80% Nettobandbreite für alle Teilnehmer.
Also z.B. 10% für 8 Sensoren.
d) Die digitale Lösung: Es gibt ein zentrales Steuersystem, bei dem alle
Leitungen einlaufen und ein PLD, dass jeden einzelnen abfertigt und als
Matrix läuft. Solange die Bandbreite und das Sendeverhalten es hergeben,
können alle an alle senden. Nötig: Abtastrate im PLD = 2x Teilnehmerzahl
x 230kbps. Allerdings ist auch hier overhead, weil die Zentrale
konfiguriert werden muss, auswählen muss etc. Insgesamt war das der
Vorläufer von dem hier: http://www.96khz.org/htm/midiviaspdif.htmIngo W. schrieb:> Es gibt Wandler von RS-232 auf RS-485.
Das ist die sauberste Lösung, wenn man alles selber aufbauen kann.
Jürgen S. schrieb:> Ingo W. schrieb:>> Es gibt Wandler von RS-232 auf RS-485.> Das ist die sauberste Lösung, wenn man alles selber aufbauen kann.
Ich weiß nicht, was daran nun sauber sein soll, zumal es die Vorgaben
vom TO einfach ignoriert. Differnetielle Übertragung ist überhaupt nicht
notwendig und bei 2 m Leitungslänge reicht Klingeldraht.
Stefan ⛄ F. schrieb:> Der TO hat sich jetzt 6 Tage lang nicht zu den Antworten geäußert. Ich> finde das ziemlich undankbar.
Na ja, mit dem Umzug mußt Du ja auch noch bis zum 8. Mai warten: in D
Tag der Befreiung mit neuer Bedeutung ;-)
m.n. schrieb:> Ich weiß nicht, was daran nun sauber sein soll, zumal es die Vorgaben> vom TO einfach ignoriert. Differnetielle Übertragung ist überhaupt nicht> notwendig und bei 2 m Leitungslänge reicht Klingeldraht.
Es geht ja um die Verschaltung mehrerer Einheiten auf einem Bus und das
ist nur bei RS-485 so einfach als Stern machbar. RS 232 ist erst einmal
eine P2P.
Jürgen S. schrieb:> Es geht ja um die Verschaltung mehrerer Einheiten auf einem Bus und das> ist nur bei RS-485 so einfach als Stern machbar. RS 232 ist erst einmal> eine P2P.
Ich denke, dass siehst du falsch. Es wurden einfache Schaltungen
gezeigt, die das bei RS232 ermöglichen.
Viel wichtiger ist aber, dass die Software auf Half-Duplex Kommunikation
umgeschrieben wird (falls nicht bereits der Fall) und dass sie mit
Kollisionen sinnvoll umgeht. Ein Umbau auf RS485 ändert daran gar
nichts.
Die Software ist der Knackpunkt. Das wurde bereits in den ersten
Antworten klar gestellt. Ob der TO die Software anpassen kann/will,
wissen wir nicht. Bis dahin ist es völlig sinnlos, hier weiter zu
diskutieren. Zumal bereits alles erdenkliche mehrfach geäußert wurde,
nur noch nicht von jedem.
Die Diskussion dreht sich weiterhin planlos im Kreis.
Stefan ⛄ F. schrieb:> Der TO hat sich jetzt 6 Tage lang nicht zu den Antworten geäußert. Ich> finde das ziemlich undankbar.
Kommt ja leider öfter hier vor. Ich frage mich, was für „Leute“ das sein
mögen… Vermutung: Denen wird auf der Arbeit eine Aufgabe vorgeworfen,
tippen den Kram mangels eigener Ideen ins Internet ein. Dann kommt ein
Kollege um die Ecke und sagt, ah brauchst net, das geht doch so und so.
Abgehakt, scheißegal, was kümmert einen schon das Hilfsangebot von
Mitmenschen, das man nicht mehr benötigt.
Stefan ⛄ F. schrieb:> Ich denke, dass siehst du falsch.
? Ich zitiere mal den TO:
Overflow schrieb:> Es ist quasi wie ein Chat. Einer der vier sendet, die anderen drei> Empfangen.
Das geht P2P nur mit 4 Ausgängen bei 4 Teilnehmern oder einem
multiplexten Bus.
Stefan ⛄ F. schrieb:> Es wurden einfache Schaltungen> gezeigt, die das bei RS232 ermöglichen.
Worauf beziehst du dich?
Stefan ⛄ F. schrieb:> Der TO hat sich jetzt 6 Tage lang nicht zu den Antworten geäußert. Ich> finde das ziemlich undankbar.
Der TO ist nicht undankbar, aber viel beschäftigt. Also erst einmal
vielen Dank für die Infos und Anregungen!
Ich habe mich erst einmal für eine andere Lösung entschieden. Ich habe
ein Java-Programm geschrieben (vorerst nur COM-Ports, also Windows),
welches mein Problem soweit löst.
Mein Programm verlangt nach mindestens drei Schnittstellen, sonst macht
es ja auch keinen Sinn.
Neben allen möglichen Einstellungen, gibt es die Möglichkeit einen
Standard z.B. 9600 8 N 1 zu laden. Dafür existiert eine separate Datei.
Solange freie Schnittstellen vorhanden sind, kann man sie hinzufügen.
Man kann sie auch wieder entfernen. Bis auf drei natürlich.
Mit Laden bzw. Speichern kann ich Einstellungen speichern.
Über Angleichen werden die Konfigurationen der ersten Schnittstelle
(ganz links) auf die anderen übertragen.
Für jede Schnittstelle kann ich noch festlegen ob RX + TX oder nur TX
oder nur RX.
Und beim Programmstart kann automatisch die letzte gespeicherte
Konfiguration eingelesen und direkt gestartet werden.
Als Libs kommen jssc-2.9.2.jar und slf4j-jdk14-1.7.32.jar zum Einsatz.
Overflow schrieb:> Der TO ist nicht undankbar, aber viel beschäftigt.
8 Tage nicht antworten hat definitiv etwas mit Undankbarkeit zu tun und
nicht mit ging nicht weil "viel beschäftigt". Tip: Im Zweifelsfall mal
andere Menschen befragen, die naturgemäß viel Umgang mit anderen
Menschen haben.
Schön auch, dass wir jetzt einen Roman und einen Screenshot deiner
Speziallösung haben, in der Du Baudraten ändern und sogar speichern
kannst. Das ist der Input, auf den alle gewartet haben.
Overflow schrieb:> Ich habe mich erst einmal für eine andere Lösung entschieden. Ich habe> ein Java-Programm geschrieben (vorerst nur COM-Ports, also Windows),> welches mein Problem soweit löst.
Das wäre auch mit VSPE von eterlogic gegangen. Kostet um die 30 € für
zwei PCs.
Overflow schrieb:> Als Libs kommen jssc-2.9.2.jar und slf4j-jdk14-1.7.32.jar zum Einsatz.
Versteh nun nur Bahnhof, ich dachte es geht darum wie man das technisch
machen kann?
Overflow schrieb:> Es ist quasi wie ein Chat. Einer der vier sendet, die anderen drei> Empfangen. Senden soll nur möglich sein, wenn eben gerade nichts über TX> herein kommt. Der Buffer soll 256 Zeichen betragen. Jeder der vier soll> immer an die jeweiligen drei anderen senden können. Es gibt keinen> Master. Alle gleichberechtigt. Baudrate bis 115k wäre nicht schlecht.> Die Leitungslängen sind maximal zwei Meter lang.
Wie machst du es denn nun mit Java? Kann man mit Java löten und
verdrahten? Welche der Libs ist das, das hätte ich gern gewusst :-)
TS
Thorsten S. schrieb:> Versteh nun nur Bahnhof, ich dachte es geht darum wie man das technisch> machen kann?
Der erste Text war nur zur völligen Verwirrung und beschreibt nicht sein
Problem.
Er will nur 3 serielle Geräte an einen PC anschließen und dafür kann man
einfach 3 COMs öffnen.
Peter D. schrieb:> Er will nur 3 serielle Geräte an einen PC anschließen und dafür kann man> einfach 3 COMs öffnen.
Tja, die Blüten des Forums. Nein, er will nicht einfach drei COMs
öffnen. Sondern es sind vier Geräte vorhanden, deren TX-Daten von den
anderen empfangen werden sollen.
Stefano (Gast) schrieb::
> Das wäre auch mit VSPE von eterlogic gegangen.
Das kannte ich nicht. Habe mir eine Lizenz gekauft. Nicht ganz
selbsterklärend, aber man splittet die COM-Ports und bekommt vier
virtuelle COM-Ports. Und dann verbindet man die vier virtuellen
COM-Ports mittels Bridges.
Als nächstes wird es wohl auf eine µC-Lösung hinaus laufen.
Overflow schrieb:> Nicht ganz> selbsterklärend, aber man splittet die COM-Ports und bekommt vier> virtuelle COM-Ports. Und dann verbindet man die vier virtuellen> COM-Ports mittels Bridges.
Das ist ja clever!
