Auswahl Bussystem

Harald Gast #221865
Lesenswert?
• ▲
▼ 
Hallo,

ich bin hier gerade mit der Auswahl eines Bussystems befasst, und werde
mir nicht so recht klar darüber, welches in Frage kommt.
Es solle eine große Anzahl identischer Geräte gesteuert werden; in
jedem Gerät sollen mehrere binäre Einstellungen (insgesamt ca. 10 pro
Gerät) von einem PC aus vorgenommen werden können.
Die Geräte selbst werden von einem Controllerbaustein gestuert;dieser
widerum ist via TCP/IP an einen PC angeschlossen und wird über HTTP
gesteuert (Plattformunabhängigkeit und Hardwareunabhängigkeit).
Problem ist nun ein Bussystem auszuwählen, das den Controllerbaustein
mit den Geräten verbindet. I^2 kommt nicht in Frage, weil nur
3-bit-Adressierbar. Profibus fällt aus wegen zu Schwergewichtig und zu
teuer. Bleibt noch der CAN-Bus. Bei dem ist mir aber die
Nachrichtenorientierung nicht so ganz geheuer... ...das Konzept sieht
für mich nach etwas aus, das erfunden wurde, um viele in ihrer Funktion
unterschiedliche Busteilnehmer zu verbinden. Ich müsste ja für meinen
Zweck pro zu steuerndem Gerät eine neue Nachricht erfinden, oder?

Konkrete Frage jetzt: Ist CAN für diese Anwendung brauchbar, und, falls
nicht, was kommt sonst noch in Frage?

Gruß,
Harald
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Rufus Τ. F. Persönliche Seite #221867
Lesenswert?
• ▲
▼ 
Für eine genaue Betrachtung fehlen noch ein paar Informationen:

- Anzahl der anzusteuernden Geräte
- Entfernung dieser voneinander/vom Steuergerät
- erforderliche Geschwindigkeit (wie oft pro Zeiteinheit müssen die
genannten "binären Einstellungen" für ein Gerät geändert werden)
- Art der zu übertragenden Information: nur vom Steuergerät zu den
angeschlossenen Geräten, oder auch retour? Reaktion des Steuergerätes
auf Ereignisse an den angeschlossenen Geräten gewünscht? Welche
Reaktionszeit ist zulässig?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Harald Gast #221868
Lesenswert?
• ▲
▼ 
Hallo Rufus,

danke für Deine Antwort.

> - Anzahl der anzusteuernden Geräte

Bis ca. 200, vielleicht auch mehr.

> - Entfernung dieser voneinander/vom Steuergerät

Die werden wohl meistens einen bis mehrere Rittal-Schränke füllen,
Entfernungen sind also nut mittelkritisch (Es sind
19"-Kasseteneinschübe, 8 Kassetten pro Rack). Das kann aber auch mal
anders aussehen, daher sollte das Bussystem mindestens zehn Meter
Abstand vertragen.

> - erforderliche Geschwindigkeit (wie oft pro Zeiteinheit müssen die
> genannten "binären Einstellungen" für ein Gerät geändert werden)

Ein paar mal am Tag, höchstens.

> - Art der zu übertragenden Information: nur vom Steuergerät zu den
> angeschlossenen Geräten, oder auch retour?

Beide Richtungen. Es müssen ja nach dem Systemstart irgendwie die
Ist-Werte ausgelesen und zum PC übertragen werden.

> Reaktion des
> Steuergerätes auf Ereignisse an den angeschlossenen Geräten
> gewünscht?

Nein.

Gruß,
Harald
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Mathias Gast #221870
Lesenswert?
• ▲
▼ 
Hallo Harald,

das mit den 200 teilnehmern ist bei rs485 ein problem, da max. 32
geräte an einen rs485 bus angeschlossen werden können!!

geschw. und entf. stellen jedoch überhaupt keine probleme dar.

mfg, Mathias
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Robby Gast #221871
Lesenswert?
• ▲
▼ 
Ich schmeiß einfach mal was in die Runde. Schätze zwar, dass das für
diesen Fall etwas überdimensioniert ist, aber schon mal über Ethernet
nachgedacht? Hätte den Vorteil, dass die Infrastruktur (Hubs,
Switsches, Kabel usw. recht günstig zu kriegen sind und das System
nahezu unbegrenzt erweiterbar bleibt. Ich selbst hab keine Erfahrung
mit uCs, die das können, aber möglich ist es bestimmt.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Philipp S. #221873
Lesenswert?
• ▲
▼ 
Hardwaremäßig RS-485, eigenes Primitivprotokoll: da es eine
Einwegkommunikation ist, gibt es keine Kollisionen, womit das größte
Problem schon erledigt ist.
Jetzt werden immer drei Zeichen geschickt:

1. neuntes Bit an: Gerätenummer senden
2. neuntes Bit aus: erstes Datenbyte an das Gerät
3. neuntes Bit aus: zweites Datenbyte an das Gerät

Reicht also für 256 Geräte mit jeweils bis zu 16 Digitalfunktionen. Und
ist innerhalb von einer halben Stunde programmiert. (-:
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Rufus Τ. F. Persönliche Seite #221874
Lesenswert?
• ▲
▼ 
rs485 kann auch mit mehr als 32 Teilnehmern betrieben werden, sofern man
keine abstrusen Vorstellungen in Bezug auf die verwendete
Datenübertragungsrate hat.

Bei ausreichend niedrigen Baudraten (9600 Baud) sind -erprobt- an die
100 Teilnehmer realisierbar, und das bei Buslängen von bis zu 1 km.

Bei den von Harald geschilderten Anforderungen scheint mir 9600 Baud
ausreichend zu sein.

Um das Protokoll einfach zu halten, sollte ein
Single-Master-Multiple-Slave-Verfahren implementiert werden; der Master
adressiert die anzusteuernden Slaves und gibt ihnen eine festgelegte
Zeit für eine Antwort, in der sie den Bus belegen dürfen.
Sofern spontane Ereignisse von Slaves auszuwerten sind, ist ein
zyklisches Pollen aller Slaves mit Verwendung eines Änderungsflags und
entsprechend kurzen Datenpaketen für "nichts passiert"
durchzuführen.

Mit so einem Verfahren lassen sich bei 9600 Baud etwa 100 Teilnehmer im
Bereich von einer Sekunde abfragen.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren