Hi, ich suche für mein Projekt den perfekten Bus -Mehrere Einheiten werden vernetzt (Hauptcontroller, Sensoren, Ausgangsstufen, Motorendstufen, etc.) -Bidirektional -Ein Master, mehrere Slaves (ca. 10-20) -Kurze Entfernungen (max. 3m) eher langsamere Geschwindigkeiten (im kbit/s-Bereich) -Wenn eine Baugruppe ausfällt, dann soll das keinen Einfluss auf die anderen Baugruppen haben (kein Ring mit Durchreichen) -Einheiten werden mittels FPGA/CPLD realisiert. Wenn möglich ohne besondere externe Baugruppen (Bus-Treiber, etc.) -Parallel/Seriell egal. Wenige Leitungen wünschenswert. -Wenn möglich weitgehend immun gegen elektromagnetische Störungen (Motoren in direkter Nähe)
Wie wärs mit Profibus. Der wird in Inustriebebereichen verwendet der eine wirklich schmutzige Umgebung hat. (Elektromagnetisch verschmutzt) Der arbeitet eigentlich ziemlich zuverlässig. Leider benötigst du da eine Signalanpassung. mfg Alex
Ich würde RS485 vorschlagen. Arbeitet mit Stromschleife udn hat damit gute Störfestigkeit. Selbiger wird auch in der Industrie oft verwendet. Vorteile: Einfach (braucht nur 2 Leiter-Bus), direkt mit UART Ausgängen eines Controller ansteuerbar. Buslängen bis mehrere hundert Meter möglich Nachteil: Braucht leider doch nen Treiber IC, aber die sind klein (8pol) und günstig (~1€). Aber du wirst ohnehin um keinen Treiber IC rumkommen, von irgendwelchen Controllen meterlange Leitungen rauszuziehen taugt nix. Schau mal das Datenblatt im Anhang... Stefan
RS485 ist nur der physical layer - wie das Protokoll aussieht, ist dabei offen. D.h. Du darfst Dir dann mal um das Handshaking den Kopf zerbrechen. (Da Master/Slave entfällt wenigstens eine collision detection...) RS485 arbeitet differentiell und nicht über Stromschleife. Deswegen brauchst Du drei Adern: D+, D- und GND. soviel dazu, Stefan ;-) Spricht etwas gegen CAN? Ein paar Details zum Profibus wären ganz interessant... Viele Grüße, Hendrik
RS485 ist keine schlechte Idee. Gerade weil der nur physical layer ist. Mometan hängen die Sensoren im I/O-Space meines 16bit Prozessors. Ich könnte ein Bus-Protokoll definieren, welches die Bitbreite und Adressierung beibehält und so bräuchte ich dann keine großen Anpassungen an die Sensoren machen. Mit der konvertierung Sensordaten - BusX - Sensordaten brauche ich micht dann auch nicht beschäftigen.
@Hendrik: Ups... Ähm, bist du da sicher ?? Differentiell arbeitet die Sache wohl, aber dem Datenblatt entnehme ich dass man nur 2 Adern braucht. Meine Gerätchen hier sind auch nur mit 2 Adern verbunden, und haben keine Masseverbindung (Batteriegespeiste Teile, keine Masse-/Erdverbindung!)...
Das wirkt auf mich ein bischen so, als willst Du das Rad neu erfinden. Busprotokolle macht man normalerweise nur dann mit PLDs, wenn's nichts passendes gibt und ein µC zu langsam ist. Hier riecht es eher nach RS485 oder CAN mit µC statt PLD. CAN erspart dabei manche Software, weil beispielsweise CRC und Retransmissions schon dabei sind. Zur Minimierung gibt's Controller mit CAN (z.B. Atmel AT89C51CC02 in SO24/QFP32 plus Bustreiber SO8).
Das wäre ja fast ein Fall für den SJA1000 als CAN-Controller. Den könnte man als Quasi-Speicherbaustein an den µC legen. Bei den Sensoren könnte man entweder auf einen Controller mit integriertem CAN-Baustein zurückgreifen, oder solche Bausteine wie den MCP2515 verwenden. Wenn man RS485 verwenden will, sollte man bei Master-Slave-Netzwerken vielleicht lieber auf die 4-Draht-Variante ausweichen: Der Master sendet auf 2 Leitungen, die mit den Eingängen sämtlicher Slaves verbunden werden. Die Slaves wiederum senden alle auf den gleichen zwei Leitungen, die in den Empfänger des Masters gehen. Das Protokoll, sollte dann nicht nur aus das Adresse bestehen, sondern noch ein paar Daten mehr enthalten.
Mich würde in dem Zusammenhang interessieren, wie man nicht nur gegen Störungen möglichst unanfällig ist, sondern auch selbst möglichst wenig stört (mit dünnen Kabeln, also keine dreifach abgeschirmten CAT-6-Prügel bitte). Ich schätze mal, daß hier auch differnziell mit verdrillten Adrenpaaren ein guter Ansatz ist? Transferrate wären auch ein paar kBit.
@Hendrik: >>RS485 arbeitet differentiell und nicht über Stromschleife. Deswegen >>brauchst Du drei Adern: D+, D- und GND. Da liegst du falsch ! Wie Stefan Seegel schon vermutet hat: Tatsächlich werden nur zwei Adern verwendet. Ich kann RS485 nur empfehlen. Ich weiß nicht warum Ihr Euch immer Gedanken macht zum Thema Busprotokoll und Kollisionserkennung ? Dass man sich für seine eigenen Zwecke auch ein eigenes Protokoll erstellt, ist doch wohl nicht die Welt. Es muß ja nicht das komplizierteste Protokoll sein. Es kann sich ja auch entwickeln (Man muß ja nicht sofort eine komplexe CRC-Berechnung implementieren !) Noch was zur Kollisionserkennung: Beim RS485 ist dabei ein simpler SW-Vergleich in der ISR notwendig: "Ist das Byte, was ich gesendet habe, auch so (in der ISR des gleichen Controllers) angekommen ? Wenn nicht: Kollision, also Botschaft nochmal senden. Wer in der Lage ist, eine Kommunikation zu erstellen, der sollte auch einen solchen Vergleich noch hinkriegen ! Gruß Detlef
@Detlef: Ne, Du brauchst bei RS485 die Masse. Zwar funktionieren viele Transceiver auch mit nur 2 Leitungen, das ist aber mehr Zufall als nach Spezifikation.
@Hendrik Es geht um die Verbindung zwischen Teilnehmern im RS485 - Netwerk Definitiv reicht bei einem RS485-Netzwerk eine 2-Adrige Verbindung zwischen den Teilnehmern.l Ich habe mich intensiv mit dem Thema befaßt, aber noch nie habe ich eine Spezifikation oder einen Treiber gesehen, die für ein RS485-Verbindung eine 3-Adrige Leitung verwendet. Falls es soetwas gibt, ist es garantiert kein RS485 ! Detlef
Ihr habt beide recht. Die RS485 Norm sieht 3 Adern vor, wobei GND zum Potentialausgleich der Teilnehmer dient (anonsten bei grösseren Entfernungen Zerstörung des RS485 Treibers). In der SPS-Technik (z.B. Siemens Simatic) bzw. beim Profibus(kabel) werden nur die 2 Kommunikationsadern(A+B) genutzt. Dabei ist dann allerdings ab 50m ein Repeater vorgeschrieben, welcher die segmente galvanisch trennt. Maxim bietet auch isolierte RS485 Treiber an (kenne aber keinen Distributor).
@ Detlef,
>Falls es soetwas gibt, ist es garantiert kein RS485
Nicht so voreilig, schau dir mal das in der Lichttechnik weit
verbreitete Protokoll DMX an. Da wird der Schirm mitgeführt und über
120 Ohm an Schaltungsmasse angebunden (nach neuester DMX 2000 Norm).
MW
@Hendrik
Profibus wird z.B bei SPS-Steuerungen für die I/O Baugruppen
(Profibus-DP) oder früher auch zum Datenaustausch zwischen SPS('en)
und HMI benutzt(Profibus-FMS).
Layer1 ist mit RS485 bis 12Mbaud realisiert.
Datenübertragung mit 8 Datebis + Parität.
Profibus kann auch Datenraten von 9600/19200. Damit kann ein uC auch
als Master relativ einfach Profibus-Slaves bedienen.
@Dam
Die Reichweite ohne Repeater hängt von der Datenrate ab. Bei 12Mbit
kommt das mit 50m hin, ich habe allerdings auch schon Leitungen von
einigen hundert Metern ohne Repeater gesehen (Baudrate wies ich leider
nicht).
Bernd
Moin, da ich an einem ähnlichen Projekt arbeite, einige Hinweise, über ein System das bereits realisiert wurde (Frequenzregler mit Vernetzung der einzelnen Regler, Master/Slave über RS485 mit regelmäßigem Masterwechsel der gleichwertigen Controller) und wovon einige tausend Einheiten verkauft wurden. Schnittstelle: RS485 mit 2 Kabeln, max. 100m (safety spec.), zusätzlich Masse.# Protokoll: - Max. vier Geräte (wäre erweiterbar) - Regelmäßiges Polling aller Geräte durch den Master mit Timeout für den Ausfall des Masters (nach max. 1 sec übernimmt ein anderer Controller - Polling mit 8 Byte (Startbyte - immer gleich, Adressbyte Quell- + Zieladresse in einem Byte, Controlbyte - Befehl zum Lesen, schreiben etc., Indexbyte - Info, was verändert werden soll - Datenbyte high, Datenbyte low, CRC-Spalte, CRC-Zeile - Die Antwort muß im gleiche Format innerhalb 6-30ms erfolgen, sonst gibt es einen Timeout Wen es interessiert: Es gibt eine umfangreiche Spec. (ca. 25 Seiten, PDF), die auf Anfrage gerne zuschicke - Mail an o.a. Adresse Grüße, der Wirus! P.S.: Realisiert ist das ganze mit Motorola MC68HCT.... abonniert (war der eigentliche Grund für das Gesülze)
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.