CAN mit sehr vielen Busteilnehmern

[Alexander H. (ill_son)]

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

[(prx) A. K. (prx)]

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.

[Jeffrey L. (the_dude)]

Bedenke dass Repeater auch Zeit benötigen. Die max. Kabellänge resp. 
Busausdehnung ist von der Baudrate abhängig:

http://infosys.beckhoff.com/content/1031/fc510x/html/co_inswirbus.htm#Busl%C3%A4nge

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

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.

[Alexander H. (ill_son)]

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

[(prx) A. K. (prx)]

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.

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

Sorry, Tippfehler, so heißt der Chip: AMIS42770

Link:
http://www.onsemi.com/PowerSolutions/product.do?id=AMIS-42770
http://www.onsemi.com/pub/Collateral/AMIS-42770-D.PDF

[(prx) A. K. (prx)]

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.

[Alexander H. (ill_son)]

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