Hallo zusammen Ich habe hier folgende Ausgangslage: Mehrere Devices (slaves) müssen über einen einzigen Bus (Feldbus) angesprochen werden können. Die Slaves werden selbst entwickelt. Der master (wenn es kein PC ist) ebenfalls. Datenmengen sind bescheiden. Einige 20-30 bytes pro 10-20 sekunden für 3-5 slaves. Die restlichen erhalten nur sporadisch ein paar bytes. Nach einiger recherche habe ich den Modbus gefunden. Modbus RTU (über RS485) scheint eigentlich ideal zu sein für diese aufgabe. Aber halt ziemlich alt. Viele andere Feldbusse laufen über TCP IP. Schöne sache, heute auch nicht mehr sooo schwer zu handhaben aber halt doch overhead auch auf hardware seite. Daher meine Frage, weil Modbus ja schon sehr sehr alt ist. Ist es noch vertretbar / sinnvoll heute neue modbus devices zu entwickeln oder gibt es ähnliche alternativen? Proprietäre protokolle möchte ich möglichst vermeiden. Danke schonmal
Modbus ist aktueller denn je. Evtl. wäre halt CAN noch was für dich.
RS485 ist ein super Bus. Einfach, robust, 2Draht und bis zu 250 Teilnehmer (sportlich...) und je nach Datenrate mehrere KM lang. Nachteil ist das alles tot ist wenn einer den Bus blockiert. Terminierung und Verkabelung muss beachtet werden, aber ansonsten mein lieblings Feldbus. Modbus kann man machen. Warum nicht, gibt sehr viele Geräte und Hersteller die darauf setzen. Ist aber viel Protokoll für die paar Bytes. Wenn es niemals zu etwas anderem kompatibel sein muss, würde ich ein einfaches eigenes Protokoll zusammenbauen. Hängt davon ab ob Du fertige Modbus Stacks bekommst die Du leicht implementieren kannst oder ob Du das alles selbst coden musst.
Ich bevorzuge RS422, weil bidirektional. Sind halt 2 Draehte mehr. Aber die Treiber sind dieselben. Fuer hireichend tiefe Baudraten und hireichend kurze distanzen kann man sich die Terminierung schenken. Und habe mein eigenes Protokoll. Dieses ist publiziert, die Kunden koennen's selbst einbauen, oder meine PC-App verwenden. Das Potokoll kann einfacher sein, wenn man die Richtung nicht umschalten muss.
:
Bearbeitet durch User
Jetzt ist G. schrieb: > Ich bevorzuge RS422, weil bidirektional. Aber auch nur bei zwei Geräten am "Bus". Bei mehreren wird es knifflig, und dann kann man auch einfach bei RS485 bleiben. Es ist bei RS485 allerdings hilfreich, eine vernünftige UART zu verwenden, die hardwareunterstützung für RS485 enthält - d.h. die nötige Sender-/Empfängerumschaltung selbsttätig vornimmt. Sonst muss man entweder sehr entspannte Timingvorgaben machen (Slave darf auf Masteranfrage erst nach einem gewissen Timeout reagieren) oder darauf hoffen, daß die UART geeignete Statusbits für "Sendeschieberegister leer" oder besser noch einen Interrupt für diese Bedingung hat. Das ist nicht bei jeder UART der Fall.
Hardwareunterstützung ist immer nett, aber wenn nicht gerade ein OS mit seinen sehr eigenwilligen Timing Vorstellungen dazwischen hängt, ist das reagieren auf den TX Ready IRQ schneller getan als die Laufzeit zum Slave + decode. Wenn der PC Master ist, findet man bei FTDI USB / Uart wandler mit RS485 Unterstützung. Edit: Uart ohne TX ready IRQ? Ups, was es alles gibt ...
> Daher meine Frage, weil Modbus ja schon sehr sehr alt ist. > Ist es noch vertretbar / sinnvoll heute neue modbus devices zu > entwickeln oder gibt es ähnliche alternativen? Weil etwas alt ist ist es schlecht? Scheint mir eine sehr dumme Argumentation zu sein. Tatsaechlich hat Modbus sogar den Vorteil das du da einiges an Doku und Testsoftware finden kannst ohne gleich Mitglied in einem sehr teuren Verein zu werden wie das bei vielen anderen modernen Feldbussen ueblich ist. Etwas anderes das du dir mal anschauen kannst ist HART. Ich wuerde nicht den Bus direkt verwenden weil du da auch Mitglied werden musst und deine Hardware teuer getestet wird, aber du koenntest dir ja was eigenes auf der Basis verfuegbarer HART-Modeme ausdenken. HART haette den Vorteil das du mit zwei Leitungen auskommst weil das auf die Versorgungsspannung aufmoduliert wird. Olaf
Hi Mir erschließt sich der Vorteil einer RS485 gegenüber CAN nicht. CAN löst viele Probleme schon die man bei RS485 selber lösen muss. Multimasterbetrieb zum Beispiel. Oder Prüfsumme. Oder Adressierung. Wenn's die Controller hergeben würde ich immer zu CAN greifen. Matthias
Μαtthias W. schrieb: > Mir erschließt sich der Vorteil einer RS485 gegenüber CAN nicht. So sehr unterscheiden die sich garnicht. Can löst eine ganze Menge direkt in Hardware, was man bei RS485 noch zu Fuss machen muss. Der Vorteil von RS485 ist das jede dödel MCU einen Uart besitzt aber nur die teuren Teile einen Can Controller. RS485 gab es schon als an Can noch nicht mal gedacht wurde. RS485 reicht locker für die meisten Sachen aus. Auch eigene Protokolle dafür zu schreiben ist nicht schwerer als den Can Controller zu betütern. Wie sehr ich die Datenrate bei Can anpassen kann um die Reichweite zu erhöhen, weiß ich gerade nicht.
Ich danke euch für die vielen Antworten und Kommentare. Ich sehe das ich auf dem richtigen Weg bin! Danke und schönes Wochenende
RS422 ist passend fuer einen Master-Slave Bus, dh der Master empfaengt immer, und die Slaves senden nur auf Anfrage.
Jetzt ist G. schrieb: > dh der Master empfaengt immer, und die Slaves senden nur auf Anfrage. Und worin besteht dabei der Unterschied zu RS485? Wozu zwei Leitungen für einen nicht auftretenden Betriebsfall (Master sendet und empfängt gleichzeitig) vergeuden?
Michael K. schrieb: > Hardwareunterstützung ist immer nett, aber wenn nicht gerade ein OS mit > seinen sehr eigenwilligen Timing Vorstellungen dazwischen hängt, ist das > reagieren auf den TX Ready IRQ schneller getan als die Laufzeit zum > Slave + decode. Er meint eher nen Flag für "TX Schieberegister empty" oder "TX Idle". Wenn der TX Ready IRQ kommt, dann ist zwar das Datenregister am CPU Bus leer, aber der UART sendet noch. Das Datenregister wird ja ins Schieberegister geladen und dann rausgeschoben. Wenne jetz bei TX empty den Bustreiber deaktivierst fehlt da was vom letzten Byte. Michael K. schrieb: > Der Vorteil von RS485 ist das jede dödel MCU einen Uart besitzt aber nur > die teuren Teile einen Can Controller. STM32F103 sind für dich also teuer?
> Und worin besteht dabei der Unterschied zu RS485? Wozu zwei Leitungen
für einen nicht auftretenden Betriebsfall (Master sendet und empfängt
gleichzeitig) vergeuden?
Der Vorteil .. ich muss keine Richtung umschalten, muss keinen einzigen
Gedanken dran verschwenden. Ob's nun 3 oder 5 pins/pole sind, ist mir
egal. Ist kein Kostenfaktor. Der PC kann ohne Sonderhardware arbeiten
Richtung umschalten heißt es dann zwar nicht, aber 2 Bustreiber könn ja wohl nicht gleichzeitig auf diselbe Doppelader treiben. Also muss immernoch der Bustreiber beim senden aktiviert und danach deaktiviert werden. Also gleiches problem wie beim RS485. Also hör hier doch bitte auf zu trollen.
Ja, die slaves müssen schon ihren Treiber deaktivieren wenn sie nicht dran sind. Aber prinzipiell könnte der Master z.B. dem slave 2 was schicken während er noch auf den ersten hört. Ob das mit dem Protokoll vereinbar ist steht wieder auf einem anderen Blatt.
Nee. Nicht gleiches Problem wie RS485. Beim 422 in Vollduplex mode wird der Slave beim Senden eingeschaltet. Der Master, der PC, muss nichts.
Jetzt ist G. schrieb: > Nee. Nicht gleiches Problem wie RS485. Beim 422 in Vollduplex mode wird > der Slave beim Senden eingeschaltet. Der Master, der PC, muss nichts. Damit ist das "Problem" also nur beim Master nicht vorhanden. Bei den Slaves hast Du aber exakt gar nichts gewonnen, die müssen nach wie vor den Bus freigeben, wenn sie nichts zu melden haben.
Jetzt ist G. schrieb: > Und > habe mein eigenes Protokoll. Dieses ist publiziert, die Kunden koennen's > selbst einbauen, oder meine PC-App verwenden. Nen Link wäre so langsam mal interessant.
Rufus Τ. F. schrieb: > Es ist bei RS485 allerdings hilfreich, eine vernünftige UART zu > verwenden, die hardwareunterstützung für RS485 enthält - d.h. die nötige > Sender-/Empfängerumschaltung selbsttätig vornimmt. Rufus Τ. F. schrieb: > Damit ist das "Problem" also nur beim Master nicht vorhanden. Bei den > Slaves hast Du aber exakt gar nichts gewonnen, die müssen nach wie vor > den Bus freigeben, wenn sie nichts zu melden haben. Man könnte es sich einfach machen und UART mit CAN Bustreibern benutzen. Dadurch müssen die µC kein CAN unterstützen, aber der Slave oder Master muß auch nicht den Bustreiber deaktivieren, wenn er mit Senden fertig ist. Wenn die einzelnen Slaves nur auf Anforderung senden, gibt es ja keine Bus-Kollisionen. Trotzdem könnte eine Buskollision erkannt werden, wenn der Sender nicht seine eigenen, gerade gesendeten Daten korrekt in seinem Rx-Buffer vorfindet.
:
Bearbeitet durch User
Jetzt ist G. schrieb: > Ich bevorzuge RS422, weil bidirektional. Sind halt 2 Draehte mehr. Aber > die Treiber sind dieselben. Fuer hireichend tiefe Baudraten und > hireichend kurze distanzen kann man sich die Terminierung schenken. Und > habe mein eigenes Protokoll. Dieses ist publiziert, die Kunden koennen's > selbst einbauen, oder meine PC-App verwenden. Das Potokoll kann > einfacher sein, wenn man die Richtung nicht umschalten muss. LOL. Was wird bei bidirektional umgeschaltet ? Mw E. schrieb: > Nen Link wäre so langsam mal interessant. Ja, das würde mich auch interessieren. Sogar sehr.
Thomas E. schrieb: > Trotzdem könnte eine Buskollision erkannt werden, wenn der Sender nicht > seine eigenen, gerade gesendeten Daten korrekt in seinem Rx-Buffer > vorfindet. Das bekommt man mit RS485-Treibern auch hin, dafür braucht es keine CAN-Treiber.
Rufus Τ. F. schrieb: > Thomas E. schrieb: >> Trotzdem könnte eine Buskollision erkannt werden, wenn der Sender nicht >> seine eigenen, gerade gesendeten Daten korrekt in seinem Rx-Buffer >> vorfindet. > > Das bekommt man mit RS485-Treibern auch hin, dafür braucht es keine > CAN-Treiber. Nein, das bekommt man mit RS485 nicht hin. P.S. Zumindest nicht ohne zusätzliche Leitungen.
:
Bearbeitet durch User
Rufus Τ. F. schrieb: > Das bekommt man mit RS485-Treibern auch hin, dafür braucht es keine > CAN-Treiber. Wie denn? Und warum sollte man das tun? CAN-Treiber sind billiger!
Thomas E. schrieb: > Wie denn? Und warum sollte man das tun? Indem man den Empfnag wärend des Sendens nicht abschaltet (RE nicht zusammen mit DE umschaltet). Allerdings sind RS485-Transceiver derart niederohmig, dass die Kollision gar nicht am Ausgang erkannt wird. > CAN-Treiber sind billiger! Bei denen kann man die Datenrichtung aber nicht umschalten. Und CAN-Controller erkennen schon am gesendenten Bit eine Kollision (Recessiv / Dominant), und reagieren entsprechend.
Thomas E. schrieb: > Rufus Τ. F. schrieb: >> Das bekommt man mit RS485-Treibern auch hin, dafür braucht es keine >> CAN-Treiber. > > Wie denn? Und warum sollte man das tun? CAN-Treiber sind billiger! /RE mit einem zusätzlichen Pin steuern oder mit GND verbinden. Macht man aber normalerweise nicht so (Es gibt schon Gründe dafür).
STK500-Besitzer schrieb: > Bei denen kann man die Datenrichtung aber nicht umschalten. Eben, darum geht es doch: die Umschaltung kann man sich sparen! Aber eben auch den CAN-Controller im µC. Ein noch einfacherer Bus wäre direkt UART im Halbduplex-Betrieb mit einer einzigen Datenleitung und Open Drain Tx-Ausgang. Aber das wäre halt störanfälliger.
Marc V. schrieb: > /RE mit einem zusätzlichen Pin steuern oder mit GND verbinden. > Macht man aber normalerweise nicht so (Es gibt schon Gründe dafür). Das löst aber immer noch nicht das "Problem", daß, wenn mehrere Geräte am Bus hängen, die einzelnen Geräte eben jeweils ihre Bustreiber deaktivieren müssen, wenn sie nicht senden.
Thomas E. schrieb: > Marc V. schrieb: >> /RE mit einem zusätzlichen Pin steuern oder mit GND verbinden. >> Macht man aber normalerweise nicht so (Es gibt schon Gründe dafür). > > Das löst aber immer noch nicht das "Problem", daß, wenn mehrere Geräte > am Bus hängen, die einzelnen Geräte eben jeweils ihre Bustreiber > deaktivieren müssen, wenn sie nicht senden. Genau. Deswegen benutzt man RS485 nur noch bei 2 Teilnehmer am Bus oder bei jederzeit genau definierten Buszuständen. Eine andere Möglichkeit wäre token ring aber das bedeutet einen ziemlichen Overhead an Software. Multimaster und RS485 verträgt sich auch nicht so gut. Kurz gesagt, CAN (nur Hardware Layer) und eigenes Protokoll ist meiner Meinung nach die beste Lösung für uC ohne CAN (ATMEL). ARM dagegen mit vollem CAN natürlich, kostet ja nichts,
RS485 ein gute Wahl fuer Multimaster Systeme. Denn es gibt Treiber nach Wahl. Je nach gewuenschter Eigenschaft. zB 25MBit@160m oder 3MBit @500m. Und ja, die Buszustaende muessen genau definiert sein. Das muessen sie eigentlich sowieso. Man sollte sowieso darauf achten, dass das verwendete Applikationsprotokoll zustandsfrei ist. Dann geht das schon. Gilt eigentlich fuer alle Protokolle. Man sollte nicht vergessen, dass CAN ein Automobilbus ist. Schnell, Verzoegerungsarm, mit kurzer Blocklaenge. Ist also nicht wirklich optimal fuer Nachrichten variabler, oder grosser Laenge.
:
Bearbeitet durch User
Rufus Τ. F. schrieb: > daß die UART geeignete Statusbits für > "Sendeschieberegister leer" Meist auch "Transmission complete" oder "TC" genannt.
@Jetzt ist G. (hacky) Den Link zu deinem Projekt haste schonwieder vergessen ;)
Holger K. schrieb: > Datenmengen sind bescheiden. Einige 20-30 bytes pro 10-20 sekunden für > 3-5 slaves. Die restlichen erhalten nur sporadisch ein paar bytes. Über 5 m oder 5 km?
Bei den geringen Datenraten könnte man auch LIN nehmen. Maximale Leitungslänge ist 40m.
Marc V. schrieb: > Jetzt ist G. schrieb: >> RS485 ein gute Wahl fuer Multimaster Systeme. > > Niemals. Darum wird es auch so oft als solches verwendet... Weil es nicht funktioniert. Grrr...
Jetzt ist G. schrieb: > RS485 ein gute Wahl fuer Multimaster Systeme. Radio Eriwan: Im Prinzip schon. Wenn Du denn das ganze Protokollgefriggel sauber in den Griff bekommst. Wer ist dran, was passiert wenn der nicht übernimmt, wer greift ein und reisst den Bus an sich, was passiert bei Kollision etc. pp. Da ist CAN ein Segen, der regelt das alles allein.
CAN ist schon ne feine Sache, ich hab mich als ich zum ersten Mal damit
zu tun hatte auch deutlich schneller damit angefreundet als ich
ursprünglich vermutet hatte.
> Multimaster
Holger K. hat aber nur einen Master. Der Vorteil von RS485 ist halt eben
daß es sich mit jedem ollen UART auf jedem noch so billigen µC
implementieren lässt.
UART ist eins von diesen System die das einfachst vorstellbare ihrer Art
sind, 100% davon dienen der nackten Funktion und nichts könnte mehr
weiter vereinfacht werden (genau wie sein Gegenstück SPI für synchrone
Übertragung), gewissermaßen ein elementares Verfahren. Deshalb wird UART
auch niemals sterben, wenn doch würde man es am nächsten Tag sofort
wieder erfinden und zwar wieder exakt genau so.
Bernd K. schrieb: > Der Vorteil von RS485 ist halt eben > daß es sich mit jedem ollen UART auf jedem noch so billigen µC > implementieren lässt. ... und der Vorteil von CAN Hardware-Layer mit dem gleichen billigen µC ist ein noch billigerer Treiberbaustein, der auf µC-Seite (im Gegensatz zu RS485) nichtmal einen weiteren Pin außer Tx und Rx benötigt.
Thomas E. schrieb: > ... und der Vorteil von CAN Hardware-Layer mit dem gleichen billigen µC > ist ein noch billigerer Treiberbaustein, Und ein CAN Controller und schon sinds 2 zusätzliche Bausteine (RS485 nur einer), oder willst Du CAN mit Bitbanging implementieren?
:
Bearbeitet durch User
Bernd K. schrieb: > Und ein CAN Controller und schon sinds 2 zusätzliche Bausteine (RS485 > nur einer), oder willst Du CAN mit Bitbanging implementieren? Nein, gar kein CAN Controller! Ich will nur den RS485 Treiberbaustein durch einen CAN Treiberbaustein ersetzen, das CAN Protokoll wird nicht benutzt.
Thomas E. schrieb: > Nein, gar kein CAN Controller! Ich will nur den RS485 Treiberbaustein > durch einen CAN Treiberbaustein ersetzen, das CAN Protokoll wird nicht > benutzt. Versuche ich seit 2 Tagen zu erklären. Bislang ohne Erfolg...
Aha. Zeig mal. Damit wir uns ein Datenblatt anschauen koennen. Ich werf mal fuer einen RS485 den SN65HVD24D fuer erhoehte Anforderungen ein.
@Marc, also ich hab dich schon verstanden. Ich zitier mich jetzt mal selbst: >@Jetzt ist G. (hacky) >Den Link zu deinem Projekt haste schonwieder vergessen ;) Mehr als Dampfplaudern kam bisher nicht von dir, also zeig doch mal her was du mit RS422 kannst! Hattest ja gesagt, dass du da schon was gebaut hattest. Dein Forennick ist jetzt aber nicht so herausstechend als ob man da mit google was finden würde. Was hat der SN65HVD24D jetzt zudem noch mit dem Thema zu tun? Er hat nen größeren Bereich fürn Common Mode und weiter? Einfach so ne Bezeichnung in Raumw erfen ohne zusagen worauf man hinaus will wirkt auch eher arrogant.
Naja, das ist was ein RS485 Treiber kann. Nicht jeder kann wie dieser 3MBit auf 250m. Was kann den ein CAN Treiber ? Zeig ein Datenblatt.
Zeig mir erstmaln Link zu deinem Projekt bevor ich mich weiter mit deinen steilen Thesen beschäftige ;)
Jetzt ist G. schrieb: > Damit wir uns ein Datenblatt anschauen koennen Z.B. SN65HVD1050 Jetzt ist G. schrieb: > Nicht jeder kann wie dieser > 3MBit auf 250m. Enorm wichtig, wenn man vielleicht 9600 Baud über 5m übertragen will...
Thomas E. schrieb: > Nein, gar kein CAN Controller! Ich will nur den RS485 Treiberbaustein > durch einen CAN Treiberbaustein ersetzen, das CAN Protokoll wird nicht > benutzt. Geht das so einfach? Dachte immer man muss das CAN Protokoll einhalten (Präambel, Adressen, Länge, Checksumme usw).
Jetzt ist G. schrieb: > RS422 ist passend fuer einen Master-Slave Bus, dh der Master empfaengt > immer, und die Slaves senden nur auf Anfrage. RS422 ist aber nur nur in Hardware genormt. Alles andere must du selbst machen. Da kann man mMn besser CAN nehmen. Hab viel mit 422 gemacht. Das ist über lange Entfernungen sehr aufwändig und du hast die Chance nicht nur zu verpolen sondern hast gleich mehrere Adern Chancen zum vertauschen und falsch zu terminieren. Wenn man die Entfernung hat, full duplex braucht und nur "Klingeldraht" bzw. Telefonleitung liegt dann macht die Schnittstelle Sinn sonst ....
X4U schrieb: > Geht das so einfach? Dachte immer man muss das CAN Protokoll einhalten > (Präambel, Adressen, Länge, Checksumme usw). Ja, das geht so einfach. Einem CAN-Tranceiver ist es genau wie z.B. einem MAX232 erstmal völlig egal was da an Bits übertragen wird und was diese bedeuten.
guest schrieb: > Ja, das geht so einfach. Einem CAN-Tranceiver ist es genau wie z.B. > einem MAX232 erstmal völlig egal was da an Bits übertragen wird und was > diese bedeuten. Das meinte ich nicht, klar wenn du nur Layer 1 nutzt ist es rein und raus transparent. Aber der TE sucht einen Feldbus für mehrere Endpunkte. Da bietet sich CAN doch an. Zum entwickeln und entstören gibt es dann noch Analyzer (auch im Feld) und DemoCode.
X4U schrieb: > Aber der TE sucht einen Feldbus für mehrere Endpunkte. Da bietet sich > CAN doch an. Er hat aber offen gelassen, welche Controller in seinen Endpunkten stecken - womöglich welche ohne CAN? Er selbst hatte ja auch schon Modbus über RS485 ins Auge gefasst. Die weitere Diskussion hat sich dann auch (wie üblich) von der Eingangsfrage ein Stück weit entfernt.
X4U schrieb: > Aber der TE sucht einen Feldbus für mehrere Endpunkte. Da bietet sich > CAN doch an. Zum entwickeln und entstören gibt es dann noch Analyzer > (auch im Feld) und DemoCode. Kommt drauf an. Wenn die Hardware CAN-Controller mitbringt und man mit den 8 Byte pro Nachricht auskommt ist CAN ne feine Sache. Allerdings läßt sich eine UART notfalls auch in Software nachbauen (Versuch das mal mit einem CAN-Controller) und ist in der Anstauerung auch ein Stück einfacher. Und wenn einem die 8 Byte nicht reichen braucht man so oder so noch ein zusätzliches Protokoll.
Es ist doch ganz einfach:
* Hast Du CAN-Fähige Controller oder kannst stattdessen auf solche
umsteigen oder sind externe CAN-Controller eine akzeptable Option?
-> Nimm CAN
* Hast Du nur Controller ohne CAN und/oder willst kein CAN?
-> Nimm RS-485
Den CAN-Controller zu initialisieren und zu benutzen benötigt kein
bisschen mehr Code als einen UART zu initialisieren und zu benutzen, von
daher Gleichstand. (Ok, zugegeben, bei nem externen Controller mußt Du
auch noch das SPI benutzen, also insgesamt etwas umständlicher als nur
den UART. Aber nicht inhärent schwierig, nur etwas mehr langweiliger
Code)
Beim Protokoll das Du Dir ausdenkst sind die jeweiligen Eigenschaften
des Übertragungsmediums zu berücksichtigen (was passiert wenn zwischen
dem 2. und dem 3. Teilnehmer das Kabel durchgeschnitten wurde, wie weißt
Du ob die Nachricht ankam, wie sollen die Geräte addressiert werden, muß
Der Master ständig pollen (RS-485) oder wäre es eventuell eleganter wenn
die Teilnehmer von sich aus Telegramme schicken wenn ein Ereignis
eintritt (CAN), maximale Nutzlast bei CAN ist 8 Byte pro Frame und
Übertragung längerer Datenblöcke ist gewünscht?, Firmware-Update über
den Bus gewünscht?)
:
Bearbeitet durch User
Da sind ja noch einige Antworten / Kommentare hinzugekommen. Also um noch ein Paar Unklarheiten zu beseitigen: Die aktuelle Hardware hat kein CAN im uC. Es ist geplant STM8 oder STM32F030 zu verwenden. Evtl. noch Atmega324.
Holger K. schrieb: > STM32F030 https://www.st.com/content/ccc/resource/technical/document/reference_manual/cf/10/a8/c4/29/fb/4c/42/DM00091010.pdf/files/DM00091010.pdf/jcr:content/translations/en.DM00091010.pdf Der unterstützt den RS485-Flow sogar in Hardware, und kann auch multiprocessor communication. Das vereinfacht die Sache bis auf die Kollisionserkennung.
Holger K. schrieb: > Also um noch ein Paar Unklarheiten zu beseitigen: Hättest Du ruhig die notwendigen Kabellängen sowie das Umfeld (Büro, Maschinenhalle) bekanntgeben können. Aber wie man sieht, gibt es ja auch schon Lösungen, ohne das Problem zu kennen. Hut ab! (oder war das der Kopf?)
STK500-Besitzer schrieb: > Das vereinfacht die Sache bis auf die Kollisionserkennung. Eben dafür wäre der CAN Hardware-Layer bestens geeignet - da alle Devices gleichzeitig alle (auch selbst gesendeten) Daten empfangen, ist eine Kollisionserkennung leicht möglich. Zudem sind die Tranceiver billiger (Digikey Einzelpreis für den billigsten SO-8 CAN-Tranceiver: 0,47 Euro, der billigste RS485-Cip kostet da >1 Euro) und man muss sich nicht mit Tx-Enable herumschlagen. Der µC muß nur über Tx- und Rx-Pins mit dem Tranceiver verbunden werden, kein weiteres Steuersignal. Der einzige "Nachteil" (wenn man es nicht als Vorteil sieht, der das Blockieren des Busses u.U. verhindert) ist, daß man eine gewisse Midestdatenrate braucht, damit der CAN Transmitter Timeout nicht zuschlägt.
Thomas E. schrieb: > Eben dafür wäre der CAN Hardware-Layer bestens geeignet - da alle > Devices gleichzeitig alle (auch selbst gesendeten) Daten empfangen, ist > eine Kollisionserkennung leicht möglich. Zudem sind die Tranceiver > billiger (Digikey Einzelpreis für den billigsten SO-8 CAN-Tranceiver: > 0,47 Euro, der billigste RS485-Cip kostet da >1 Euro) und man muss sich > nicht mit Tx-Enable herumschlagen. Der µC muß nur über Tx- und Rx-Pins > mit dem Tranceiver verbunden werden, kein weiteres Steuersignal. > Der einzige "Nachteil" (wenn man es nicht als Vorteil sieht, der das > Blockieren des Busses u.U. verhindert) ist, daß man eine gewisse > Midestdatenrate braucht, damit der CAN Transmitter Timeout nicht > zuschlägt. Ob man einen RS485- oder CAN-Transceiver verwendet ist doch völlig egal. Um die Vorteile des CAN-Bus benutzen zu können, ist ein CAN-Controller notwendig. Den müsste man beim gewählten 32bitter extern dranhängen. Damit wäre der Kostenvorteil nicht mehr gegeben. Timeoput-Geschichten sind nicht so mein Fall, da sie die ganze Bus-Geschichte verlangsamen. Mit der Multiprozessor-Kommunikation kann man sich das dann auch sparen. Und man kann eine eigene Datenlänge definieren (im Gegensatz zu den 8 Bytes bei CAN - CANopen ist ja eigentlich auch nur "Gebastel"). Wenn ein Slave nicht adressiert wurde, hält er die Klappe - ganz einfach.
m.n. schrieb: > Hättest Du ruhig die notwendigen Kabellängen sowie das Umfeld (Büro, > Maschinenhalle) bekanntgeben können. Stimmt. Sorry. Kabellänge: ca. 1-3 Meter. Umfeld: Semi-Profesionell. (Es werden 24V Motoren angesteuert). Aber ansonsten nichts wildes! Interessanter Ansazt mit den Can-Tranceivern. Jedoch kostet ein MAX485 bei Ali 0.037 USD inkl. Versand. Also keine 4Cent!
:
Bearbeitet durch User
Holger K. schrieb: > Kabellänge: ca. 1-3 Meter. > Umfeld: Semi-Profesionell. (Es werden 24V Motoren angesteuert). Ein RS232-Treiber vom Master an alle Endgeräte. Rückleitung der Endgeräte RS232 mit Diode+R entkoppelt zum Master. Vorteil: voll duplex und per Terminal bzw. PC bedien-/kontrollierbar. Holger K. schrieb: > Jedoch kostet ein MAX485 bei Ali 0.037 USD inkl. Versand. > Also keine 4Cent! Was hier gespart wird, zahlst Du bei der Software und beim Kabel+Terminierung wieder drauf ;-)
STK500-Besitzer schrieb: > Ob man einen RS485- oder CAN-Transceiver verwendet ist doch völlig egal. Ich geb's auf - anscheinend ist es nicht möglich, hier Ideen/Lösungen abseits der Hersteller-Applikationen oder per xxx-Konsortium-Beamten abgesegneten Bus-Spezifikationen 'rüberzubringen. Ok, CAN-Transceiver sind ausschließlich für CAN-Protokoll gemacht und dürfen selbstredend nur dafür verwendet werden, und UARTs kann man nur mit RS485 o.ä. Hardware-Specs benutzen - alles Andere steht nicht in den Hersteller-Datenblättern und geht deshalb nicht. Und weil man UART sowieso nicht über CAN-Layer benutzen kann, ist es auch völlig egal, daß man bei RS485 keine Datenkollisionen erkennen kann oder die Bustreiber im Fehlerfall ggf. einfach gegeneinander arbeiten. Auf diese Gegebenheiten muss man eben das Protokoll anpassen, statt einen Hardware-Transportlayer zu wählen, der sowas schon allein durch seine physikalische Funktionsweise löst. Wie der im CAN Transmitter untergebrachte Hardware-Timeout die Datenübermittlung verlangsamen soll, ist mir schleierhaft. Er schaltet lediglich die Bustreiber aus, wenn das Tx-Signal für eine gewisse Zeit auf 0 klemmt, daher auch die Mindest-Datenrate. Holger K. schrieb: > Jedoch kostet ein MAX485 bei Ali 0.037 USD inkl. Versand. > Also keine 4Cent! Ok, dann möchte ich gar nicht wissen, was CAN Transceiver bei Ali kosten...
Holger K. schrieb: > Kabellänge: ca. 1-3 Meter. > Umfeld: Semi-Profesionell. (Es werden 24V Motoren angesteuert). > Aber ansonsten nichts wildes! Dann ist LIN noch ein Kandidat, rein serielles Master-Slave Protokoll, simple Eindraht open collector Hardware (= beliebig hoher Störabstand) und Automotive spezifiziert. Bei 24V Motoren würde ich evtl. galvanisch trennen. Das geht bei LIN mit nur einem Optokoppler pro Endpunkt.
Thomas E. schrieb: > Ok, CAN-Transceiver sind ausschließlich für CAN-Protokoll gemacht und > dürfen selbstredend nur dafür verwendet werden, und UARTs kann man nur > mit RS485 o.ä. Hardware-Specs benutzen - alles Andere steht nicht in den > Hersteller-Datenblättern und geht deshalb nicht. Habe ich nie behauptet. Aus dem Zusammenhang gerissen, behauptest du das aber... ;) Um einem RS485-Bus zu betreiben, kann man SOWOHL einen RS485-Transceiver, als auch einen CAN-Transceiver benutzen, wobei sich die Endstufen der beiden unterscheiden. Bei CAN wird auf Bit-Ebene eine Kollision erkannt - bei RS485 (da byteweise orrienteriert) frühestens, wenn man seine eigenes Byte eingelesen hat.
Thomas E. schrieb: > Ok, CAN-Transceiver sind ausschließlich für CAN-Protokoll gemacht und > dürfen selbstredend nur dafür verwendet werden, und UARTs kann man nur > mit RS485 o.ä. Hardware-Specs benutzen - alles Andere steht nicht in den > Hersteller-Datenblättern und geht deshalb nicht. Ein Can Controller löst Kollisionen in einer Bitzeit auf, geht vom Bus und wartet eine zufällige Zeit. Ich bin mir daher nicht sicher ob ein Can Transceiver dauerhaft kurzschlussfest ist, wie ein RS485 Treiber. Weswegen also einen Can Transceiver für etwas benutzen für das ein RS485 Transceiver voll durchspezifiziert ist? Natürlich kannst Du ICs ausserhalb der Herstellerspec benutzen. Wenn Dir ein paar gesparte Cent den Ärger wert sind den Du Dir damit einfangen kannst, bitteschön. Meine Zeit ist zu teuer für diese Abendheuer. RS484 ist sehr viel älter als Can und trotz der schicken Funktionen eines Can Controllers immer noch ein sehr guter und einfacher Bus. Man muss nicht bei jeder 0815 Anwendung seine eigenen Kreationen da reinbringen wenn das schon 100mal sehr robust gelöst wurde. Verwende Deine Zeit doch lieber sinnvoller in der Lösung neuer Probleme statt Dir neue Probleme zu kreieren.
Michael K. schrieb: > Ich bin mir daher nicht sicher ob ein Can Transceiver dauerhaft > kurzschlussfest ist, wie ein RS485 Treiber. Bei CAN kann es keine Kurzschlüsse geben weil der Transceiver die Leitungen nur in die dominante Richtung treibt. Deshalb kann man mit RS-485 erheblich höhere Bitraten auf die selbe Länge erreichen als mit CAN. CAN-Transceiver für RS-485 ist vollständiger Käse. Es gibt keinen Grund dafür. Erstens ist es inkompatibel und zweitens weniger störsicher und erreicht geringere Datenraten. Die Nachteile aus beiden Welten vereint.
:
Bearbeitet durch User
Michael K. schrieb: > Ich bin mir daher nicht sicher ob ein Can Transceiver dauerhaft > kurzschlussfest ist, wie ein RS485 Treiber. Du weisst aber schon, wie ein CAN-Transmitter aufgebaut ist und was passiert, wenn der eine eine "1" und der andere eine "0" auf den Bus schickt? Michael K. schrieb: > Natürlich kannst Du ICs ausserhalb der Herstellerspec benutzen. Wo soll den da etwas außerhalb der Spec der Tranceiver benutzt werden? Es wird lediglich kein CAN-Protokoll verwendet, die Bus-Hardware bleibt dieselbe. STK500-Besitzer schrieb: > bei RS485 (da > byteweise orrienteriert) frühestens, wenn man seine eigenes Byte > eingelesen hat. Oder eben auch nicht - schließlich arbeiten die RS485 Treiber ggf. einfach gegeneinander - je nachdem, welcher der "Stärkere" ist, kann, muss eine Kollision aber nicht zwangsläufig direkt zum Erkennnen eines Datenfehlers führen. Bei CAN-Hardware ist sicher, daß eine 0 eine 1 dominiert.
:
Bearbeitet durch User
Michael K. schrieb: > Ich bin mir daher nicht sicher ob ein Can Transceiver dauerhaft > kurzschlussfest ist, wie ein RS485 Treiber. Bei CAN kann es keine Kurzschlüsse geben. > Weswegen also einen Can Transceiver für etwas benutzen für das ein RS485 > Transceiver voll durchspezifiziert ist? Und das wäre was ? Michael K. schrieb: > RS484 ist sehr viel älter als Can und trotz der schicken Funktionen > eines Can Controllers immer noch ein sehr guter und einfacher Bus. > Man muss nicht bei jeder 0815 Anwendung seine eigenen Kreationen da > reinbringen wenn das schon 100mal sehr robust gelöst wurde. RS485 ist ganz einfach nicht darauf ausgelegt, Buskollisionen zuver- lässig zu erkennen und zu behandeln. Deswegen schrieb ich auch, dass RS485 nicht für Multimaster Systeme geeignet ist. RS485 schreibt nur die Hardware vor, CAN dagegen Hard- und Software Layer. Aber niemand wird gezwungen, beide CAN-Layer zu benutzen, ist das so schwer zu verstehen ?
:
Bearbeitet durch User
Marc V. schrieb: > RS485 ist ganz einfach nicht darauf ausgelegt, Buskollisionen zuver- > lässig zu erkennen und zu behandeln. Muss er auch nicht. CRC und neu Übertragen wenns nicht angekommen ist, reicht meist vollkommen aus. > Deswegen schrieb ich auch, dass RS485 nicht für Multimaster Systeme > geeignet ist. Stimmt, es geht, ist aber unnötig aufwendig wenn man statt dessen einfach Can nehmen kann der das viel ausgefuchster in Hardware macht. Die Notwendigkeit eines Multimaster Systems ist aber auch nur ausgesprochen selten gegeben. Worauf wollen wir hier aber eigentlich hinaus? Beide Busse haben ihre Vorteil, beide werden rege benutzt, beide erledigen ihren Job hervorragend. Statt 'mein Bus ist aber besser als deiner' kann man auch einfach einen davon benutzen und damit glücklich werden. Brauche ich die Funktionalitär von Can, dann nehme ich Can. Brauche ich eine simple gepollte Master / Slave Übertragung ohne viel Schickimicki ist RS485 ein prima Bus. Für anderes ist I²C, SPI oder 1wire vielleicht die richtige Wahl.
Michael K. schrieb: > Worauf wollen wir hier aber eigentlich hinaus? > Beide Busse haben ihre Vorteil, beide werden rege benutzt, beide > erledigen ihren Job hervorragend. Ja, nur sehe ich keine Vorteile von RS485 gegenüber CAN, ausser vielleicht grössere Rechweite. Aber wer arbeitet schon mit Längen über 200m ? > Statt 'mein Bus ist aber besser als deiner' kann man auch einfach einen > davon benutzen und damit glücklich werden. Selbstverständlich.
Michael K. schrieb: > ich I too. Letztens ist mir wieder ein SUKONET K (eins der vielen RS485 Protokolle) unters Läptop gekommen. Länge etwas über 800m, erstreckt sich über 4 Gebäude.
Michael K. schrieb: > Marc V. schrieb: >> Aber wer arbeitet schon mit Längen über 200m ? > Viele, ich ... Arduino Fanboy D. schrieb: > Michael K. schrieb: >> ich > I too. > > Letztens ist mir wieder ein SUKONET K (eins der vielen RS485 Protokolle) > unters Läptop gekommen. > Länge etwas über 800m, erstreckt sich über 4 Gebäude. Ahem.
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.