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
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?
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
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
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.
mit 1/4-load-Bausteinen bist du bei 128 Teilnehmern, aber das reicht ja auch nicht.
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. (-:
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.