Stern Topologie Bus System?

[Tom (Gast)]

Hallo,

was für Bus Systeme gibt es die eine Sterntopologie unterstützen?

Es werden auch keine großen BAUD Raten benötigt (Wird nur zur Steuerung 
benötigt).
Leitungslänge maximal 10m/Strang.
1 Master, 100 Slaves

Ich hatte da an sone Art ultra light Ethernet gedacht, eventuell auch 
etwas in Richtung USB.

[Knut B. (Firma: TravelRec.) (travelrec)]

Versuche es mit RS485, das ist recht tolerant. Suche Dir Treiber aus, 
die auch 100 Lasten treiben können bzw. eine sehr geringe Eingangslast 
darstellen. Prinzipiell kannst Du auch eine Art Stromschleife für jeden 
Sternen-Strang bauen, also eine am Ende terminierte Strangleitung. Diese 
kann bei geringer Baudrate sogar nur einpolig gegen Masse sein.

[paule (Gast)]

Was für ein System solls denn überhaupt sein?
Master-Slave, Multimaster oder was???

[Tom (Gast)]

Wie oben schon angedeutet, Master-Slave, nur ein Master.

Könnte es eigentlich Klappen wenn ich mir z.B. einen Hub baue der für 
jeden Strang einen Transreceiver enthält?

Master --| -> Transreceiver -> Slave -> Slave -> Slave
         | -> Transreceiver -> Slave -> Slave -> Slave
         | -> Transreceiver -> Slave -> Slave -> Slave
         | -> Transreceiver -> Slave -> Slave -> Slave

Könnte sowas mit einem CAN oder RS485 Bus klappen?

Wenn ich immer nur mit einem einzelnen Slave Kommuniziere müsste das 
doch klappen, oder?

[paule (Gast)]

Das sollte eigentlich funktionieren, sofern du dei Daten im 
Transreceiver
zwischen pufferst. Is halt nur nicht so besonders schnell, aber wenn 
harte Echtzeit nicht gefordert ist, warum nicht...

[Falk (Gast)]

@ Travel Rec. (travelrec)

>Versuche es mit RS485, das ist recht tolerant. Suche Dir Treiber aus,
>die auch 100 Lasten treiben können bzw. eine sehr geringe Eingangslast

Und nimm die EXTRA LANGSAMEN Treiber (slew rate limited), wie z.B. 
MAX13487E.

Dann brauchst du auch keine Terminierung bei diesen Leitungslängen und 
Baudraten.

MFG
Falk

[Tom (Gast)]

Hmm, direkte Echtzeit ist zwar nicht nötig, aber warum müsste es dann 
gepuffert werden? (welche Transceiver können das eigentlich???)

Ich hatte mir im groben so gedacht:
1. Master Sendet Daten
2. Transceiver sendet die Daten weiter in die einzelnen Stränge
3. Der Slave sendet Daten zum Transceiver seines Strangs
4. Die Daten sind wieder beim Master.
Die Daten des Slaves werden zwar auch in die anderen Stränge übertragen, 
aber das sollte ja kein Problem sein da dort ja alles "verpufft".

Wo ist mein Denkfehler?

[Falk (Gast)]

@ Tom (Gast)

>Hmm, direkte Echtzeit ist zwar nicht nötig, aber warum müsste es dann
>gepuffert werden? (welche Transceiver können das eigentlich???)

Wozu puffern? Das kann man direkt alles an einen Strang anschliessen.

>Die Daten des Slaves werden zwar auch in die anderen Stränge übertragen,
>aber das sollte ja kein Problem sein da dort ja alles "verpufft".

So ein Repeater/Hub ist viel zu aufwändig und hier unnötig.

MFG
Falk

[Knut B. (Firma: TravelRec.) (travelrec)]

Wenn immer nur ein Slave explizit auf die Anfrage des Masters hin 
antwortet, dann muß nichts gepuffert werden. Es sind dann immer nur 
Daten in eine Richtung unterwegs. Der Hub muß allerdings direkt an den 
Master angeschlossen sein, damit dieser die Datenrichtung der einzelnen 
Transceiver umschalten kann (zumindest bei RS485).

[Tom (Gast)]

Habe leider keine RS485 hardwre mehr hier. Ich werde es mal mit einem 
CAN Bus testen, da müsste ich noch Hardware für einige Nodes 
zusammenbekommen :)