Hallo zusammen, es geht um eine Kundenentwicklung, die mich etwas Nerven kostet, bzw. ich noch keinen so richtigen Ansatz finde. Zentrale Anwendung: Es gibt, in einer Gesamtlänge von ca 2000m insgesamt 30 kleine Steuerungen (Herzstück ist ein STM32 Cortex M3). Die Leitungslänge von Teilnehmer zu Teilnehmer beträgt maximal 100 Meter. Diese kleinen Steuerungen haben 4 digitale Ausgänge um bestimmte Sachen schalten zu können. Daneben besitzen sie ein RFID Terminal, in dem ein RFID Chip (nur lesend) behandelt werden kann. Am Ende des Busses sitzt eine WAGO PFC200 Industriesteuerung. Was soll das Ganze: Ziel ist es, dass die WAGO als zentraler Server genutzt wird, in dem jeder RFID Chipnummer bestimmte Berechtigungen zugeordnet werden können. Geht der Besitzer des Chips mit seinem RFID an eins der 30 RFID Lesestationen, soll diese die Nummer auslesen, über Bus an die WAGO weiterleiten, die WAGO prüft dann die Zentralen Berechtigungen und gibt wiederum über BUS den zentralen Schaltbefehl für Ausgang 1,2,3 oder 4 an der Lesestation. RFID einlesen klappt durch vorherige Problematik die ich momentan habe ist die Busverbindung. 2 Ideen hatte ich bisher: 1 RS485 Netz mit 30 Teilnehmern. Gut und schön, aber bei 2000m Leitungslänge sollte das selbst bei 9600kBit/s eher NICHT laufen. ODER.... die Steuerungen so aufbauen, dass es immer ZWEI ein RS485 Netzte gibt (UART1 und UART2 des µC nutzen und 2 RS485 Wandlerbausteine nebst galvanischer Trennung einplanen. Dann könnte der letzte im Bunde seine Informationen an den Vorletzten schicken, der packt seine Informationen hinzu und sendet beide Infors an den Vorvorletzten usw. usw. Vorteil: Ab jedem Teilnehmer beginnen die 1200m theoretisch nutzbare Länge von neuem, mit meinen zu erwartenden 100m bin ich somit Safe. Nachteil: Bis ich mich durch 30 Controller gearbeitet habe und die WAGO dann wieder über 30 Controller zum letzten Teilnehmer zurück melden muss vergehen schätzungsweise 10-15 Sekunden --> nicht akzeptabel. So und nun bin ich mit meinem Latein am Ende. Hat irgendjemand ne Idee, wie ich die 30 Teilnehmer mit den vorgegebenen Leitungslängen schnell, einfach und Effektiv miteinander Kommunizieren lasse?
Hallo Hanna, warum soll die Weitergabe 10-15 Sekunden dauern? Das Signal muss doch nicht von jedem Controller interpretiert werden. Im Empfangsfall wird das empfangene Signal (RX) direkt über den zweiten Transceiver weiter gegeben. Im Sendenfall sendest du dein Telegram in beide Richtungen um Verdrahtungsfehler zu vermeiden. Wenn von einem im Bus später angeordnetem Slave Daten versendet werden gibst du diese von Transceiver 2 auf Transceiver 1. Vereinfacht kann man direkt RX und TX der beiden Transceiver kreuzen und im Sendefall diese Verbindung auftrennen und die RX und TX LEitung des Controllers an beide Transceiver anbinden. Beste Grüße Philipp
Hanna schrieb: > 1 RS485 Netz mit 30 Teilnehmern. Gut und schön, aber bei 2000m > Leitungslänge sollte das selbst bei 9600kBit/s eher NICHT laufen. Unsinn, das läuft schon, wenn man keinen Murks baut. > die Steuerungen so aufbauen, dass es immer ZWEI ein RS485 Netzte gibt > (UART1 und UART2 des µC nutzen und 2 RS485 Wandlerbausteine nebst > galvanischer Trennung einplanen. Dann könnte der letzte im Bunde seine > Informationen an den Vorletzten schicken, der packt seine Informationen > hinzu und sendet beide Infors an den Vorvorletzten usw. usw. Noch mehr Unsinn und Fehlerquellen. > Vorteil: Ab jedem Teilnehmer beginnen die 1200m theoretisch nutzbare > Länge von neuem, mit meinen zu erwartenden 100m bin ich somit Safe. Da scheint ein neues Modewort zu sein "safe sein", wahlweise auch "save sein". OMG! > Nachteil: Bis ich mich durch 30 Controller gearbeitet habe und die WAGO > dann wieder über 30 Controller zum letzten Teilnehmer zurück melden muss > vergehen schätzungsweise 10-15 Sekunden --> nicht akzeptabel. Blödsinn^3. Dann wären deine Knoten in Relaistechnik aufgebaut. > So und nun bin ich mit meinem Latein am Ende. Bis ja nicht wirklich weit gekommen. Barba non facti philosophum. Ein 2km RS485 Bus mit 9600 Baud ist machbar, ohne Tricks. Selbst wenn man da Bedenken sieht, kann man ja in der Mitte einen Repeater einbauen. Aber man braucht man sicher NICHT alle 100m in jedem Knoten einen! Außerdem kann man im Fall der Fälle auch auf 4800 oder gar 1200 Baud runter. Für die paar Bytes für die ID der RFIDs reicht das allemal. 1200Baud sind auch 120 Bytes/s.
Phil schrieb: > Vereinfacht kann man direkt RX und TX der beiden Transceiver kreuzen und > im Sendefall diese Verbindung auftrennen und die RX und TX LEitung des > Controllers an beide Transceiver anbinden. Hm, da braucht es sowas, das die Post früher mal Gabelschaltung nannte. Macht es doch ein wenig komplizierter. 15 Sekunden klingt echt viel. Das wären 250 ms zum Weiterleiten eines Päckchens. Du kannst ja durch die kurzen Abstände die Baudrate erhöhen. Eventuell musst Du einen Hybrid zwischen Deinen beiden Konzepten verwirklichen. Sprich es gibt Kleinsteuerungen und Router. Von den Routern werden nur so viele eingesetzt, dass die Anforderungen an Teilnehmerzahl und Länge pro Bussegment gerade so erfüllt werden. Dadurch geht eine Botschaft über weniger Zwischenstationen.
> 1 RS485 Netz mit 30 Teilnehmern. Gut und schön, aber bei 2000m > Leitungslänge sollte das selbst bei 9600kBit/s eher NICHT laufen. Ich halte die Leitungslaenge an sich fuer kein Problem. Allerdings hat man sich bei solchen langen Leitungen hoffentlich Gedanken ueber moegliche Potentialunterschiede gemacht. .-) Olad
Hallo, weist du FALK, solche Antworten wir deine sind mal wieder prädestiniert dafür, dass eine Diskussion ins Unsachliche abschweift UND, dass sich keiner mehr traut hier im Forum was zu posten. Ist ja ganz toll, dass du ne Word Datei mit lateinischen Sprichwörtern auf deinem PC hast und auch wirklich Klasse, dass alles für dich ein Klacks ist und nominelle Vorgaben für dich nicht gelten (RS485 max. 1200m bei 9600) aber jedwede Nutzinformation aus deinem Post konnte ich auch bei mehrmaligem Durchlesen nicht entnehmen. Zurück zum Thema: Phil schrieb: > Im Empfangsfall wird das empfangene Signal (RX) direkt über den zweiten > Transceiver weiter gegeben. > > Im Sendenfall sendest du dein Telegram in beide Richtungen um > Verdrahtungsfehler zu vermeiden. Das hört sich sehr interessant an, en Detail verstehe ich es aber noch nicht so ganz. Bedeutet, ich habe 2 RS485 Treiber auf meiner Schaltung, die die Daten im Regelfall nur 1:1 durchschleifen (und das dann in Echtzeit). Wenn die jeweilige Schaltung dass aber senden soll, wie würde das physikalisch aussehen?
Hanna schrieb: > und nominelle Vorgaben für dich nicht gelten (RS485 max. 1200m bei > 9600) Woher kommt diese "nominelle Vorgabe"? Bei 9600 Baud sind deutlich mehr als 1200m möglich, zuverlässig und stabil, und auch bei mehr als 30 Teilnehmern. Wenn man die RS485-Treiber sauber aufbaut (galvanische Trennung, Versorgung über DC-DC-Wandler), muss man sich auch über Potentialunterschiede und -Ausgleichsströme nicht allzuviele Gedanken machen.
Hanna schrieb: > weist du FALK, solche Antworten wir deine sind mal wieder prädestiniert > dafür, dass eine Diskussion ins Unsachliche abschweift UND, dass sich > keiner mehr traut hier im Forum was zu posten. Ich bin zwar nicht Falk, aber Du solltest seinen Beitrag ruhig nochmal mit abgekühltem Gemüt lesen. Was er da sagt, hat Hand und Fuß. Natürlich sollte man den Bus als Bus belassen, statt die Päckchen von einer Relais-Station zur nächsten zu senden. Wie Falk schon sagte: Das verkompliziert eher alles und macht das Ganze fehleranfällig. Mich wundert allein, dass Du hier die benötigte relativ hohe Latenzzeit akzeptierst aber eine niedrigere Baudrate für Dich inakzeptabel ist. Das passt nicht zusammen. > und nominelle Vorgaben für dich nicht gelten (RS485 max. > 1200m bei 9600) Lies seinen Beitrag genauer. Falk schrieb: notfalls ein Repeater Damit sind 2000m natürlich realisierbar. Davon abgesehen: In welcher "Norm" steht das mit den 1200 Metern? Meines Wissens nach sind das lediglich Erfahrungswerte. Probiers doch einfach mal aus.
:
Bearbeitet durch Moderator
> Bei 9600 Baud sind deutlich mehr als 1200m möglich, zuverlässig und > stabil, und auch bei mehr als 30 Teilnehmern. Man sollte sich auch darueber im klaren sein das es bei solchen Leitungslaengen auch stark von der Kabelqualitaet abhaengt. Olaf
Hallo nochmal, das heißt zusammenfassend: Ich kann das Netzwerk aufbauen wie hier unter 3.2 dargestellt? http://www.alciro.org/alciro/RS-485_16/topologia-conexiones-RS-485_329_de.htm Dann kann senden und Empfangen als FULLDUPLEX realisiert werden? Der Master sendet zyklisch, z.B. alle 100ms an die Slaves, diese "picken" sich dann die entsprechenden Nutzinformationen für sich raus Der jeweilige Slave sendet nur, wenn er vom Master aufgefordert wird? Oder gäbe es eine Möglichkeit, dass jeder Slave zu jeder Zeit senden kann wenn er will und die anderen Teilnehmer "einfach" nur hören ob der Bus frei ist bis sie senden? Was ist da gängige Praxis? Bzw. wie sieht sowas in der Praxis aus?
Hanna schrieb: > Ich kann das Netzwerk aufbauen wie hier unter 3.2 dargestellt? > > http://www.alciro.org/alciro/RS-485_16/topologia-conexiones-RS-485_329_de.htm Ja. Aber wozu full duplex? Dein Bus ist sowieso langsam, da reicht halbduplex. > Der Master sendet zyklisch, z.B. alle 100ms an die Slaves, diese > "picken" sich dann die entsprechenden Nutzinformationen für sich raus Kann man machen. > Der jeweilige Slave sendet nur, wenn er vom Master aufgefordert wird? Kann man machen. > Oder gäbe es eine Möglichkeit, dass jeder Slave zu jeder Zeit senden > kann wenn er will und die anderen Teilnehmer "einfach" nur hören ob der > Bus frei ist bis sie senden? Kann man machen, ist aber mehr Aufwand, vor allem für die Kollisionserkennung bzw. Vermeidung. CAN macht das schon selber, da muss man sich nicht drum kümmern.
Hanna schrieb: > Der Master sendet zyklisch, z.B. alle 100ms an die Slaves, diese > "picken" sich dann die entsprechenden Nutzinformationen für sich raus Genau, dazu gibst Du jedem Slave eine eindeutige Adresse. Vereinfachtes Kommunikations-Beispiel (ohne CRC): Der Slave Nt. 22 soll das Licht anmachen:
1 | $22On<CR><LF> |
Der Slave antwortet: "Das Licht ist nun an".
1 | !22On<CR><LF> |
Anderes Beispiel: Der Slave 31 soll den zuletzt eingelesenen RFID-Code ausspucken.
1 | $31RFID<CR><LF> |
Der Slave antwortet:
1 | !31RFID<CR><LF> // hat keinen gelesen |
oder:
1 | !31RFID1234567890<CR><LF> // gibt RFID aus |
und löscht danach den zuletzt eingelesenen RFID-Code imn internen Speicher. > > Der jeweilige Slave sendet nur, wenn er vom Master aufgefordert wird? Korrekt. Am besten gibt der Slave für jede(!) Anfrage auch eine Antwort aus. Das vereinfacht eine evtl. verwendete Statemachine sowohl auf dem Master als auf den Slaves.
:
Bearbeitet durch Moderator
Das mit dem RS485 ist generell nicht allzu beliebt in der Industrie, vor allem bei vielen Teilnehmern. Hat ein Ausgagstreiber einen Schaden, steht das ganze Netz still. Die Suche nach dem defekten Gerät ist dann oft zeitaufwändig. Ethernet wäre eine gute Alternative. Es gibt auch RS485 auf Ethernet-Umsetzter. Wäre vieleich darüber nachzudenken... Grüsse
Gebhard R. schrieb: > Ethernet wäre eine gute Alternative Passt nicht so ganz einfach zu den geforderten 2000 Metern.
Hanna schrieb: > Dann kann senden und Empfangen als FULLDUPLEX realisiert werden? Nein. Aber das, was Du beschreibst, ist auch kein Vollduplex, sondern Halbduplex. Vollduplex bedeutet gleichzeitiges Senden und Empfangen. Das geht nur auf Punkt-zu-Punkt-Verbindungen, nicht aber auf einem Bus, und schon gar nicht bei RS485, dessen Treiberbausteine eigens eine Sender-/Empfänger-Umschaltung haben. > Der jeweilige Slave sendet nur, wenn er vom Master aufgefordert wird? So wird es üblicherweise gehandhabt. > Oder gäbe es eine Möglichkeit, dass jeder Slave zu jeder Zeit senden > kann wenn er will und die anderen Teilnehmer "einfach" nur hören ob der > Bus frei ist bis sie senden? Umständlich, weil Bus-frei-Erkennung nötig, und weil Kollisionsdetektion nötig (denn es können ja auch mehrere Slaves gleichzeitig senden, weil alle gleichermaßen den Bus für "frei" gehalten haben).
Rufus Τ. F. schrieb: >> und nominelle Vorgaben für dich nicht gelten (RS485 max. 1200m bei >> 9600) > > Woher kommt diese "nominelle Vorgabe"? Z.B. von hier: ANSI/TIA/EIA-422-B-1994 Annex A (informative), Seite 20ff ----> The curve of cable length versus data signaling rate given in figure A.1 may be used as a conservative guide. This curve is based upon empirical data using a 24 AWG, copper conductor, unshielded twisted-pair telephone cable with a shunt capacitance of 52.5 pF/meter (16 pF/foot) terminated in a 100 Ohm resistive load. The cable length restriction shown by the curve is based upon assumed load signal quality requirements of: a. Signal rise and fall times equal to or less than, one-half unit interval at the applicable data switching rate. b. A maximum voltage loss between generator and load of 66% At the higher data signaling rates (90 kbit/s to 1 0 Mbit/s), the sloping portion of thefcurve shows the cable length limitation established by the assumed signal rise and fall time requirements. As the data signaling rate is reduced below 90 kbit/s, the cable length has been limited at 1200 meters (4000 feet) by the assumed maximum allowable 66% signal loss. <---- Da kommen die 1200m her, die sich überall finden. Mit besserem Kabel mit weniger Dämpfung kommt man weiter. Wie weit, das muss man ausmessen. Dabei spielen dafürlich auch die eingesetzten Transceiver eine Rolle. fchk
Rufus Τ. F. schrieb: > Vollduplex bedeutet gleichzeitiges Senden und Empfangen. Das geht nur > auf Punkt-zu-Punkt-Verbindungen, nicht aber auf einem Bus, und schon gar > nicht bei RS485, dessen Treiberbausteine eigens eine > Sender-/Empfänger-Umschaltung haben. Stimmt nicht, es gibt vollduplex RS485 Tranceiver, MAX488 & Co.
Geht es denn um ein bestehendes System? Könnte man auch einen CAN-Bus nehmen? Der soll bei 10kbit/s auch 6,7km können. https://www.me-systeme.de/de/technik-zuerst/elektronik/can-bus-grundlagen
Hallo Zusammen, vielen Dank für die mittlerweile doch sehr nützlichen Beiträge. Eine Frage hätte ich aber noch: Wenn ich 32 Teilnehmer von meiner Mastersteuerung aus zyklisch abfragen muss, dann muss ich ja zuerst eine Antwortanforderung senden, so wie Frank das eben sehr gut dargestellt hat, dann muss ich auf eine Antwort warten. Ist die Antwort vollständig da, dann kann ich mit den nächsten Slave fortfahren. Wenn ich nur 100ms für eine Taktung (Senden, auf Antwort warten, Antwort empfangen) rechne, dann komme ich auf 3,2 Sekunden um alle Slaves durch zu tingeln. Das kommt mir doch sehr lange vor. Wo liegt mein Denkfehler
Da gibt's keinen Denkfehler. Man kann von der Baudrate her die 100ms sicher auf 10ms reduzieren, aber wie schnell ist die Wago? Und 0.32s sind immer noch lange, wenn der Benutzer eine Reaktion erwartet. In der Hinsicht kann dein Plan mit der "Reihenschaltung" schneller sein.
Hanna schrieb: > enn ich nur 100ms für eine Taktung (Senden, auf Antwort warten, Antwort > empfangen) rechne, dann komme ich auf 3,2 Sekunden um alle Slaves durch > zu tingeln. Das kommt mir doch sehr lange vor. Wo liegt mein Denkfehler Schon mal überlegt, wieviele Zeichen man bei 9600 Baud in 100ms senden kann? Ob man die alle braucht, um eine einfache Nachricht für "Hallo, was gibt's Nr 11?" und "Nix, alles ruhig, mein Meister" zu übertragen?
Für RS485 würde ich mal einen Blick auf das Modbusprotokoll werfen. Das ist für Single-Master ausgelegt und übernimmt auch die Sicherung der Datenintegrität mittels CRC. Die Spec ist offen und absolut industrietauglich mit Millionen von Geräten, die täglich im Feld zuverlässig ihren Dienst verrichten. CAN wäre natürlich auch eine Idee. Da geht dann auch Multimaster und Kollisionserkennung sowie CRC-Sicherung sind schon im Protokoll "eingebaut" (auf Hardware-Ebene).
Falk B. schrieb: > Stimmt nicht, es gibt vollduplex RS485 Tranceiver, MAX488 & Co. Dsa nennt man dann RS422, und funktionieren tut es nur im Punkt-zu-Punkt-Betrieb mit nicht mehr als einem Sender pro Aderpaar. Vollduplex auf einem Adernpaar ist aber auch im Punkt-zu-Punkt-Betrieb nicht drin.
Man kann RS485 im 2 Leiterpaar System als RS422 laufen lassen, und hat so eine bidirektionale kommunikation. Ein Master Slave system mit 30 Stationen ist machbar. Treiber wie der SN65HVD24D ist fuer 3MBit auf 500m spezifiziert. Ich denke bei einem hochwertigen Kabel ist mehr Laenge bei weniger Geschwindigkeit drin. Eine Frage der Eingangsschwellen, und der Signalqualitaet.
Christopher J. schrieb: > CAN wäre natürlich auch eine Idee. Da geht dann auch Multimaster und > Kollisionserkennung sowie CRC-Sicherung sind schon im Protokoll > "eingebaut" (auf Hardware-Ebene). Genau dieses. Die WAGO PFC200 gibt es auch mit integriertem CAN-Interface => Ich würde definitiv auf CAN statt EIA-485 gehen, alleine schon wegen des angesprochenen Delays durch das permanente Polling aller Slaves. Stattdessen sendet jeder Slave eine Message, wenn ein RFID-Tag erkannt wurde, sowie eine "Alive"-Message alle paar Sekunden, um zu signalisieren, dass er noch online ist. Spannender wird die Frage nach der Spannungsversorgung aller Busteilnehmer.
fchk schrieb: > As the data signaling rate is reduced below 90 kbit/s, the cable length > has been limited at 1200 meters (4000 feet) by the assumed maximum > allowable 66% signal loss. Nun passt zwischen "below 90 kbit/s" und 9600 Baud noch 'ne ganze Menge.
Toni Tester schrieb: > Spannender wird die Frage nach der Spannungsversorgung aller > Busteilnehmer. Dezentral und Schnittstelle galvanisch trennen?
Falk B. schrieb: > ist aber mehr Aufwand, vor allem für die > Kollisionserkennung bzw. Vermeidung. CAN macht das schon selber, da muss > man sich nicht drum kümmern. Ich würde auch CAN empfehlen, einfacher gehts nicht. Der Master muß nichts pollen. Jeder Teilnehmer sendet einfach drauflos, sobald ein RFID-Chip erkannt wurde. CAN kümmert sich um alles in HW.
Bei Modbus RTU wäre der Overhead wirklich nicht zu vernachlässigen aber mal eine grobe Rechnung: 3,5 Byte Start + 1 Byte Adresse + 1 Byte Funktion + 1 Byte Daten + 2 Byte CRC , macht also in Summe 8,5 Byte bzw. ~94 Baud bei 8E1. Bei 9600 Baud würde dann das aulesen eines Statusbits (RFID vorhanden) ca. 10ms dauern, d.h. in ca. 300ms ist klar ob irgendwo ein RFID-Tag gescannt wurde. Das finde ich jetzt gar nicht soooo übel. Das schöne am Modbus RTU ist halt die relativ geringe Anforderung an die Hardware, die große Verbreitung und die offene Spec. CAN hat halt definitiv Vorteile bei der Geschwindigkeit bzw. Reichweite, braucht aber halt eine CAN-PHY und die ist halt nicht so trivial zu haben wie ein UART. Beim F103 kannst du z.B. nicht CAN und USB gleichzeitig nutzen. Das könnte aber z.B. ein F042 oder F072. Was für einen STM32 hast du denn eigentlich? Bei Cortex M3 tippe ich mal auf F103.
Was ist denn bei CAN mit den unterschiedlichen Potenzialen? Ihr wollt doch nicht etwa die Masse auf diese Länge einfach durchschleifen. Da muß doch zwischen MCU und Transceiver noch ein Isolator: https://www.nve.com/Downloads/il41050ta.pdf RS485 mit zwei Adern kann man schon vollduplexfähig machen. Aber das wäre ne aufwändige Spezialschaltung. Das lohnt nicht, denn als fertiger Chip sah ich das noch nirgends. Oder doch Stromschleife 20mA.
:
Bearbeitet durch User
Abdul K. schrieb: > Was ist denn bei CAN mit den unterschiedlichen Potenzialen? CAN hält schon einiges an Masseversatz aus. https://gemac-fieldbus.com/de/common-mode/ +7/-2V Naja, RS485 kann da mehr, aber für die normalen CAN-Sachen reicht es. > Ihr wollt > doch nicht etwa die Masse auf diese Länge einfach durchschleifen. Warum nicht. Wenn man da keinen großen Strom drüber schickt, geht das schon. > Da muß > doch zwischen MCU und Transceiver noch ein Isolator: > https://www.nve.com/Downloads/il41050ta.pdf Kann man machen, muss man nicht, wenn alle Knoten lokal gespeist werden. > Oder doch Stromschleife 20mA. Als Bus für 30 Knoten? Eher nicht.
Der Thread heisst "... hohe Geschwindigkeit" und erwähnt "9600kBit/s". Nun sieht das zwar nach einem Schreibfehler aus, aber andererseits sind 9600 bit/sec nicht direkt das, was man gemeinhin unter einer hohen Geschwindigkeit versteht. Vielleicht sollte man klären, was wirklich gefordert ist.
In den 90er Jahren galten 14.400 Baud Modemen als "high Speed" und kosteten mehr als heutige Kabel/DSL Modemen mit 400.000.000 Baud. Das waren noch Zeiten ...
9,6 Mbaud/s sind wohl bei 2000m Leitungslänge doch etwas unrealistisch und 9600 Baud/s sind ja immer noch "schnell", z.B. verglichen mit 1200 Baud/s ;)
Frank M. schrieb: > Ich bin zwar nicht Falk, aber Du solltest seinen Beitrag ruhig nochmal > mit abgekühltem Gemüt lesen. Was er da sagt, hat Hand und Fuß. Seine Beiträge hatten noch nie Hand und Fuß. Und seine Antworten wie Unsinn, das läuft schon, wenn man keinen Murks baut und Kann man machen zeugen nur davon, daß er keine Ahnung davon hat. Man kann vieles machen, aber einfach 2000m Kabel verlegen und hoffen, daß alles gut geht, weil man ja keinen Murks gebaut hat, ist einfach Unsinn. > Davon abgesehen: In welcher "Norm" steht das mit den 1200 Metern? Meines > Wissens nach sind das lediglich Erfahrungswerte. Probiers doch einfach > mal aus. Natürlich steht das in keiner Norm, das sind ganz einfach Empfehlungen, basiert auf Erfahrungen und Berechnungen. Siehe auch: https://www.maximintegrated.com/en/app-notes/index.mvp/id/3884 Aber mal abgesehen davon, ist CAN sowieso die weitaus bessere Wahl, vor allem weil man sich praktisch um nichts kümmern muß und CAN kann, im Gegensatz zu RS485, ohne Probleme verlegt bzw. nachträglich verlängert werden - es muß nur auf die stub länge geachtet werden - Bustopologie ist ohne Bedeutung.
:
Bearbeitet durch User
Zum Daisy Chain aka Punkt-zu-Punkt aka 2 Schnittstellen je Modul: Der Durchsatz ist genauso hoch wie beim Bus Ein Fehler kann sofort lokalisiert werden, Teilketten laufen weiter Signaltechnisch das einfachste/robusteste Ja, der Zeitverzug ist da, aber da liegt es bei 30 Rechner bei etwa 1s @30byte-telegramme. Und wie gesagt, der Gesamt-Durchsatz ist gleich.
A. S. schrieb: > Zum Daisy Chain aka Punkt-zu-Punkt aka 2 Schnittstellen je Modul: > > Der Durchsatz ist genauso hoch wie beim Bus > > Ein Fehler kann sofort lokalisiert werden, Teilketten laufen weiter > > Signaltechnisch das einfachste/robusteste Geradezu trivial wird es, wenn man vollduplex Verbindungen spendiert. > Ja, der Zeitverzug ist da, aber da liegt es bei 30 Rechner bei etwa 1s > @30byte-telegramme. Und wie gesagt, der Gesamt-Durchsatz ist gleich. Dank der relativ kurzen Kabel geht es auch deutlich schneller. Noch dazu kann die Sende-/Empfangsumschaltung entfallen.
Bauform B. schrieb: > Geradezu trivial wird es, wenn man vollduplex Verbindungen spendiert. Stimmt: Vollduplex ist ja sonst gar nicht drin. Damit wird es insgesamt deutlich schneller und robuster. Auch ist es wesentlich einfacher, mal ein langes Teilstück von ein paar tausend Metern zu realisieren, eine galvanische Trennung einzubauen oder das Medium beliebig zu wechseln, z.b. POF oder Funk.
Daisy chain gehenuber Bus hat den Nachteil, dass bei Stationsausfall alle hinter dran nicht mehr gesehen werden. Ja, welcher es ist ist leicht herauszufinden.
Hallo Zusammen, nochnals vielen Dank für die Überlegungen/ Gedankenanstöße. CAN Bus erscheint mir nun auch vielleicht die bessere Wahl, vor allem weil es bis mehrere km spezifiziert ist und weil jeder Slave sehr schnell ohne Anforderung senden darf. Großes Problem an der Sache: Ich habe mit dem STM32 noch NIE etwas mit CAN Bus zu tun gehabt, weiß also nicht im geringsten wie ich das anfange. Hat da jemand ein Codebeispiel o.ä.?
Hanna schrieb: > Großes Problem an der Sache: Ich habe mit dem STM32 noch NIE etwas mit > CAN Bus zu tun gehabt, weiß also nicht im geringsten wie ich das > anfange. Hat da jemand ein Codebeispiel o.ä. Gibt es für sowas nicht Lehrgänge? Sowas muss doch dein Arbeitgeber zahlen. So habe ich mich in Richtung CANopen weitergebildet
Der Zweite günstige Troll aus dem Duzendpack schrieb im Beitrag #5924194: > Daisy chain gehenuber Bus hat den Nachteil, dass bei Stationsausfall > alle hinter dran nicht mehr gesehen werden. Dafür funktioniert der vordere Teil noch, während am Bus ein defekter Transceiver alle Stationen lahmlegt ;) Man könnte die beiden Kabel stecken, und zwar mit Männchen und Weibchen. So kann man eine defekte Station mit 2½ Handgriffen isolieren und der Rest geht wieder. Mit Relais könnte man das auch noch automatisieren, kostet aber ca. 8 Umschalter. Wie immer ist das wirkliche Leben nicht einfach schwarz/weiß.
Suche Dir ggf. einen STM32 aus, der USB und CAN gleichzeitig unterstützt, z.B. den STM32F303. Der alte STM32F103 kann das nicht.
Nochwas: DaisyChain erfordert keine parallele Adressierung. Also keine dippschalter, unique IDs oder Parametrierung. Bei CAN muss ich schon dafür sorgen, dass keine 2 Geräte das gleiche Telegramm zu senden versuchen.
Die maximalen 100 Meter (pro Segment) sind für RS485/RS422 Treiber absolute Pillepalle. Da kannst du fast jedes beliebige Kabel verwenden und hast viel Luft nach oben für längere Kabel oder höhere Übertragungsraten. Und diese Treiber sind billig. Deswegen plädiere ich ebenfalls für eine Daisy_Chain. Die Programmierung ist vor allem bei RS422 simpel, da Kollisionen ausgeschlossen sind. Jeder kann jederzeit senden, was er will, und der nächste in der Kette reicht das dann weiter bis zum Host, sobald er kann.
Hallo Stefanus, ja mittlerweile erscheint mir diese Variante auch als die Beste, da ich wirklich hohe Taktraten verwenden kann und (ich will mit CAT7 Kabeln und RJ45 Buchsen auf dem Layout arbeiten) eigentlich mit wenigen Fehlern zu rechnen ist. Was mir noch nicht ganz klar ist ist, wie ich die Aktualisierungsrate berechne: Wenn ich jetzt mal von sau langsamen 9,6kbps ausgehe und von 10 Byte Anfrage (Master -> Slave) und 25Byte Rückantwort (Slave-->Master), dann davon ausgehe, dass meine Daisy-Chain 32 Teilnehmer hat, also 25*32Byte zurück geschickt werden, da jeder Teilnehmer das gesamte Array überträgt und nur "seinen Teil" mit Nutzdaten befüllt, dann komme ich auf 6400bit die übertragen werden müssen. Das wären 666ms von einem Teilnehmer zum nächsten. Das würde bedeuten, die Aktualisierungsrate vom letzten zum Master wären ~ 32*0,66s = 21 Sekunden. Bei 115,2kbps sind es 5,5ms (mit etwas Rechnerei etc sind es schnell mal 10ms), also 3,2 Sekunden. Auch nicht so rosig :-(
Moin, für "Fabrikumgebung" habe ich auf modbus und Ethernet gesetzt. Ethernet darum, um skalierbar zu bleiben, die intelligenten Hubs die kaum noch was kosten, sorgen dafür, dass nicht alle Teilnehmer mit Paketen beschallt werden. Das kostet deutlich weniger an Aufwand was das Repeating angeht. Für Umsetzung von modbus RTU/TCP gibt es einige offene Libraries. Wir haben dafür einen Embedded Linux-Server als Hutschienengerät gebaut, inzwischen gibt's aber ähnliches schon aus der RPi-Fraktion oder von Siemens. Nachteil sind bei Linux die Boot-Zeiten, wenn das System nach einem Power-Out schnell hochstarten muss. Und natürlich kann man auch CAN nehmen, aber das klingt für den Fall etwas nach Kanonen auf Spatzen. RS485 ist immer noch robust genug und gut zu debuggen. Solang man nicht auf die Idee kommt (Klassiker), die Signalmasse wegzulassen.
Hanna schrieb: > da jeder Teilnehmer das gesamte Array überträgt > und nur "seinen Teil" mit Nutzdaten befüllt, Das würde ich anders machen. Jeder Teilnehmer sende nur seine Daten zusammen mit einer eindeutigen ID Nummer. Wenn du die Daten aller Teilnehmer zusammen packen willst, musst du sie sammeln und zeitlich koordinieren. Wie stellst du dir das praktisch vor? Die Übertragungszeit hängt maßgeblich davon ab, wie schnell die Teilnehmer ein Paket weiter reichen.
Hanna schrieb: > Wenn ich jetzt mal von sau langsamen 9,6kbps ausgehe und von 10 Byte > Anfrage (Master -> Slave) und 25Byte Rückantwort (Slave-->Master) Mit einer vollduplex Daisy Chain muss man eigentlich nicht pollen. Gerade diese Anwendung müsste doch rein ereignisgesteuert funktionieren? Sobald eine RFID gelesen wurde, kann der Slave sofort die Daten senden. Die anderen Stationen können das Paket weiterleiten ohne es zu dekodieren (wenn es aus der Richtung kommt, kann es ja nur für den Master bestimmt sein). Das ergibt ein Zeichen Verzögerung pro Station. In der anderen Richtung muss ein Slave entscheiden, ob das Paket für ihn selbst bestimmt ist oder ob er es weiterleiten muss. Das kann aber spätestens nach dem 2. oder 3. Zeichen klar sein. Wenn nur dann Pakete unterwegs sind, wenn tatsächlich etwas zu tun ist, wird die Antwortzeit in der Praxis sehr kurz. Immerhin muss jemand mit einem RFID-Teil hantieren. Ich sehe wenig Gründe, warum der Master ein Art Abfrage senden muss: natürlich beim Neustart des Masters, zur Fehlersuche und ggf. um den Slaves gelegentlich die Uhrzeit zu schicken. Für's "Kinder zählen" könnten die Slaves alle Minute oder so ein ping schicken.
Hanna schrieb: > Hallo Stefanus, > > ja mittlerweile erscheint mir diese Variante auch als die Beste, da ich > wirklich hohe Taktraten verwenden kann und (ich will mit CAT7 Kabeln und > RJ45 Buchsen auf dem Layout arbeiten) eigentlich mit wenigen Fehlern zu > rechnen ist. Du verwechselst CAN-Bus mit CAN-Protocol. Man kann sehr wohl CAN Transceiver benutzen ohne das CAN Protokoll, d.h. genauso wie RS485. Beim CAN wird, im Gegensatz zu RS485 jedes gesendete bit auch gleich wieder empfangen und dadurch kann man Kollisionen sofort erkennen. Also, falls irgendein Node yy sendet aber yz empfängt, dann hat ein anderer Node oder Master dazwischengefunkt. Danach wird die empfangene Adresse bit für bit mit eigener (gesendeten) Adresse verglichen und es wird festgestellt ob die eigene Adresse höher oder niedriger ist. Falls die eigene Adresse niedriger ist, wird die komplette Nachricht inkl. Adresse wieder gesendet, falls die eigene Adresse höher ist, wird gewartet bis die andere Nachricht zu Ende ist. Deswegen sind die vorgeschlagenen ASCII-Nachrichten ungeeignet, sowohl für RS485 als auch besonders für CAN. Vorschlag:
1 | EA - ZA - R/A - DL - data - CRC - EOF |
2 | | | | | |
3 | | | | Data |
4 | | | | length |
5 | | | | |
6 | | | Request/ |
7 | | | Answer |
8 | | | |
9 | | Ziel |
10 | | Adresse |
11 | Eigene
|
12 | Adresse
|
Mit solch einem Format der Nachrichten kannst du dein Netz ohne Probleme um weitere Funktionen, Master, Endgeräte ganz anderer Art usw. erweitern.
:
Bearbeitet durch User
Wenn man einen doppelten Ring baut (2 Adern für die Kommunikation links herum, und zwei für die umgekehrte Richtung) und jeder Teilnehmer immer in beide Richtungen gleichzeitig sendet, hat man sogar Redundanz gehen Ausfälle einzelner Knoten.
Marc V. schrieb: > Deswegen sind die vorgeschlagenen ASCII-Nachrichten ungeeignet, sowohl > für RS485 als auch besonders für CAN. ASCII hat aber den unschätzbaren Vorteil, menschenlesbar zu sein. Zur Fehlersuche einfach ein Terminal(programm) dran hängen und klar sehen... Bei so wenig Adressen würde ich das sogar für die komplette CAN-Nachricht versuchen.
Bauform B. schrieb: > ASCII hat aber den unschätzbaren Vorteil, menschenlesbar zu sein. Zur > Fehlersuche einfach ein Terminal(programm) dran hängen und klar sehen... ASCII wird bei weitem überschätzt... Ein Programm in VS zu erstellen um die Nachrichten zu dekodieren, dauert kaum ein paar Stunden und der ganze Verkehr auf dem Bus ist dann weitaus verständlicher und menschenlesbar...
:
Bearbeitet durch User
Marc V. schrieb: > ASCII wird bei weitem überschätzt... Sehe ich anders. Bei der Vernetzung von Servern haben binäre Protokolle längst weitgehend ausgedient. Menschen-lesbare Protokolle erleichtern das Troubleshooting massiv. Sofern es die Performance-Anforderungen zulassen, sollte man meiner Meinung nach immer auf Text statt Rohdaten setzen.
Stefanus F. schrieb: > Marc V. schrieb: >> ASCII wird bei weitem überschätzt... > > Sehe ich anders. Bei der Vernetzung von Servern haben binäre Protokolle > längst weitgehend ausgedient. Menschen-lesbare Protokolle erleichtern > das Troubleshooting massiv. ASCII erleichtert da genau nichts. Troubleshooting wird nicht durch einfaches lesen der Nachrichten mit irgendeinem Terminalprogramm gemacht. Ein mithörendes Programm welches alle Nachrichten übersichtlich (entweder nach Node oder Zeit oder Art der Nachricht) sortiert, mit kommentiertem Inhalt, ist für so etwas ganz einfach ein MUSS. Ausserdem ist es ein gewaltiges Unterschied, ob eine Node 3 Bytes oder 1 Byte einlesen muss, um die Zieladresse zu dekodieren. Ob man 4 Bytes oder 10 ASCII-Ziffern sendet... Und: Je kürzer die Nachricht selbst ist, umso effizienter ist das Ganze. Nicht umsonst hat CAN die länge der Daten begrenzt...
:
Bearbeitet durch User
Wenn der HOST rechts ist: Knoten <--> Knoten <--> Knoten <--> Host Jeder Knoten sendet seine Daten nach rechts. Was er von links bekommt, sendet er nach rechts weiter. Wenn alle gleichzeitig senden, passiert, ... nichts. Wenn jeder sein Telegramm fertig hat, ist das nächste reingekommen und kann gesendet werden. Wenn Du pollen möchtest, dann sendet der Host z.B. an Alle nach links: "Gebt mir Eure Daten". Was von rechts kommt, wird nach links weitergeleitet. Also senden alle ihre Daten. Die Absender-Adressierung ist einfach: Ein Feld wird bei jedem Weiterleiten erhöht, mit Initialer 1: Sehe ich eine 3, dann kommt es vom dritten Gerät aus der Richtung Die Empfänger-Adressierung ebenso: Ein Feld ist 0 (dann gehts an jeden) oder >0, dann ist es bei 1 für mich, bei >1 wird dekrementiert und weitergeleitet.
Hanna schrieb: > Großes Problem an der Sache: Ich > habe mit dem STM32 noch NIE etwas mit CAN Bus zu tun gehabt, weiß also > nicht im geringsten wie ich das anfange. > Hat da jemand ein Codebeispiel o.ä.? Ich hab mal ein Beispiel für eine CAN-Configuration für einen F072 angehängt. Das Beispiel stammt aus den "STM32F0 Snippets", basiert also lediglich auf Registerprogrammierung mittels CMSIS-Header (das komplette Paket bekommt man unter https://www.st.com/en/embedded-software/stm32snippetsf0.html). Von der Konfiguration her ist CAN schon ein bisschen komplizierter als SPI oder I2C aber immer noch viel einfacher als z.B. USB. Der Code ist schon sehr gut kommentiert aber wie immer hilft ein Blick in das Reference-Manual (in diesem Fall dem des F072).
Christopher J. schrieb: > Ich hab mal ein Beispiel für eine CAN-Configuration für einen F072 > angehängt. Danke. CAN ist nun wirklich keine große Kunst, und auch für STM32 findet man Codebeispiele ohne Ende. Klar kann man das noch beliebig verkomplizieren, indem man noch weitere Schichten wie CANopen etc. oben drauf packt - braucht es aber nicht; CAN reicht meiner Meinung nach für diese Applikation völlig aus. Ja, das Erlernen einer neuen Busschnittstelle bedeutet Arbeit und kostet Zeit - wie auch das Einarbeiten in einen neuen Mikrocontroller oder in eine neue Programmiersprache. Das ist immer so im Leben; gratis gibts fast nix. Letztendlich muss Dein Chef (bzw. der Kunde) aber sagen, was er konkret will bzw. braucht. Nicht zu unterschätzender Vorteil von Standardlösungen wie CAN, RS485 usw. im Gegensatz zu "wilden" Selbstbaulösungen mit Stromschleifen, RS422 usw.: Es gibt auch halbwegs professionelle Bus-Sniffer für relativ wenig Geld - ein im normalen Entwickleralltag unverzichtbares Utensil, und hat sich normalerweise schnell bezahlt gemacht (zumal bei anderen Lösungen im Allgemeinen nicht nur Zeit für die Fehlersuche drauf geht, sondern auch über Gebühr viel Aufwand für die eigentliche Definition und Implementierung des eigentlichen Busses, so wie er bei RS485 und speziell CAN schon vorhanden bzw. systemimmanent (Arbitrierung usw.) ist.). Wenn allerdings selbst sowas Deinem Chef zu teuer ist...
Hanna schrieb: > Gut und schön, aber bei 2000m > Leitungslänge sollte das selbst bei 9600kBit/s eher NICHT laufen. Du siehst das zu schwarz. Vor über 30 Jahren haben wir problemlos 307kBd (vielleicht sogar 1,8MBd) mit RS422 über einen beidseitig abgeschlossenen Bus aus gewöhnlichem Telefonkabel übertragen. Clock und Daten gingen dabei allerdings über separate Paare. Die Länge des Bus in den Türmen der Stadtverwaltung dürfte bei etwa 600m gelegen haben. https://de.wikipedia.org/wiki/CTOS
Hanna schrieb: > Es gibt, in einer Gesamtlänge von ca 2000m insgesamt 30 kleine 2km Kabel fachgerecht zu verlegen werden wohl alle Hardwarekosten deutlich übertreffen => nimm gleich SMF!
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.