[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DDL-ML] Re: [DDL-ML] rufo, loconet, rückmeldebus, bushardware, ddl-treffen

Andy schrieb:

> Von RS485 hat schon mal ein Berufener (weiß nicht mehr wer) abgeraten.
> Dieser TriState-Kram funktioniert nur bei wenigen Teilnehmern; da ist > ein Open Collector-Bussystem, welches darauf eingerichtet ist daß alle
> gleichzeitig quatschen, besser geeignet.

Meines Wissens nach ist *gerade* bei Open-Collector-Bussen die mangelnde Störsicherheit ein nicht zu unterschätzender Nachteil, auch wenn es sich vom Protokoll-Handling und Hardware her einfacher zu handeln ist. RS485 ist aufgrund seiner symmetrischen Leitungen nicht nur extrem störsicher, sondern auch noch schnell. In Industrieanwendungen wird mit RS485-Hardware Datenübertragung bis in den MBit-Bereich und mit -zig Teilnehmern betrieben. (z.B. Profibus). Das sollte wohl genügen.

Allerdings habe ich noch nie von Open-Collector-Bussen in industrieller Steuerungstechnik gehört, deren Länge mehr als wenige -zig cm beträgt.
Wohin einfache unsymmetrische Signale (möglichst noch TTL-Pegel) führen, kann man ja an S88 sehen. Mir ist ein Fall bekannt, wo die S88-Leitungen nicht näher als 1 m an die Digialstrom-Leitungen liegen dürfen, um Störungen durch Übersprechen zu vermeiden.

> SNAP umfaßt nur das Kommunikationsprotokoll, die physikalische Schicht > ist ausgenommen. Und genau da liegt ein wichtiger Faktor in der
> Zuverlässigkeit

Deshalb habe ich ja als Layer1 RS485-Halbduplex vorgeschlagen.

> LocoNet benutzt quasi CSMA/CD, damit sind 100 Datenpakete/s durchaus
> realistisch handhabbar.

CSMA/CD kann ich bei jeder Bus-Datenübertragung einsetzen (egal ob Loconet oder SNAP), im einfachsten Fall durch gleichzeitiges Rücklesen der gesendete Informationen (bei SNAP: SYNC-Pakete). Sind diese verstümmelt, so ist eine Kollision vorhanden.

Ich glaube mich auch erinnern zu können, das für CSMA-CD bei 50% der physikalisch möglichen Bandbreite die maximale Übertragungskapazität erreicht ist.

> drauf ankommen lassen, und der gegenüber Loconet höhere
> Protokolloverhead (ca. 100 %) und geringere Geschwindigkeit lassen
> sich verschmerzen.

Ich meine, es müsste erst einmal geklärt werden, welche Reaktionszeiten für Rückmeldesignale notwendig und sinnvoll sind. Ich gehe nicht davon aus, daß alle Rückmeldesignale unbedingt innerhalb von 10-100ms übertragen werden müssen. Das Latchen der Signale sollte der Controller vor Ort übernehmen.

Eine Studie über das auftretende Datenvolumen, notwendige Reaktionszeiten und Gleichzeitigkeitsfaktoren würden mich sehr interessieren. Hat dazu jemand schon Erfahrungen gesammelt?

Das Thema Protokoll-Overhead ist immer im Zusammenhang mit der möglichen Paketgröße zu sehen. Und die kann ich bei SNAP ja in weiten Bereichen einstellen.

> Nicht zuletzt fehlt es SNAP an einem
> Arbitrierungsalgorithmus für das Medium. Das Protokoll ist eben ..

Wenn auf eine Arbitrierung ohne Informationsverlust besonderer Wert gelegt wird, dann wäre wahrscheinlich ein Prinzip wie CAN, wo sich die höher priorisierte Adresse durchsetzt, die bessere Alternative. Da wird aber wieder der Kostenfaktor eine Rolle spielen, CAN-Microcontroller sind nicht gerade billig. Die Alternative wäre Software-Emulation. Ausserdem, wer legt dann die Prioritäten fest?

> SNAP mag durchaus für den Zweck als Layer2-Protokoll funktionstüchtig
> sein, glänzt aber offensichtlich mit kompletter Abwesenheit jeglicher
> Vorarbeit (Treiber, Geräte, bahnspezifische Spezifikationen). Da hat
> Loconet einen erheblichen Vorsprung.

Treiber sind für Linux und Windows vorhanden.

Ausserdem, war da bei Loconet nicht irgendwas mit Lizenz-Fragen, die eine freie Verwendung untersagten bzw. die eigene Entwicklung stark einschränken ?

Zitat Homepage Digitrax:

"Is LocoNet Proprietary?
Yes, in the strictest sense of the word LocoNet is a proprietary system. In order to maintain a system as complex as LocoNet someone has to be "in charge" so that valuable system resources are not used unwisely. Digitrax maintains LocoNet professionally for the benefit of the hobby & works with other competent DCC developers so that they can include it in their systems. The non-disclosure agreements & licensing agreements & fees for the use of LocoNet are not intended to prevent or discourage anyone from using LocoNet but merely to insure that system resources are used prudently & to cover Digitrax cost to maintain and expand the LocoNet as needed."

Das sagt eigentlich alles dazu aus. Abhängigkeit von nur einer Firma die bestimmt, wo es lang geht und wieviel ich wissen darf ist nicht mein Fall.

Allerdings wurde auch von einem zeitkritischen Verhalten bei Loconet gesprochen. Wie sieht es denn mit der zusätzlichen Belastung de Rechners aus?

Fazit: Viele Fragen sind noch offen, jedoch würde ich vorsichtig mit pauschalen Urteilen wie "nicht zu gebrauchen" sein. Sicherlich ist die Entwicklung eines eigenen Protokolls mit mehr Arbeit verbunden, aber ich denke, es lohnt sich am Ende.


Gruss Torsten