Guten Abend,
Ich bin in der Arbeit dazu verdammt worden
Über eine ungeschirmte unverdrillte Leitung, Weine Kommunikation aufzubauen:-(, also eine normale H05VV, 7 Adern, RX, TX, 24V, 12V und jeweils GND
und der PE... Ja, ich weiß, macht man nicht, ist auch nich schön aber es es wurde was bestehendes Erweitert.
Im Ersten Versuch mit Simplen RS232 bei 38400 Baud
Auch erstmal problemlos, weniger als 0,1 Promille resend (ca 100 Telegramme bidirekrional pro Sekunde a 7 Byte)
Jetzt kam jemand aus der Nachbar Abteilung (Hardware) auf die Idee das CAN doch viel robuster ist.. Der Kollege hat aus meiner Sicht im Prinzip recht wenn man geeignete Kabel einsetzt.
Verpufft die Robustheit von Can nicht wenn man verdrillung und Schirm weglässt? Vorallem müssten man ja um die gleiche Datenrate zu schaffen ca. doppelt so schnell fahren wie bei RS232 weil es ja kein voll duplex ist... und keine Adern für 4draht ala RS422 frei sind,
Lieg ich da so falsch das es keinen Benefit bringt? Oder hat CAN hier doch Vorteile?
problemlos, weniger als 0,1 Promille resend (ca 100 Telegramme
bidirekrional pro Sekunde a 7 Byte)
0,0% nach Nachtlauf wäre für mich in Laborumgebung "problemlos".
Verpufft die Robustheit von Can nicht wenn man verdrillung und Schirm
weglässt?
Sie reduziert sich signifikant. Denn das Verdrillen bewirkt, dass sich eingekoppelte Gleichtaktstörungen an jedem "Schlag" auslöschen. Und dass ein Schirm Störungen reduziert ist eh' klar.
Bleibt also nur noch die differentielle Übertragung, der erweiterte Gleichtaktbereich des Empfängers und das automatische Wiederholen korrupter Telegramme als Vorteil für den CAN.
Vorallem müssten man ja um die gleiche Datenrate zu schaffen
ca. doppelt so schnell fahren wie bei RS232 weil es ja kein voll duplex
ist... und keine Adern für 4draht ala RS422 frei sind,
Das kommt drauf an, wie die Daten übertragen werden und wie die Richtungen dabei ausgelastet werden.
OK, vergessen zu schreiben, das Ding wurde gleich ins lebende Objekt eingebaut (montageanlage, ca 5 Meter Kabel zw. Sender und Empfänger, also nicht wirklich Labor.
Sorry das ich das nicht erwähnt hab :-(.
Danke für die Einschätzung, vllt überzeugt es ja :-) gemessen am Aufwand der Entwicklung sind die Benefits nicht signifikant.
Bei einer Punkt-zu-Punkt Verbindung bringt die CAN tatsächlich nicht allzuviel.
Was eine Überlegung wert wäre: die uralte 20mA-Stromschnittstelle (TTY). Bei der Entfernung und der Datenrate sehr sicher. Strom lässt sich schwerer stören als Spannungspegel :-)
Vorteil vor allem: es bleibt bei der primitiven UART, nur die physikalische Schnittstelle ändert sich ein wenig.
RS232 ist im gestörten Umfeld nicht so dolle, lässt sich aber bei Einsatz eines geigneten Protokolls durchaus verwenden wenn Übertragungszeitreserven vorhanden sind.
ca 5 Meter Kabel zw. Sender und Empfänger, also nicht wirklich Labor.
Ich würde mit einem Oszilloskop mal messen wie das Signal aussieht und welche Störungen da drauf sind und versuchen, die Fehler im normalen Betrieb auf 0 zu drücken.
Im Ersten Versuch mit Simplen RS232 bei 38400 Baud
(ca 100 Telegramme bidirekrional pro Sekunde a 7 Byte)
Also effektiv 100 x 7 x 8 Bit/s = 5600 Bits/s. "Bidirektional" macht die Sache eher unkritisch, weil dank getrennter RX und TX Leitungen gleichzeitig gesendet und empfangen werden kann. Da wären also schon 9600 Baud locker ausreichend. Und 9600/s sind einfacher zu entstören als 38400/s.
Du könntest RS232 durch RS485 ersetzen, dann hast du einen differentielle Übertragung wie bei CAN, brauchst aber keinen µC mit CAN-Controller. Arbeitest also mit deinem eigenen "Protokoll".
Mit dem (ur)alten RS485-Problem: wer darf wann senden? Wie und wer macht man die Richtungsumschaltung?
Wenn man das Rad nicht neu erfinden will (die, die denken das wäre trivial erfinden immer nur Scheinlösungen) nimmt man eben gern getrennte Kanäle für Rx und Tx oder delegiert das an übergeordnete Sachen wie z.B. an CAN.
Hat man doch. Oder müssen die Massen getrennt sein / bleiben?
Sonst wäre die 20mA TTY Schnittstelle geeignet. Ist wahrscheinlich eh die bessere Lösung.
Auch dafür gibt es fertige Interfaces, z.B.
https://www.wut.de/e-84001-ww-dade-000.php
Bei der kurzen Leitung sollte problemlos mehr als die von WuT spez. 19200 Baud drin sein.
Hat man auch schnell selbergestrickt.
Ich bin weiterhin sicher, dass man das bei geeigneter Wahl der Baudrate und passender Filterung/Terminierung über die genannten 5m auch mit RS232 hinbekommt.
Ja, 5m mit 38kBaud ist auch uber RS232 machbar. 5m ist immer noch Labor. Falls noetig kann man auch eine Potentialtrennung einfuegen, etwas Richtung ADuM1301
Currentloop (0/20mA, resp 4/20mA) ist fuer lange Distanzen, zb 500m mit 1200 Baud. Beim Zweiten detetiert man auch Unterbruch und Currentloop kann auch analoge Signale Uebertragen.
Die 8 Bytes fuer CAN ist halt je nachdem unpassend. speziell wenn man die Reaktionszeit nicht benoetigt. CAN wurde fuer Autosysteme entwickelt.
Der Nachteil von CAN ist die festen Packetgroesse.
Nö, sie ist nicht fest, sie kann 0..8 Bytes betragen. UARTs haben dagegen oft nur 1..3 Byte Puffer.
Es hindert einen niemand daran, mehrere Pakete hintereinander zu senden. CAN-Controller haben typisch mehrere MOBs, die man kaskadieren kann.
Z.B. bei 15 MOBs kannst Du 120 Byte am Stück empfangen, ehe Du in den Interrupt springen mußt. Da ist eine UART schon längst übergelaufen.
Currentloop (0/20mA, resp 4/20mA) ist fuer lange Distanzen, zb 500m mit
1200 Baud. Beim Zweiten detetiert man auch Unterbruch und Currentloop
kann auch analoge Signale Uebertragen.
Ganz einfach geht das wie bei Midi, also auch stromgesteuert. Galvanische Trennung ist durch die Optokoppler sowieso gegeben. Robust ist das auch, was die Praxis beweist. Und extrem billig.
https://www.mikrocontroller.net/articles/MIDI
Currentloop (0/20mA, resp 4/20mA) ist fuer lange Distanzen, zb 500m mit
1200 Baud. Beim Zweiten detetiert man auch Unterbruch und Currentloop
kann auch analoge Signale Uebertragen.
Man kann die TTY-Übertragung für lange Leitungen benutzen, muß man aber nicht.
Die Baudrate ist variabel, man muß sich nicht an die eigentliche Norm (110 Baud) halten, das Maximum wird durch den (üblicherweise) verwendeten Optokoppler und natürlich die Leitungslänge, begrenzt.
Ein weiterer Vorteil ist die übliche galvanische Trennung der Partner.
4..20 mA ist als digitale Übertragung nicht üblich, das kommt aus der analogen Welt.
Die 8 Bytes fuer CAN ist halt je nachdem unpassend. speziell wenn man
die Reaktionszeit nicht benoetigt. CAN wurde fuer Autosysteme
entwickelt.
Niemand schreibt vor daß 8 Bytes per Message versendet werden müssen.
CAN findet breite Anwendung in der Automatisierung, besonders auch bei mobilen Arbeitsmaschinen und in der Landwirtschaft.
Selbst bei 10m und 115k sollten 0 Fehler in 24h back-to-back auftreten.
Wenn welche auftreten, kannst Du mit Oszi und Diagnoseinfo herausfinden, wo. Typische Vertreter:
A) Baudraten matchen auf weniger als 1% (bei 3% ist komplett Schluss)
B) irgendwas auf dem Weg ist in der Sättigung (das erste Startbit verschliffen)
C) Gleichspannungsstörungen > 1V (GND ...)
D) SW-Fehler
A und B mit dem Oszi anschauen ("Augendiagramm"). Für C das Oszi im Singlebetrieb triggern lassen über Nacht. (Sollte es C sein, ein Stück Lichtleiter zwischenschalten, gibt es als fertige Wandler)
Zudem mit Diagnose feststellen, was verloren geht und warum. Einzelne Zeichen sporadisch, bursts, immer nur das erste, immer nur 0xff...
SW-Fehler: Auch bei perfekter Kommunikation verschlucken Sender oder Empfänger Telegramme oder Bytes.
BTW.: Wenn Du die HW selber in der Hand hast, kannst du relativ einfacher dafür sorgen, dass es auch über längere Strecken (auch km) robust läuft. Im Unterschied zu CAN spielt die Dauer der Daten keine Rolle. Du kannst z.B. beliebig zwischendurch auf Licht, Funk oder was immer wandeln.
