Forum: Mikrocontroller und Digitale Elektronik RS485 galvanische Trennung?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Manuel R. (dude123)


Bewertung
1 lesenswert
nicht lesenswert
Hallo zusammen,

ich möchte für eine Hausautomatisierung auf RS485 zurückgreifen und das 
ganze mit CAT5 Kabel verdrahten.

Die freien 4 Adern möchte ich für eine 24V Versorgung für die Slaves 
verwenden (mit Step-Down an jedem Slave). Pro Slave rechne ich mit P < 
1W.

Trotz der hohen Versorgungsspannung muss ich bei meinen Leitungslängen 
mit Spannungsabfällen im Bereich 1-5V rechnen. D.h. die GNDs der Slaves 
(und damit auch die RS485 Transceiver) liegen dann um diese Spannung 
über dem GND des Masters.

Nun meine Frage:
Würdet ihr das trotzdem noch mit normalen RS485 Transceivern machen 
(laut Datenblatt müssen sie ja einen CM-Bereich von -7V bis +12V 
vertragen)?

Oder wäre es sinnvoller auf galvanisch getrennte RS485 Slaves zu gehen 
(auf Kosten der Komplexität)?


Viele Grüße,
Manuel

von Gerhard O. (gerhard_)


Bewertung
2 lesenswert
nicht lesenswert
Manuel R. schrieb:
> Hallo zusammen,
>
> ich möchte für eine Hausautomatisierung auf RS485 zurückgreifen und das
> ganze mit CAT5 Kabel verdrahten.
>
> Die freien 4 Adern möchte ich für eine 24V Versorgung für die Slaves
> verwenden (mit Step-Down an jedem Slave). Pro Slave rechne ich mit P <
> 1W.
>
> Trotz der hohen Versorgungsspannung muss ich bei meinen Leitungslängen
> mit Spannungsabfällen im Bereich 1-5V rechnen. D.h. die GNDs der Slaves
> (und damit auch die RS485 Transceiver) liegen dann um diese Spannung
> über dem GND des Masters.
>
> Nun meine Frage:
> Würdet ihr das trotzdem noch mit normalen RS485 Transceivern machen
> (laut Datenblatt müssen sie ja einen CM-Bereich von -7V bis +12V
> vertragen)?
>
> Oder wäre es sinnvoller auf galvanisch getrennte RS485 Slaves zu gehen
> (auf Kosten der Komplexität)?
>
> Viele Grüße,
> Manuel

Je nach RS485 Transceivertyp sind üblicherweise Common Mode 
Spannungsabfälle bis zu +12 bis zu - 7V zulässig. Da machen Deine 
Stromversorgungsspannungsabfälle weitgehend nichts aus. Galvanische 
Trennung ist bestimmt nicht notwendig wenn Du innerhalb der vorgegebenen 
Grenzen bleibst.

Siehe auch hier:
https://ecee.colorado.edu/~mcclurel/max485ds.pdf

"-7V to +12V Common-Mode Input Voltage Range" - Seite 1

Ausprobieren halt.

Bevor ich es vergesse: Nimm einen Slew Rate begrenzten Transceiver wie 
den MAX483 o.ae. 10Mbit Transceiver machen nur Probleme.

: Bearbeitet durch User
von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Manuel R. schrieb:
> ich möchte für eine Hausautomatisierung auf RS485 zurückgreifen und das
> ganze mit CAT5 Kabel verdrahten.
> Die freien 4 Adern möchte ich für eine 24V Versorgung für die Slaves
> verwenden (mit Step-Down an jedem Slave).
Such dir eine Belegung aus, bei der der Netzwerktrafo deines Laptops 
nicht kaputtgeht, wenn du ihn mal zufällig an dieses "Netzwerk" 
anschließt. Denn das ist die Gefahr bei Buchsen, die weltweit vorrangig 
für eine ganz bestimmten Sache verwendet werden: keiner rechnet damit, 
dass da was ganz anderes rauskommen könnte.

> Trotz der hohen Versorgungsspannung muss ich bei meinen Leitungslängen
> mit Spannungsabfällen im Bereich 1-5V rechnen.
Du solltest da übrigens unbedingt auch die vielen Übergangswiderstände 
in den vielen Steckverbindungen berücksichtigen...

von fchk (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Manuel R. schrieb:
> Hallo zusammen,
>
> ich möchte für eine Hausautomatisierung auf RS485 zurückgreifen und das
> ganze mit CAT5 Kabel verdrahten.
>
> Die freien 4 Adern möchte ich für eine 24V Versorgung für die Slaves
> verwenden (mit Step-Down an jedem Slave). Pro Slave rechne ich mit P <
> 1W.
>
> Trotz der hohen Versorgungsspannung muss ich bei meinen Leitungslängen
> mit Spannungsabfällen im Bereich 1-5V rechnen. D.h. die GNDs der Slaves
> (und damit auch die RS485 Transceiver) liegen dann um diese Spannung
> über dem GND des Masters.

1. Nimm 48V, wie es sonst überall (PoE, ISDN,...) gemacht wird. Damit 
kannst Du mehr Leistung übertragen, und die Verlustleitung viertelt 
sich.

2. Wenn Du Power GND und Signal GND trennst, hast Du das Problem nicht 
mehr. Signal GND ist die Referenz für den Bus, und hier wirst Du kaum 
nennenswerte Ströme haben. Und für die Stromversorgung nimmst Du 
isolierte DC-DC-Wandler. Exemplare mit Eingangsspannungen von 36-72V und 
Ausgangsspannung 5V gibts genügend. Der Spannungsabfall auf Power GND 
spielt dann keine große Rolle mehr.

fchk

von Peter D. (peda)


Bewertung
3 lesenswert
nicht lesenswert
Ich würde für neue Projekte CAN bevorzugen. Der Master muß dann die 
Slaves nicht mehr pollen, sondern sie können antworten, wann ihnen 
danach ist.
Die CAN-Hardware kümmert sich automatisch darum, daß Kollisionen 
aufgelöst und Fehler korrigiert werden. Die Firmware wird also erheblich 
einfacher und die Übertragung sicherer.

Kämpfen 2 RS-485 Transceiver gegeneinander, können bei hohen 
Leitungswiderständen beide MCs der Meinung sein, daß sie erfolgreich 
gesendet haben.

von Bauform B. (bauformb)


Bewertung
1 lesenswert
nicht lesenswert
fchk schrieb:
> für die Stromversorgung nimmst Du isolierte DC-DC-Wandler.
> Exemplare mit Eingangsspannungen von 36-72V und
> Ausgangsspannung 5V gibts genügend.

Durch den großen Eingangsspannungsbereich muss die zentrale Versorgung 
nicht geregelt sein. Ich würde wahrscheinlich 
Ringkerntrafo/Gleichrichter/Elko verwenden; hält 100 Jahre, im Gegensatz 
zu billigen Schaltnetzteilen.

Bonus: wenn ein Step-Down defekt wird, kommen evt. 48 statt 5 Volt raus. 
Bei einem getrennten Wandler ist das eher unwahrscheinlich.


Lothar M. schrieb:
> Du solltest da übrigens unbedingt auch die vielen Übergangswiderstände
> in den vielen Steckverbindungen berücksichtigen...

Sooo viele sollten in einer Hausinstallation nicht vorkommen. Klar, 
einer pro Slave, aber da geht auch nur "ein Strom" drüber.


Lothar M. schrieb:
>> Die freien 4 Adern möchte ich für eine 24V Versorgung für die Slaves
>> verwenden (mit Step-Down an jedem Slave).
> Such dir eine Belegung aus, bei der der Netzwerktrafo deines Laptops
> nicht kaputtgeht, wenn du ihn mal zufällig an dieses "Netzwerk"
> anschließt.

Wäre GND auf 7 und 8, Plus auf 4 und 5 in Ordnung?


Peter D. schrieb:
> Ich würde für neue Projekte CAN bevorzugen.

Normale CAN-Tranceiver können nur -2 bis +7V common mode. Die SN65HVD233 
schaffen -7 bis +12V und vertragen ±100V Transienten und Kurzschlüsse 
gegen 24V. Mit Kabeln quer durchs Haus ist das durchaus ein Argument.

Das bringt uns zum SN65HVD1785, der verträgt auch Kurzschlüsse gegen 48V 
und kann -20 bis +25V common mode. Damit wäre die ursprüngliche Frage 
auch beantwortet.

: Bearbeitet durch User
von fchk (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bauform B. schrieb:
> Das bringt uns zum SN65HVD1785, der verträgt auch Kurzschlüsse gegen 48V
> und kann -20 bis +25V common mode. Damit wäre die ursprüngliche Frage
> auch beantwortet.

Da ja eh 5V vorhanden sind, kann man auch zu einem MAX13054 greifen, der 
+-80V an den Busleitungen verträgt.

fchk

von Peter D. (peda)


Bewertung
3 lesenswert
nicht lesenswert
Bauform B. schrieb:
> Normale CAN-Tranceiver können nur -2 bis +7V common mode.

TJA1050:
Common Mode: +/-12V
Max: -27V/+40V, no time limit
Transient: +/-200V
ESD (HBM): +/-4000V
An unpowered node does not disturb the bus lines.

https://www.nxp.com/docs/en/data-sheet/TJA1050.pdf

Manuel R. schrieb:
> Trotz der hohen Versorgungsspannung muss ich bei meinen Leitungslängen
> mit Spannungsabfällen im Bereich 1-5V rechnen.

Sind also auch für CAN kein Problem.

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Der Master muß dann die
> Slaves nicht mehr pollen, sondern sie können antworten, wann ihnen
> danach ist.

Das macht aber die Programmierung für einen Anfänger nicht unbedingt 
einfacher.

Georg

von H.Joachim S. (crazyhorse)


Bewertung
3 lesenswert
nicht lesenswert
georg schrieb:
> Das macht aber die Programmierung für einen Anfänger nicht unbedingt
> einfacher.

Doch.

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
H.Joachim S. schrieb:
> georg schrieb:
>> Das macht aber die Programmierung für einen Anfänger nicht unbedingt
>> einfacher.
>
> Doch.

Nein, wirklich nicht. Zähl einfach mal die Bits, die im CAN-Controller 
richtig gesetzt werden müssen und vergleiche mit einem UART. Von der 
Beschreibung ganz abgesehen: welche 10% der Funktionen braucht man 
eigentlich?

Allerdings verursacht CAN wesentlich weniger Umweltverschmutzung als 
Pollen, gerade in dieser Anwendung. Wie oft muss ein Lichtschalter sich 
melden? Und dann der Stromverbrauch: die Abschlusswiderstände brauchen 
bei RS-485 dauernd Strom, die bei CAN brauchen genauso viel, aber nur, 
wenn jemand sendet! Jedes Milliwatt zählt ;)

von Peter D. (peda)


Bewertung
1 lesenswert
nicht lesenswert
georg schrieb:
> Das macht aber die Programmierung für einen Anfänger nicht unbedingt
> einfacher.

Der Master schickt z.B. 3 Anfragen an 3 Slaves. Und irgendwann hat er 3 
Interrupts gekriegt und es stehen die 3 Antworten in 3 Empfangpuffern, 
ohne jedes Zutun. Er muß sie nur noch auswerten und die Empfangspuffer 
wieder freigeben.
Sich mit Kollision, Timeout, Retry, CRC usw. rumärgern war gestern.

von Andi B. (andi_b2)


Bewertung
0 lesenswert
nicht lesenswert
Zur ewigen Diskussion CAN versus RS485 - bei langen Leitungen die auch 
mal Stiche oder Stich am Stich verdrahtet sind, tut man sich mit slew 
rate limited RS485 viel leichter als mit CAN. Also in diesem 
Anwendungsfall ist kann schon RS485 besser geeignet sein. RS485 braucht 
im Gegensatz zu CAN keine niederohmigen Abschlusswiderstände. Die 
hochohmigen in den Treibern bzw. zusätzlich einer irgendwo, reichen.

Bei RS485 kann man auch je nach belieben extern noch die slew rate 
verringern um auch bei mega lange Leitungen und Abzweigen keine 
nennenswerten Reflexionen zu bekommen. Wer mal versucht hat bei CAN die 
slew rate extern einzustellen weiß, dass geht nicht gut mit den 
niederohmigen CAN Abschlusswiderständen. Und CAN Treiber mit slew rate 
Einstellung sind leider sehr selten.

@Manuel R. - ich weiß nicht wie du auf die 1-5V Spannungsabfall kommst. 
Aber da würd ich mir mit RS485 keine Sorgen machen. Die -7 - +12V die 
reichen da. Mehr wäre natürlich gut. Die vorgeschlagenen 
Alternativbausteine mit höherem CM würde ich mir auf jeden Fall ansehen.

Als Belegung würde ich 1/2 und 6/8 für die Versorgungsleitungen nehmen 
und 4/5 für RS485. Wenn du auf "fälschlich LAN anstecken" keine 
Rücksicht nehmen musst, kannst auch 1-3 und 5-8 für die Versorgung 
nehmen.

Die Anzahl deiner Teilnehmer und warum die nicht viel weniger als 1W 
brauchen sollen, wären auch noch interessant.

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Der Master schickt z.B. 3 Anfragen an 3 Slaves

Das ist ja auch nicht das Problem, das ist genauso Master-Slave wie bei 
RS485 usw. Aber er muss ja auch jederzeit auf Messages reagieren die er 
nicht veranlasst hat - jedenfalls theoretisch.

Georg

von Hannes J. (Firma: _⌨_) (pnuebergang)


Bewertung
0 lesenswert
nicht lesenswert
Bauform B. schrieb:
> Ich würde wahrscheinlich
> Ringkerntrafo/Gleichrichter/Elko verwenden; hält 100 Jahre, im Gegensatz
> zu billigen Schaltnetzteilen.

Das ist ein bisschen schwer auf eine Hutschiene zu bekommen wie sie 
gerne bei Hausinstallationen genommen werden. Innerhalb von 100 Jahren 
wird bei den heutigen Elkos auch der ein oder andere Elko-Wechsel 
fällig.

Das Netzteil muss ja nur ähnlich lang halten wie der Rest der RS485 
Haussteuerung. Der gebe ich keine 100 Jahre. Daher würde ich mir ein 
Hutschienen-Schaltnetzteil aussuchen. Wenn es nicht zu teuer sein soll 
was passendes von MeanWell. Die haben eine ziemlich breite Auswahl und 
sind nicht ganz schlecht.

von CAN_Nutzer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich hab einen 25kbit CAN schon über 400m und mit >über 150m 
Stichleitungen aufgebaut. Überhaupt kein Problem.

von Andi B. (andi_b2)


Bewertung
0 lesenswert
nicht lesenswert
CAN_Nutzer schrieb:
> Ich hab einen 25kbit CAN schon über 400m und mit >über 150m
> Stichleitungen aufgebaut. Überhaupt kein Problem.

400m und >150m StichleitungEN? Kannst du das mal aufzeichnen?

Wenn du in deinem speziellen Aufbau "kein Problem" mit Reflexionen 
hattest, bzw. diese vielleicht gar nicht an den entsprechenden Stellen 
gemessen hast, hilft das dem TO wahrscheinlich nicht viel.

Das Stichleitungen mit den bei CAN obligatorischen Abschlusswiderständen 
am Anfang und am Ende nicht gut zusammengehen, sollte dir schon klar 
sein, oder? Aber vielleicht hat ja der TO diese gar nicht....

von CAN_Nutzer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
250m Hauptleitung vom Master zum letzten Sensor, dazwischen 10 
Abzweigungen mit je 15m zur Hauptleitung. Terminiert war der Master und 
der letzte Slave. Die Buslast war nie über 15%, aber mehr ist bei 
Hausautomatisierung auch nicht zu erwarten

von Manuel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Andi B.
Ich rechne mit < 10 Teilnehmern.
Die Last ist so klein, weil es meist nur Sensoren etc. sind.
Der Spannungsabfall ergibt sich aus dem DC Widerstand der Leitung und 
Übergangswiderständen.

@alle
Danke für die zahlreichen Tipps, wie immer sehr hilfreich.

Da ich kein Multimaster plane, bleibe ich lieber bei RS485.

Das mit dem Stromverbrauch durch den Nullpegel ist tatsächlich ein Punkt 
(hat mich überrascht, als ich das bei der ersten Inbetriebnahme gesehen 
habe).
Um das zu vermeiden plane ich die Transmitter bei Inaktkvität 
ausschalten, damit ist es dann vergleichbar zu CAN. Oder spricht da 
etwas dagegen?

Noch eine Frage zum Thema Stichleitungen. Wieviel Meter sind bei 
115kbit/s und slew rate Limitierung denn akzeptabel?

Viele Grüße,
Manuel

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Bauform B. schrieb:
> Zähl einfach mal die Bits, die im CAN-Controller
> richtig gesetzt werden müssen und vergleiche mit einem UART.

Nur ist eine UART einfach nur ein Schieberegister, das ein Byte senden 
oder empfangen kann. Zu einer sicheren Datenübertragung ist es dann noch 
ein ganz weiter und steiniger Weg. Anfänger unterschätzen oft den 
nötigen Aufwand für ein zuverlässiges Protokoll.
RS-485 würde ich nicht für viel Geld programmieren wollen.

Bei CAN schreibt man ganz einfach Adresse + Daten in ein Messageobjekt 
und setzt das Sendebit. Der andere Teilnehmer kriegt einen 
Empfangsinterrupt und liest die Daten aus einem Messageobjekt. Fertig.

: Bearbeitet durch User
von Andi B. (andi_b2)


Bewertung
0 lesenswert
nicht lesenswert
Manuel schrieb:
> Noch eine Frage zum Thema Stichleitungen. Wieviel Meter sind bei
> 115kbit/s und slew rate Limitierung denn akzeptabel?

Mit z.B. MAX3082 oder MAX3072 (weiß nicht mehr genau mit welchem ich 
getestet hab) insgesamt >>100m. Stiche völlig egal. Ohne extra 
Abschlusswiderstände. Leichte Verzugswiderstände sind ev. 
empfehlenswert. Aber CRC und ein Protokoll welches Störungen 
unterdrückt, sind sowieso obligatorisch.

Nur so als grober Anhaltspunkt -> 5ns/m Ausbreitungsgeschwindigkeit, auf 
100m Hin- und 100m Rückleitung würde die erste Reflexion, wenn's eine 
nennenswerte geben würde, nach ca. 1us ankommen. Also weit früher als 
das einen typischen UART bei 115200 auch nur kratzen würde. Aber mit 
slew rate limited Treiber, wirst wohl da kaum eine messen können.

5V Spannungsabfall - 0,4A bei 10x1W, da die Teilnehmer ja nicht alle am 
Ende der Leitung sitzen sondern eher gleich verteilt, denke ich du 
rechnest mit > 200m. (AWG24 = CAT5 = < 90 Ohm/km bei zwei Adern je 
Versorgung also nur 1x zu rechnen, bei 3 Adern wär's noch besser), 
korrekt? Aber warum ein Teilnehmer 1W verbraten soll, verstehe ich 
nicht. Der sollte doch eher schlafen. Selbst mit einem einfachen 
hintergrundbeleuchtetem Display, darf der nicht mehr als 0,1 - 0,25W 
verbrauchen (PIC24 mit 128x64 Display ohne sleep mode, ein EFM32 kann 
das viel besser und ohne Hintergrundbeleuchtung sowieso). Ich denke da 
hast du einige Reserven eingerechnet.

Nochmal zu den CAN Fanatikern - der physical layer von CAN ist für sowas 
nicht wirklich gut geeignet. Erklärung siehe oben. Und die CAN Treiber 
die slew rate einstellbar sind, haben üblicherweise wieder kein 3V3 
Interface. Also entweder 5V uC oder nochmal level shifter dazu. Und 
Strom saufen die auch ganz schon. Für sowas nimmt nur jemand CAN, wenn 
er nichts anderes kennt bzw. unbedingt einen uC einsetzen will, der eh 
schon CAN integriert hat. Da kommen wir zum 2. Nachteil von CAN in 
dieser Anwendung, begrenzte Controllerauswahl. Ein UART hat fast jeder, 
CAN nur die teureren komplexeren, und nicht sehr effizienten. Aber wenn 
man so einen uC kennt und beherrscht, den Preis und Stromverbrauch 
akzeptieren kann, dann ist CAN schon eine feine Sache. Aber eher für 
kürzere Kabel und wo man die Busstruktur einigermaßen einhalten kann.

von Andi B. (andi_b2)


Bewertung
0 lesenswert
nicht lesenswert
Btw. das der Transmitter beim RS485 nach dem Senden den letzten Bytes 
deaktiviert wird, sollte klar sein. Das können die meisten Controller 
automatisch mit CTS gesteuert. Und wie gesagt, bei RS485 (fail safe und 
slew rate limited Treiber, deiner Geschwindigkeit und <100m pro 
Einzelstich) brauchst gar keinen extra Abschlusswiderstände. Da baue ich 
eher ~10k Verzugswiderstände am Master, gegen Störungen in den 
Kommunikationspausen, ein.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Andi B. schrieb:
> Nochmal zu den CAN Fanatikern - der physical layer von CAN ist für sowas
> nicht wirklich gut geeignet.

Nö, die CAN-Entwickler waren ja nicht dumm. Oftmals sehe ich beim 
Kunden, daß nur auf einer Seite ein Terminator steckt, weil es läuft ja.

Mit Fanatismus hat das nichts zu tun, sondern wieviel Mannjahre Manuel 
für die Entwicklung des RS-485 Stacks opfern will. Nicht umsonst 
benötigen fertige RS-485 Stacks viele kB an Flash und einem Anfänger 
fällt es schwer, sie zu verstehen.

Natürlich bastelt sich keiner einen CAN-MC selber. Z.B. der AT90CAN128 
wird gerne genommen und ist gut verfügbar. Mit 15 MOBs kann der ne Menge 
Nachrichten puffern. Man kann also durchaus den CAN-Interrupt längere 
Zeit sperren, ohne daß es kracht. Eine UART mit 3 Byte Puffer ist 
dagegen ein Witz.
Ein CAN Slave muß auch nicht ständig auf dem Sprung sein, ob der Master 
ihm einen Sendeslot freigibt. Er nimmt sich ihn, sobald er Lust dazu 
hat. Die zeitliche Abfolge spielt bei CAN einfach keine Rolle.

Aber es bleibt jedem natürlich selbst überlassen, wie schwer er sich die 
Programmierarbeit machen möchte.
Man kann auch Bestückungsoptionen mit RS-485 und CAN vorsehen. Und wenn 
man dann von RS-485 Aussetzern die Nase voll hat, auf CAN umschwenken.

von Andi B. (andi_b2)


Bewertung
0 lesenswert
nicht lesenswert
@ Peter D. - vielleicht solltest du auch mal versuchen den pyhsical 
layer etwas genauer zu betrachten. Du würdest du vielleicht auch 
draufkommen, CAN ist z.B. für Stichleitungen nicht gut geeignet.

Ich denke ich hab das oben schon differenzierter dargelegt. Es hilft nix 
wenn du immer auf der Stelle verharrst und nur auf den Vorteil der 
einfacheren Integration in dein SW-Framework verweist. Es gibt viele 
Gründe warum man nicht überall CAN nehmen kann und soll (gilt genauso 
für jedes andere Übertragungsverfahren).

Übrigens, nicht nur die CAN Entwickler waren nicht dumm. Viele andere 
Entwickler waren und sind es auch nicht.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Andi B. schrieb:
> CAN ist z.B. für Stichleitungen nicht gut geeignet.

Man sollte vielleicht nicht gerade eine Sterntopologie aufbauen, aber 
Stichleitungen sind kein Problem. Man darf ruhig die Baudrate 
runtersetzen, wenn es Reflexionen gibt.
Da immer einer die Arbitration gewinnt, darf CAN bis nahe 100% Buslast 
arbeiten. Es sind keine zusätzlichen Wartezeiten notwendig, wo der eine 
Sender abschaltet und bis der andere Sender anfängt.

Wir hatten schon mehrfach Geräte mit RS-485, bei denen man zusätzliche 
Wartezeiten einlegen mußte. Manche verschluckten nur Pakete, manche 
stürzten komplett ab. Der Master muß also zusätzlich Däumchen drehen, 
damit es funktioniert. Jeder SW-Entwickler haßt solche Protokolle, die 
mit Wartezeiten arbeiten. Oft sind diese Wartezeiten nicht dokumentiert 
oder nur durch mehrfaches Nachfragen zu erfahren. Manchmal wird auch 
stur geleugnet, daß der RS-485 Stack buggy ist und es hilft nur 
Trial&Error. Dann war das auch das letzte Gerät, was wir bei diesem 
Hersteller gekauft haben.
Unsere Erfahrungen mit RS-485 sind daher gelinde gesagt gemischt, ganz 
im Gegensatz zu CAN.
Daß bei CAN alles kritische schon die Hardware macht, ist doch ein 
großer Vorteil und läßt wenig Spielraum für SW-Bugs.

: Bearbeitet durch User
von Andi B. (andi_b2)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Man sollte vielleicht nicht gerade eine Sterntopologie aufbauen, aber
> Stichleitungen sind kein Problem. Man darf ruhig die Baudrate
> runtersetzen, wenn es Reflexionen gibt.

Was aber nicht die Reflexionen verringert, sondern nur soweit kaschiert, 
dass sie ev. nicht mehr so auffällig und direkt die Kommunikation 
stören. Das ist genauso Pfusch wie die SW die du in einigen Geräten 
kritisierst, die du offenbar von irgendwen zugekauft hast.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Andi B. schrieb:
> Das ist genauso Pfusch

CAN benutzt wie die UART eine 3-Fach Abtastung in der Mitte der Bitzeit. 
Wenn man die Baudrate so wählt, daß dann die Reflexionen abgeklungen 
sind, ist das kein Pfusch. Man kann aber auch die Abtastzeitpunkte näher 
am Ende der Bitzeit wählen.

von Andi B. (andi_b2)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Andi B. schrieb:
>> Das ist genauso Pfusch
>
> CAN benutzt wie die UART eine 3-Fach Abtastung in der Mitte der Bitzeit.
> Wenn man die Baudrate so wählt, daß dann die Reflexionen abgeklungen
> sind, ist das kein Pfusch. Man kann aber auch die Abtastzeitpunkte näher
> am Ende der Bitzeit wählen.

Du hast offensichtlich den Sinn von "slew rate limited" und die Physik 
dazu bezüglich Reflexionen noch immer nicht verstanden. Es geht nicht 
darum nach den Reflexionen zu bewerten, sondern erst gar keine entstehen 
zu lassen.

Ich schreib mir hier schon die Fingern wund um verständlich darzulegen, 
dass slew rate begrenzen bei CAN nicht so einfach ist und deshalb das 
verhindern von Reflexionen mit z.B. RS485 vieeeel einfacher geht. Aber 
offensichtlich ohne Erfolg :-(

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Andi B. schrieb:
> Es geht nicht
> darum nach den Reflexionen zu bewerten, sondern erst gar keine entstehen
> zu lassen.

Wer schreibt denn sowas vor?
Es reicht völlig, wenn die Verbindung zuverlässig ist und die Datenrate 
ausreichend. Immer nur so gut wie nötig entwickeln und nicht wie maximal 
möglich.
Auch bei den alten PCA82C251 habe ich den Widerstand für Slope control 
immer auf 0 Ohm gesetzt und keine Probleme mit CE gehabt.

: Bearbeitet durch User
Beitrag #6420249 wurde vom Autor gelöscht.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.