Goto page Previous 1, 2
Marte Schwarz
Guest
Tue Jan 12, 2010 9:05 am
Hi Falk,
Quote:
Ich glaube nicht, daß es etwas Fertiges für Deine Anforderung gibt.
Dem schließe ich mich an.
Quote:
Eine Lösung zu bauen wäre aber auch kein Hexenwerk
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.
Quote:
(wenn die 'Meßdingsbumse' (Ich liebe dieses Wort, Sensoren klingt so öde)
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" ;-)
Quote:
nicht gerade ein AKW moderieren oder einen Defibrillator steuern).
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
Marte Schwarz
Guest
Tue Jan 12, 2010 9:30 am
Hi,
Quote:
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.
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.
Quote:
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.
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.
Quote:
Probleme sehe ich eventuell bei der Kommunikation zwischen PC und dem
Verteiler. 1 MBit ist für die serielle Schnittstelle nicht unbedingt
Standard.
Huch? Das macht doch mittlerweile jeder billigste USB-COM-Wandler mit. Oft
gehen sogar 2 MBit/s
Quote:
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.
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.
Quote:
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,
Stichleitungen sind bei RS422 auch nicht vorgesehen.
Quote:
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.
Und hat dann ggfs Glück, dass die Reflexionen nicht wieder als Datenpaket
interpretiert werden ;-)
Quote:
Wenn die Messdingsbumse direkt nebeneinander liegen, ist das natürlich
kein so großes Problem.
Oder einfach, wie vorgesehen eine eindimensionale Struktur verwendet wird,
wie sie bei den RS422 vorgesehen ist.
Marte
Stefan Brröring
Guest
Tue Jan 12, 2010 11:45 am
Quote:
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.
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.
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.
Quote:
Probleme sehe ich eventuell bei der Kommunikation zwischen PC und dem
Verteiler. 1 MBit ist für die serielle Schnittstelle nicht unbedingt
Standard.
Huch? Das macht doch mittlerweile jeder billigste USB-COM-Wandler mit. Oft
gehen sogar 2 MBit/s
mag sein...
Quote:
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.
Und hat dann ggfs Glück, dass die Reflexionen nicht wieder als Datenpaket
interpretiert werden ;-)
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
Sven Schulz
Guest
Tue Jan 12, 2010 10:17 pm
Marte Schwarz wrote:
Quote:
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.
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.
Quote:
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.
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.
Quote:
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.
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
Sven Schulz
Guest
Tue Jan 12, 2010 10:39 pm
Stefan Brröring wrote:
Quote:
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.
Soweit ich weiß muß ich mich bei SPI um die logischen Kommunikationsslots
selber kümmern. Das war, glaube ich, bei CAN schon "mitgeliefert".
Sven
Falk Willberg
Guest
Tue Jan 12, 2010 10:54 pm
Sven Schulz schrieb:
Quote:
Stefan Brröring wrote:
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.
Soweit ich weiß muß ich mich bei SPI um die logischen Kommunikationsslots
selber kümmern. Das war, glaube ich, bei CAN schon "mitgeliefert".
Das SPI, das ich kenne, besteht aus zwei Schieberegister mit einem Draht
zwischen Ein- und Ausgang und einem für Takt ;-)
Falk
Sven Schulz
Guest
Tue Jan 12, 2010 11:19 pm
Falk Willberg wrote:
Quote:
Das SPI, das ich kenne, besteht aus zwei Schieberegister mit einem
Draht zwischen Ein- und Ausgang und einem für Takt ;-)
CAN scheint die einfachere Lösung zu sein. Datagramm bauen, senden/empfangen
und vergessen.
Hergen Lehmann
Guest
Tue Jan 12, 2010 11:55 pm
Sven Schulz schrieb:
Quote:
CAN scheint die einfachere Lösung zu sein. Datagramm bauen, senden/empfangen
und vergessen.
.... aber nicht bei mehreren Teilnehmern, die mit hohen Anforderungen an
den Datendurchsatz miteinander konkurrieren. Für sowas ist CAN nicht
konzipiert, da ist es mit dem deterministischen Verhalten schnell vorbei.
Hergen
Marte Schwarz
Guest
Wed Jan 13, 2010 12:36 am
Hallo Hergen,
Quote:
CAN scheint die einfachere Lösung zu sein. Datagramm bauen,
senden/empfangen und vergessen.
... aber nicht bei mehreren Teilnehmern, die mit hohen Anforderungen an
den Datendurchsatz miteinander konkurrieren. Für sowas ist CAN nicht
konzipiert, da ist es mit dem deterministischen Verhalten schnell vorbei.
CAN ist gerade wegen der Eigenschaften zu deterministischem Verhalten
interessant. Allerdings will da viel Hirn in die Zuweisung der Adressen
gehen, da hier auch die Priorisierung auf dem Bus entschieden wird.
Marte
Hergen Lehmann
Guest
Wed Jan 13, 2010 1:55 am
Marte Schwarz schrieb:
Quote:
CAN ist gerade wegen der Eigenschaften zu deterministischem Verhalten
interessant. Allerdings will da viel Hirn in die Zuweisung der Adressen
gehen, da hier auch die Priorisierung auf dem Bus entschieden wird.
Ja, eben. Priorisierung versagt aber leider kläglich, wenn mehrere
Teilnehmer auf einem zu 100% ausgelasteten Medium zeitgleich grosse
Datenmengen loswerden wollen. Da beisst der letzte schlicht und einfach
deterministisch ins Gras.
Mit einem zwar formal nicht-deterministischen, aber aufgrund geringer
Auslastung selbst im worst-case immer noch schnellen Medium kommt man da
deutlich weiter.
In diesem Sinne würde ich über getrennte RS422-Verbindungen an
RS422/Ethernet-Umsetzern durchaus nachdenken. Auf einem 100MBit oder gar
GBit-Ethernet dürften die Verzögerungen selbst im Worstcase immer noch
vernachlässigbar klein sein gegenüber der Zeit, die die Übertragung
eines Paketes über die RS422 benötigt.
Hergen
Michael Schwingen
Guest
Fri Jan 15, 2010 10:21 pm
Sven Schulz <Sven-Schu_at_arcor.de> schrieb:
Quote:
Klar, deren Lösung heißt Ethernet, Portswitch o.ä.
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).
Full-Duplex-Ethernet auf einem Point-2-Point-Link (sprich: eigene Steckkarte
im PC, und nur der Terminalserver am anderen Ende) sollte recht gut
funktionieren - kommt halt 'drauf an, *wie* schnell es im worst case gehen
muß.
cu
Michael
Goto page Previous 1, 2
