Switch für Serielle Kommunikation mit RS422/485

Hi Sven,

AFAIR baut NEC µCs mit einer großen Anzahl eingebauter Schnittstellen. evtl kommst Du mit denen ans Ziel. Ansonsten könntest Du µCs mit 2 USART zur Pufferung jedes langsamen Teilnehmers einsetzen. Die Software für jeden einzelnen "Puffer" sollte so schwer nicht sein.

Marte

Diese Idee hatte ich auch. Das heißt leider es müßte Hardware und Software aufgebaut und programmiert werden. Es wäre vermutlich einfacher soetwas von der Stange zu kaufen. Nur woher?

Sven

Sven Schulz schrieb:

Da es bei RS485 kein einheitliches Protokoll gibt, dürfte es mit der Stange schwer werden. Es sei denn, der Hersteller deiner Messdingsbumse bietet zufällig so etwas passend zu seinen Geräten an...

Hergen

Sven Schulz schrieb:

Wie wäre es mit einem Terminal/Device-Server, also Ethernet auf n* Seriell? Die Teile gibt es fertig, incl. virtuellem COM-Port für Windows.

Oder muß es unbedingt "echt" seriell in den PC?

cu Michael

Ja, doch ich weiss nicht ob Dein Protokoll damit funktioniert:

Falls der Link nicht klappt, es ist ein "Edgeport USB to 8PT RS232" mit acht RS232 Schittstellen. Der PC muesste aber ueber USB angeschlossen werden. Soll 230kbps schaffen.

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Hi Jörg,

Huch, für 8 USB-Seriellwandler und ein bischen USB-Hub so viel Geld ausgeben?

Marte

Genau sowas würde ich auch vorschlagen. Kommunikation dann aber nicht über virtuellem COM-Port, was natürlich auch geht, sondern direkt per IP-Socket. Meist ist das Port 4000, 4001 usw.

Wir setzen für sowas Moxa5230 o.ä. ein.

Wobei sich noch die Frage stellt, ob es tatsächlich 8x RS485/RS422 sein muss, oder ob die 8 Geräte per RS485/RS422 Bus kommnizieren. Wenn letzteres zutrifft würde man ja nur einen RS485/RS422 Kanal benötigen.

Gruß

Stefan DF9BI

Hallo,

stellvertretend für alle anderen Antworten:

Ja, es muß ein echter serieller Port sein. Auf den PC läuft Real-Time-OS, das mit dem seriellen RS422/485-Port 'richtig' verbunden ist. Schon aufgrund der Echtzeitanforderungen scheiden Kommunikationsformen mit zufälligem Charakter aus (z.B. Ethernet).

RS485 könnte als Bus verwendet werden um den PC und alle 'Meßdingsbumse' miteinander zu verbinden. Leider wird der Bus nur mit der maximalen Rate von

256kBit/s arbeiten können. Daher war die Idee geboren die 'Meßdingsbumse' als Stern mit 256kBit/s zusammenzufassen und dann speist der PC den Sternverteiler mit 1MBit/s.

Dieses 'Problem' müßten aber schon andere gehabt haben, von vielen kleinen Datenquellen in eine große Senke Daten einsammeln.

Sven

Das muß 256kBit/s heissen, nicht 256MBit/s.

Sven

Sven Schulz schrieb:

...

Wie oft senden die 'Meßdingsbumse' denn? Dauerfeuer wird's ja wohl kaum sein, denn dann müßtest Du 8*256kBit/s (2MBit/s) in 1MBit/s stopfen und hättest die Mathematik gegen Dich.

Real-Time klingt danach, daß die Antworten sehr schnel erfolgen müssen, da ist mit Multiplexen nichts zu machen.

Klar, deren Lösung heißt Ethernet, Portswitch o.ä.

Ich glaube nicht, daß es etwas Fertiges für Deine Anforderung gibt. Eine Lösung zu bauen wäre aber auch kein Hexenwerk (wenn die 'Meßdingsbumse' (Ich liebe dieses Wort, Sensoren klingt so öde) nicht gerade ein AKW moderieren oder einen Defibrillator steuern).

Falk

Ist eben ein sehr kleiner Markt und es ist fast nur die Industrie die sowas noch braucht, i.d.R. in der Produktion. Hier gibt es z.B. viele CNC Drehbaenke die nur ueber 3-1/2" Disketten zu fuettern sind aber noch mindestens 2-3 Jahrzehnte in Betrieb sein werden. Da ist gelegentlich horten angesagt.

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Das ist nicht ganz einfach. Die Dingsbumse bekommen Teile der PC-Software hineinprogrammiert. Die Software wird auf dem PC ersteinmal auf ihre Funktion und Sinnhaftigkeit geprüft. Wenn das ok ist, dann wird auf dem Dingsbums die Software portiert. Schlagwort: Hardware-in-the-loop. Es ist also pro Entwicklungsschritt eine sich praktisch immer verändernde Datenmenge. Daher gibt es keine konkrete Antwort. Als Obergrenze gilt aber:

256kBit/s pro Dingsbums. Und die würde ich gerne voll ausschöpfen.

Nö. Real-Time ist nicht gleich bedeutend mit schnell. Das heißt nur das es nachvollziehbar sein soll. Oft werden Entwicklungen mit RT-Anforderungen mit monströsen Rechnern praktisch ausgehebelt. Also derart viel Power in die Erfassungshardware gepackt das der eigentliche zeitkritische Prozess völlig obsolet wird.

Ethernet wäre nur mit einem entsprechenden QoS denkbar, der eine nachvollziehbare Datenübertragung erlaubt. Ethernet ist 'von Natur aus' mit Zufälligkeiten behaftet (Kollisionen+Arbitrierung).

Weder noch. Ich denke das sollte auch ohne von der Stange machbar sein:

7 Mikrokontroller mit 1x UART und 1x CAN, alles läuft zum 8ten Mikrokontroller. Der redet mit CAN mit den anderen Controllern und mit seinem einen UART mit dem PC mit 1MBit/s.

Sven

Sven Schulzschrieb: "

Schwierig - die Daten müssen zwischengepuffert werden usw. ist viel zu speziell, als dass man das in preiswertes bekommen könnte.

Am einfachsten (und billigsten) erscheint mir da gleich eine gebrauchte Steckkarte für den PC, der 8x RS-232 auf dem Board hat (sowas wie Ebay 250555505970).

Dirk

Das geht sicherlich alles, wobei CAN vieleicht nicht die richtige Wahl ist. Für die Kommunikation zwischen den Prozessoren gibt es sicher einfachere und bessere Lösungen, z.B. sowas wie SPI.

Probleme sehe ich eventuell bei der Kommunikation zwischen PC und dem Verteiler. 1 MBit ist für die serielle Schnittstelle nicht unbedingt Standard.

Bei den Messdingsbumsen würde ich unbedingt prüfen, wie hoch die Übertragungsrate tatsächich sein muss. Bei 256 kBit kann es schon massive Probleme mit der RS485/RS422 Verkabelung geben.

Ich erinnere mich an ein System, wo ein RS422 Bussystem in Industrieumgebung aufgebaut wurde. Dort wurde 115 kBit/s gearbeitet. Das führte zu Problemen mit Stichleitungen, was man dann durch eine komplizierte Steckerlösung "behoben" hat. Dies steigerte dann die Fehleranfälligkeit des Gesamtsystems. Der Gag bei der Sache war, dass vom PC aus nur alle 50ms ein Datenpaket abgeschickt wurde, woraufhin die Endgeräte jeweils einen kurzen Burst zurückschickten. Der effektive Datendurchsatz war dann < 10 kBit/s. Auf der Busleitung waren immer nur kurze Bursts zu sehen.

Wenn die Messdingsbumse direkt nebeneinander liegen, ist das natürlich kein so großes Problem.

Gruß

Stefan DF9BI

Hi Falk,

Dem schließe ich mich an.

Sehe ich ähnlich. man nehme ein µC, der eigentlich nur zwei RS485 ansteuern können muss, einen mit 1 MBit/s und einer eben mit 256 kBit/s. Das Programm muss ja an sich nur feststellen, welchen Teilnehmer es bedienen muss und reicht Nachrichten an und für diesen transparent durch.

Hör mal, Sensoren, das sind einfache Keramikstückchen oder so was, aber nichts intelligentes, das sind dann entweder "Smartsensing Devices" oder eben auf deutsch "Meßdingsbumse" ;-)

Mit AKWs kenn ch mich nicht so aus, aber im Defi sollte so viel nicht schiefgehen. Da muss ohnehin durch das Protokoll sichergestellt sien, dass keine Zufallsfolge irgendetwas unvorhergesehenes auslöst.

Marte

Hi,

AFAIR hat der OP Meßdingensbumse, die mit RS485 kommunizieren wollen, nicht mit CAN. Dann sollte man diese jenigen auch mit RS485 bedienen wollen. Auf den anderen Seite scheint etwas PC ähnliches mit einem RTOS sein, das derzeit auch RS485 spricht. Ich gehe davon aus, dass an diesen Komponenten nicht allzuviel umgestrickt werden soll. Der OP möge sich äussern, wenn diese Annahmen falsch sind.

Und noch was nächstes. SPI und RS485 sind ja so ähnlich. Möglicherweise sind die Meßdingsbumse ja mehrere Meter abseits des PCs und weit im Feld verteilt. Mit RS485 kein Problem, mit SPI wirds da recht schnell eng.

Huch? Das macht doch mittlerweile jeder billigste USB-COM-Wandler mit. Oft gehen sogar 2 MBit/s

Da der OP noch nichts über Kabellängen und derartiges gesagt hatte, gehe ich davon aus, dass er an der Kante weiss, was er tut.

Stichleitungen sind bei RS422 auch nicht vorgesehen.

Und hat dann ggfs Glück, dass die Reflexionen nicht wieder als Datenpaket interpretiert werden ;-)

Oder einfach, wie vorgesehen eine eindimensionale Struktur verwendet wird, wie sie bei den RS422 vorgesehen ist.

Marte

Ich dachte auch eher daran, dass die Prozessoren für die Kommunikation direkt nebeneinander in einem Konzentrator untergebracht sind und per RS485 mit den Messdingsbumsen kommunizieren. SPI könnte man dann für die Kommunikation auf einem internen Bus nehmen, um die Daten vom PC zu den einzelnen Prozessoren zu verteilen.

mag sein...

Die Reflexion kommt viel früher und überlagert sich eventuell mit dem aktuellen, oder dem folgenden Bit, wobei es noch von der genauen geometrischen Anordnung abhängt, ob eine Reflexion zu einem Fehler führt oder nicht.

Man kann das einfach ausrechnen. Wenn man den Verkürzungsfaktor ignoriert und davon ausgeht, dass sich die Datenpakete mit Lichtgeschwindigkeit auf dem Kabel bewegen, hat man bei 256 kBit eine "Bitlänge" auf dem Kabel von ca. 0,25 us entsprechend 75m. Wenn ich jetzt eine offene Stichleitung mit l=lambda/4, also ca. 17m anbringe, treffen sich an der Kontaktstelle das Originalsignal und die Reflexion mit einer Verschiebung von 1/2 Bitbreite.

Tatsächlich gibt es bereits bei kürzeren Stichleitungen Probleme. Dazu kommen noch weitere witzige Effekte, z.B. in einem Bus mit 10 Slaves kann der PC mit den Slaves 3-10 problemlos kommunizieren, aber mit 1 und

2 gibt es ständig Probleme obwohl die wesentlich näher am PC sind. Oder, es gibt einen Kabelfehler bei Slave 2, aber alle Slaves, außer Nr. 8 funktionieren einwandfrei...

Die Fehlersuche in solchen Systemen macht dann echt Spaß...

Gruß

Stefan DF9BI

Korrekt. Wobei ich das so verstanden habe, wenn ich lediglich zwei RS485-Teilnehmern einen exklusiven Sendekanal und einen exklusiven Empfangskanal gebe dann kann ich mir den ganzen Aufwand mit einem Buskonzept sparen. Dann "wird es" zu einer RS422-Kommunikation. Somit braucht jedes Meßdingsbums lediglich eine RS422-Anbindung. Und kippt seine gesamten Daten in den UART, der auf RS422 umgesetzt wird. Empfangen wird ebenfalls ohne Kollisionen, wieder auf dem eigenen Empfangskanal. Wenn ich jetzt weiter in Richtung Switch denke, brauche ich also pro Meßdingsbums einen Mikrokontroller der einen UART-Port hat für das exklusive Senden und Empfangen der Daten von und zum Meßdingsbums.

Hier gehts weiter. Vom exklusiven Kommunikationspfad des Meßdingsbumses gehts weiter im Switch zum "Master-Mikrokontroller" der mit allen 7 Mikrokontroller redet. Ich nahm CAN, als Idee. Wegen der Hardwarearbitrierung, der relativ einfachen Datagrammstruktur, der Standartisierung wegen.

PC zum Switch ca. 6m. Meßdingsbums zum Switch ca. 3m. RS485/422 wurde aus reiner Vorsicht gewählt.

Mit Kritik bitte nicht zurückhalten.

Sven

Soweit ich weiß muß ich mich bei SPI um die logischen Kommunikationsslots selber kümmern. Das war, glaube ich, bei CAN schon "mitgeliefert".

Sven