Hallo,
im Rahmen einer Studienarbeit soll ich mir über die Realisierung der
Kommunikation in einem System Gedanken machen. Die Problematik ist wie
folgt. Es sollen zyklisch Daten (sagen wir mal ca. 64 Byte) von einem
Master an eine große Anzahl (3- bis 4-stellig) von Teilnehmern gesendet
werden, möglichst gleichzeitig, ohne Quittierung oder ähnlicher
Sicherheit, was eh kaum möglich wäre. Systemausdehnung ist vielleicht
einige 100m. Die Teilnehmer selbst senden keine Daten. Nun hatte ich mir
überlegt, das mit CAN zu machen. Broadcast ist er sowieso und ein
Problem mit Adressierung gibt es auch nicht. Wäre das möglich, wenn man
in Abständen immer wieder mal einen Repeater vorsieht?
Grüße, Alex
Bei CAN kommst du um die Berücksichtigung der Zeitbedingungen nicht
herum, weil schon aufgrund des ACK Bits bidirektional. Einzig bei einem
CAN, dessen Massen-Nodes rein passiv ohne ACK arbeiten, entfällt das. Im
Grund drehen sich aber alle Vorteile von CAN gegenüber RS485 bei dir in
Nachteile um.
Rein unidirektional betrieben ist die Technik von RS422/485 sehr viel
einfacher an eine grosse Anzahl Nodes adaptierbar.
Schaue dir den AMIS542770 an. Wenn Du was fertiges suchst kenne ich eine
Firma die dir das verkaufen könnte. Schreib mir dann eine PN.
Wir haben damit schon Anlagen mit über 500 CAN Teilnehmer realisiert.
Hallo,
danke für die Antworten.
@Jeff und A.K.: RS485 wäre in der Tat eine Alternative, allerdings ist
da, wenn ich das richtig gelesen habe, die Teilnehmeranzahl aufgrund
elektrischer Bedingungen noch mehr limitiert als bei CAN. Ich habe da
was von 32, mit neueren Bausteinen bis 256 gelesen.
CAN wäre insofern interessant, dass man eben auch mal was zurücksenden
könnte, wenn man z.B die Broadcast-Daten am höchsten priorisiert und die
Fehlermeldungen entsprechen niedrig.
@Markus: Danke, aber ich möchte nichts bauen. Ich soll mir als einen
Teil meiner Arbeit ein Kommunikationskonzept überlegen, also erstmal
rein theoretischer Natur. Und die Bedingungen, die sich für mich
ergeben, sind: viele Teilnehmer, lange Leitung und zyklische Daten per
Broadcast in fast ausschließlich eine Richtung. Die ersten beiden Punkte
machen es halt etwas schwierig. Ich bin auch nicht auf CAN festgelegt,
hatte mir das nur überlegt, weil mir aufgrund der Bedingungen (besonders
die vielen Teilnehmer) nichts anderes einfiel. Für Vorschläge bin ich da
offen und dankbar.
Momentan denke ich gerade noch über Ethernet bzw. etwas darauf
aufgesetztes nach.
Zu AMIS542770 liefert mir Google gar nichts. Hast Du Dich vielleicht
vertippt?
Grüße, Alex
Alexander H. schrieb:> elektrischer Bedingungen noch mehr limitiert als bei CAN. Ich habe da> was von 32, mit neueren Bausteinen bis 256 gelesen.
Bei unidirektionalem Betrieb hindert dich niemand daran, genug
Transmitter an den UART Ausgang zu hängen, um damit ein Dutzend
getrennte aber parallel arbeitende Busse aufzubauen. Einfacher gehts
wirklich nicht mehr.
Alexander H. schrieb:> CAN wäre insofern interessant, dass man eben auch mal was zurücksenden> könnte, wenn man z.B die Broadcast-Daten am höchsten priorisiert und die> Fehlermeldungen entsprechen niedrig.
Was dann so ungefähr das Gegenteil der ursprünglichen genannten Aufgabe
darstellt. Solltest schon wissen, was genau du eigentlich willst.
Ich weiß schon, was ich möchte, was mich aber nicht daran hindert,
weiter darüber nachzudenken. Die Rückantworten kämen ja nur sporadisch
und wären bei CAN einfacher zu implementieren. Ob das notwendig ist,
muss ich mir noch überlegen. Im Prinzip ist es bei meiner Anwendung
egal, ob mal ab und ein Datenpaket hinten runterfällt. Wichtiger wäre
es, wenn ein Teilnehmer meldet, dass etwas bei ihm defekt ist, was aber
nur sehr selten passieren und, wie schon gesagt, bei CAN dann inklusive
wäre.
Grüße, Alex
Eine eigene Frage?
Dieser Thread ist über 11 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
