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? Vorab vielen Dank für Euren Input
TM6 F. schrieb: > 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.
:
Bearbeitet durch Moderator
TM6 F. schrieb: > 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.
Guten Abend, 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. Schönen Gruß
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.
TM6 F. schrieb: > 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. TM6 F. schrieb: > 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. H.Joachim S. schrieb: > RS232 ist im gestörten Umfeld nicht so dolle Wir wissen eigentlich noch nichts vom "Umfeld", ausser dass es eine "Montageanlage" ist.
:
Bearbeitet durch Moderator
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.
Der Nachteil von CAN ist die festen Packetgroesse. 6 Bytes oder so. Wenn die nicht passen ist nicht gut. Ich verwend RS422 resp RS485.
H.Joachim S. schrieb: > Wenn man das Rad nicht neu erfinden will.... ... nimmt man RS422 z.B. https://www.wut.de/e-86000-ww-dade-000.php Uwe
H.Joachim S. schrieb: > Ja, wenn man ausreichend Adern hat..... 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. Uwe
Uwe B. schrieb: > Sonst wäre die 20mA TTY Schnittstelle geeignet. Ich bin weiterhin sicher, dass man das bei geeigneter Wahl der Baudrate und passender Filterung/Terminierung über die genannten 5m auch mit RS232 hinbekommt.
Purzel H. schrieb: > Der Nachteil von CAN ist die festen Packetgroesse. 6 Bytes oder so. Unsinn. CAN2.0A/B kann 0 bis 8 Bytes transportieren. Und zwar jeden Botschaft individuell. CAN-FD kann 0 bis 64 Bytes transportieren, individuell.
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.
:
Bearbeitet durch User
Purzel H. schrieb: > 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.
Purzel H. schrieb: > 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
Purzel H. schrieb: > 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. https://de.wikipedia.org/wiki/TTY-Schnittstelle 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. Uwe
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.
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.