Ich habe das Problem wenn ich an einem funktionierenden HS-CAN-Bus einen zusätzlichen (6.) Teilnehmer anschließe tauchen bei hoher Buslast Error-Frames auf. Entferne ich einen Teilnehmer (auch einen anderen, muss nicht der zuletzt angesteckte sein) läuft der Bus wieder ohne Error-Frames. Terminierungsfehler kann ich ausschließen. Meine Vermutung ist dass der Fehler auftritt wenn mindestens zwei Teilnehmer gleichzeitig anfangen zu senden - mit einem kleinen Phasenunterschied - so dass ein Empfänger dann ein überlanges Bit sieht und deswegen einen Fehler wirft. Normal wird ja gleichzeitiges Senden erkannt und abgefangen. Frage daher: Muss man das Bit-Timing bei zusätzlichen CAN-Teilnehmern anpassen oder darf sich das nicht ändern?
Bei allen genannten Problemen sorgt das CAN Protokoll selbst, auch Hardwareebene bereits für Abhilfe, es heißt ja nicht ohne Grund CSMA/CA (https://elearning.vector.com/mod/page/view.php?id=53) Kannst Du das Signal nicht mal Oszillographieren? Manche Probleme erkannt man nur auf dem Layer 1 direkt... 6 Teilnehmer sind jetzt nicht gerade viel, aber vielleicht machen die, wie Du sagst alle so viel Traffic das der 6. dann der Topfen ist der das Faß zum überlaufen bringt?!
Hast Du Stichleitungen? Wenn ja, wie lang sind die? fchk
Welche Baud-Rate und wie hoch ist die Buslast wenn die Fehler auftreten?
Frank K. schrieb: > Hast Du Stichleitungen? Wenn ja, wie lang sind die? Nein, daran liegt es wohl nicht, gleicher Effekt am Testsystem mit relativen kurzem Flachbandkabel als auch in einem mehreren Meter langen Netz mit Stichleitungen, Kabel verdrillt.
RCC schrieb: > Welche Baud-Rate und wie hoch ist die Buslast wenn die Fehler auftreten? 125kBaud, Fehler beginnen etwa bei 1/3 Buslast (Einzelfehler im vielleicht Minutenabstand), bei 95% Buslast über 1000 Fehler in 15 Minuten.
Senden mehrere Teilnehmer mit der gleichen ID?
> ... 95% Buslast ...
Die Buslast ist zu hoch. Empfehlung CiA: 50 %
Das ist aber sehr konserativ und dient wohl eher dazu, dass auch niedrigpriorisierte Knoten in akteptabler Zeit ihren Kram loswerden können. Auch 90% Buslast führen erst mal nicht zu errorframes. Passen die Transceiver/eingestellte slew rate zur Baudrate?
Christian G. schrieb: > Senden mehrere Teilnehmer mit der gleichen ID? Im Testaufbau hatte ich es zum Teil so eingestellt, im Originalsystem sollte es nicht so sein - muss ich noch mal prüfen. Würdest Du darin eine Erklärung sehen (im Bruchteil einer Bitzeit verschobene Nachrichten mit gleicher ID)?
Wie ist der Abtastzeitpunkt eingestellt? Kannst den mal etwas hin-und herschieben?
Wenn mindestens zwei Nodes Nachrichten auf der gleichen ID versenden aber das Datenfeld verschieden ist, dann kommt es unweigerlich zu einer Kollision, und damit zu error frames. Da ein dominates Bit ja immer (! nicht nur während der Arbitrierungsphase) ein rezessives Bit überschreibt und damit über das Zurücklesen ein Fehler erkannt wird. Jeder Node muss daher mit eigenen IDs arbeiten, die im Netzwerk nur einmalig vergeben sind. Die Verschiebung um den Bruchteil einer Bitzeit könnte evtl. auch noch zu Problemen führen. Wobei ich das noch nie gesehen habe. Theoretisch wäre es aber möglich die Abtastzeitpunkte je Node so unterschiedlich einzustellen, dass es zu deinen Problemen kommt.
:
Bearbeitet durch User
Bit-Zeiten (Quantas) können ein Problem sein, aber wahrscheinlicher ist eine ID-Kollision. Alles oben genannte führte dann unweigerlich zu einem CRC Fehler. Ich meine mich aber zu erinnern das ein CAN-Controller pet Definition das gesendete Bit auch immer einliest und vergleicht, nicht nur während der Arbitrierungsphase. Somit sollten die Sender ihr Problem erkennen und den internen Fehlerzähler erhöhen der dann früher oder später zur Selbstabschaltung eines der Nodes führen sollte.
Wie Helmut schon fragte: Wie ist der Abtastzeitpunkt eingestellt? Wenn der ungünstig liegt, kann genau der geschilderte Effekt eintreten!
Manschmal führen auch gut gemeinte Filter / ungeeigneter Überspannungsschutz zu kapazitiver Belastung der Busleitungen. Verringere mal die kapazitive Last und prüfe erneuet. Volker
Ja, genau das machen die CAN-Controller (nicht die Transceiver). Wenn dann aber außerhalb des Arbitrierungsbereichs ein rezessives Bit gesendet und ein dominantes gelesen wird, wird ein Errorframe gesendet. Dieser Vergleich soll ja genau das feststellen, dass die auf dem Bus liegende Nachricht nicht mit der zu sendenden Nachricht übereinstimmt. Deshalb ist es auch eine blöde Idee, dass mehrere Nodes mit der ID senden, das kann nur schief gehen. Bis zum CRC Fehler kommts in einem solchen Fall schon gar nicht. Denn bevor die Checksumme auf dem Bus liegt muss ja ein Unterschied im Datenbereich zwischen den gleichzeitig sendenden Nodes da gewesen sein und somit wird die aktuelle Übertragung per Errorframe abgebrochen. Zuerst von dem Node, der den Fehler erkennt, dann stimmen alle anderen Nodes mit ein. Hab jetzt spontan keine Ahnung mehr wieviele Bitzeiten der Errorframe lang ist, nach Abschluss wird der Bus für die nächste Übertragung wieder freigegeben.
Beitrag #5966512 wurde von einem Moderator gelöscht.
Gerald O. schrieb: > bei 95% Buslast über 1000 Fehler in 15 > Minuten. Woher kommt diese Buslast? Aus einem Tool? Theoretisch errechnet? Selber gemessen? Wie? Vielleicht ist die tatsächliche Buslast ja bei 100.0% und daher die Fehler. Nur eine Vermutung.
Peter schrieb: > Gerald O. schrieb: >> bei 95% Buslast über 1000 Fehler in 15 >> Minuten. > > Woher kommt diese Buslast? Aus einem Tool? Theoretisch errechnet? Selber > gemessen? Wie? > > Vielleicht ist die tatsächliche Buslast ja bei 100.0% und daher die > Fehler. Nur eine Vermutung. Auch 100% macht keine Error-Frames, nur die Botschaften mit hoher ID kommen nicht mehr auf den Bus.
Wie siehts denn mit den Abschlusswiderständen aus? LG, Sebastian
Sebastian W. schrieb: > Wie siehts denn mit den Abschlusswiderständen aus? Gerald O. schrieb: > Terminierungsfehler kann ich ausschließen. Man darf auch ab und zu was glauben, und hier glaube ich es.
Peter schrieb: > Woher kommt diese Buslast? Aus einem Tool? Theoretisch errechnet? Selber > gemessen? Wie? PCAN-View / CANoe Die Buslast alleine darf kein Grund für Error-Frames sein.
Sebastian W. schrieb: > Wie siehts denn mit den Abschlusswiderständen aus? Beide Enden je 120 Ohm - auch am Oszi überprüft wie das Signal aussieht in Abhängigkeit von den Abschlußwiderständen - sauber. Garry
Christian G. schrieb: > Jeder Node muss daher mit eigenen IDs arbeiten, die im Netzwerk nur > einmalig vergeben sind. Dachte schon das Problem reproduzieren zu können, da war mir allerdings nur der Fehler mit der doppelten ID beim erzeugen von Buslast mit mehreren Nodes unterlaufen. An den Abtastzeitpunkten bin ich noch dran. Problem durch ESD-Schutzdioden ist eventuell auch noch ein Ansatz. Danke für die Tipps! Garry
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.