Hallo,
Ich hab ein Testaufbau von einem RS 485 (SN75176) und MCP2551 gemacht
und wollte euch an die Ergnisse teilhaben.
Die ICs wurden auf einem Steckbrett aufgebaut und verbunden wurden sie
mit CAT5 Kabel, 500m.
Einmal mit 1Paar (1km) und 2Paar(2km) verbunden.
Sender und Empfänger ist jeweils der PC an einer RS232 Schnittstelle mit
MAX232.
Mich hat interessiert warum ich bei mein CAN Aufbau immer mal wieder
Probleme hatte.
Beim Can hatte ich bei 1km max 40kbaud hinbekommen, wobei ich nur die
Senderseite mit 120 Ohm terminieren durfte, da sonst der differenz Pegel
beim Empfänger zu gering war.
Beim alten SN75176 kann ich bei 1km etwa 450kbaud ohne Fehler
übertragen(nach 30min und etwa 60 000x teststring kein Fehler).
Bei 2km kann ich noch bis 170kBaud fehlerfrei Übertragen.
Um ein härteres Umfeld zu simulieren habe ich dann, bei den 2 freien
Adernpaare (bei 1km)
, ein bis 0.1kHz-2MHz Signal(Rechteck) draufgegeben, etwa 2-10Vss, mit
fest angeschlossender Abschirmung auf Masse und jeweils 120 Ohm
Abschlusswiderstand sowie 390 Ohm zu VCC nach A und GND nach B, gab es
keine Fehler.
Wurde ein Widerstand oder die Abschiermung unterbrochen, entstanden
sofort Übertragungsfehler.
Vielleicht helfen diese Messungen einen ja.
Ich komme nun zu den Schluß das CAN nur sinnvoll ist bei kurzen Strecken
und einem Multibussystem(<100meter). RS485 muss man sich das Protokol
selber Schreiben aber bei meinem Testaufbau habe ich ein
Interruptverfahren wo das Senden per IRQ an/abgeschaltet wird.Ist aber
noch im Aufbau.
Hat einer ein ähnliche Verhalten festgestellt?
@ Peter (Gast)
>Ich hab ein Testaufbau von einem RS 485 (SN75176) und MCP2551 gemacht>und wollte euch an die Ergnisse teilhaben.
Kann es sein, dass du CAN und RS485 zusammenwürfelst? Das ist NICHT das
Gleiche und auch nicht kompatibel. Mach es richtig und nimm einen
CAN-Tranceiver.
>Wurde ein Widerstand oder die Abschiermung unterbrochen, entstanden>sofort Übertragungsfehler.
Logisch, bei der Leitungslänge braucht man zwingend eine Terminierung,
siehe Wellenwiderstand. Ausserdem ist dein Mischmasch aus RS485 und
CAN Murks.
>Ich komme nun zu den Schluß das CAN nur sinnvoll ist bei kurzen Strecken>und einem Multibussystem(<100meter).
CAN hat eine sehr enge Prüfung bei der Übertragung eines einzelnen Bits,
da spielen Signallaufzeiten eine Rolle. Allso kommt man bei hohen
Bitraten nicht sehr weit. Ein 0815 UART über RS485 kommt da deutlich
weiter bei gleicher Bitrate, hat dann aber nicht die Sicherung der
Übertragung auf Bitebene.
Vielen Dank für deine Antwort.
Mir gings nur allein um die Bitebente ohne irgendeiner Protokolierung
und Schutzverhalten vom CAN.
Ich habe bei einem Testaufbau von einer Haupteinheit und 5 Nebengeräten
gemerkt das ich bei 100m ziemliche Probleme habe bei Datensicherheiten.
Eine Nebenstelle hat bei der Haupteinheit etwas angefordert, diese
anforderung kam aber nie an. Leider ist das sehr sporadisch und lässt
sich nicht weiter Untersuchen.
Bei meinem Test ging es nur allein darum wie gut die Ausgangstreiber von
den beiden ICs sind.
Mir ist klar das CAN und RS485 ein Unterschied ist, aber mir scheint CAN
für wesentlich kürzere Strecken gedacht zu sein als RS485.
Da fällt mir noch ein, ich habe vergessen zu erwähnen.
Der Aufbau ist immer 2x MCP2551 oder 2x SN75176 geschehen.
Also der erste MCP bekam Daten die der 2. MCP empfangen hat und der UART
an den Reciver gegeben hat.
Gleicher Aufbau nur mit SN75176 und dann ebent die Geschwindigkeit und
die Kabellängen variiert um zu schauen wie schnell/lang die Geschichte
sein darf um brauchbare Daten aus den Entstufen zu erhalten.
Peter schrieb:> Mir ist klar das CAN und RS485 ein Unterschied ist, aber mir scheint CAN>> für wesentlich kürzere Strecken gedacht zu sein als RS485.
CAN wurde von Bosch für den Einsatz im Automobil entwickelt, eingestzt
erstmals in der Mercedes S-Klasse W140. Entsprechend brauchte man keine
Kabellängen.
CAN hat vielen Vorteilen gegenüber RS485, auch wenn es nicht immer
ersichtlich ist.
Lese mal die App Note AN96116 von Phillips. Darin wird die "Physical
Layer" erklärt
hth
PICfan
Hi,
aus meiner Erfahrung ist eine Datenübertragung über 1km mit
Kupferleitung (Rs485, RS422) auch bei 9600 Baud absolut Störanfällig
wenn nicht gar unmögklich. Bei höheren Übertragungsraten (z.B. Profibus
mit Rs485 (standard) und 19,2MBit/s) ist auch schon nach ca 150m ein
Repeater erforderlich. Wir setzen als Übertragungsmedium für
Entfernungen bis 3km Glasfaser ein. Darüberhinaus werden Daten nur noch
über Ethernet (WLan, Internet, Telefonstandleitung, etc) übertragen.
Die CAN-Physik bringt nur was in Verbindung mit dem CAN-Protokoll und da
nur auf geringer Entfernung, da sie dafür entwickelt wurde. Ein
wesentlicher Aspekt des CAN- Bus ist die Verteilung der Betriebsspannung
gkeichzeitig mit den Busdaten. Nach 2km Kupfer bleibt von der
Betriebsspanung nicht mehr viel übrig.
Hambone
Ich habe bei einem Projekt massive Probleme gehabt, der Kunde forderte
250m Kabellänge.
Ich hatte bei der Entwicklung auch das Problem gehabt das Message beim
Can einfach verloren gegannen sind, daher schau ich mir nun die RS485
geschichte näher an.
Zuwas würdet ihr den Raten, wenn längen von 300m vorkommen für ein
einfaches Bussystem mit max 10xBytes pro sek für 5 Module?
@ Peter (Gast)
>Ich habe bei einem Projekt massive Probleme gehabt, der Kunde forderte>250m Kabellänge.
Und?
>Ich hatte bei der Entwicklung auch das Problem gehabt das Message beim>Can einfach verloren gegannen sind,
Glaub ich nicht. Dann ist massiv was faul. Oder die Implementierung der
CAN-Treiber schlampig, denn die müssen so einen Fehler im Controller
erkennen und melden. Und dass die Controller nicht normgerecht arbeiten
ist praktisch ausgeschlossen.
> daher schau ich mir nun die RS485 geschichte näher an.
Ist nicht besser.
>Zuwas würdet ihr den Raten, wenn längen von 300m vorkommen für ein>einfaches Bussystem mit max 10xBytes pro sek für 5 Module?
CAN. Man muss ja nicht mit 1MBit/s fahren, 125kbit/s reichen auch, ggf
weniger. Einfacher uns sicherer bekommt man keine Daten über so ein
Kabel.
http://de.wikipedia.org/wiki/Controller_Area_Network#.C3.9Cbertragungsrate_und_Leitungsl.C3.A4nge
