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.
> 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.
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
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.
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.
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.
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.
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ß.
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.
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...
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...
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 abschalten