Hallo, ich habe hier ein Problem mit dem CAN-Bus, und zwar folgendes: Ich habe zwei Geräte, die via CAN kommunizieren. Es handelt sich dabei um fertige Geräte, ich habe also keine Unterlagen davon, aber das ist auch nebensächlich denke ich. Ich habe weiterhin ein CAN-PC-Interface von EMS Dr. Thomas Wünsche, damit kann ich den Datenverkehr mit 100 kBit/s auch sniffen. Es laufen dabei ca. 760 Nachrichten pro Sekunde durch (Buslast 89%). Nun muss ich ein weiteres Gerät einbinden, dazu habe ich mir zunächst eine Testschaltung mit dem MCP 2511 aufgebaut (Schaltplan ist angehängt). Sobald ich den MCP 2551 am Bus mit dazuhänge, geht die Anzahl der Nachrichten in die Knie: 2-4 Nachrichten / Sekunde (Buslast 0.2 - 0.4 %). Hat jemand eine Idee woran das liegen kann ? Ausgangsseitig ist der MCP noch nicht beschaltet, also Rx und Tx sind offen. Ein zusätzlichen Abschlußwiderstand von 120 Ohm am MCP ändert absolut nicht...
Danke für den Tip, ändert leider absolut nichts. Es gibt auch keine Errorframes o.ä. auf dem Bus, auch das entfernen von R1 ändert nichts (also Pin 8 offen lassen).
:
Bearbeitet durch User
Harald B. schrieb: > Ausgangsseitig ist der MCP noch nicht beschaltet, also Rx und Tx sind > offen. Aber die 5V sind doch angeschlossen?
Moin. Liegt es vielleicht an einer doppelten CanID? Eine Buslast von 89% ist auch schon recht hoch, viel solltest du nicht mehr machen...
Ich glaube nicht dass es an einer doppelten CAN-ID hängt. Es sind zwei Komponenten einer Maschine die so eigentlich immer kommunizieren. Ich selbst sende ja noch nichts am Bus, insofern dürfte eine ID keine Ursache sein. Abgesehen davon kann ich auch einen der beiden Busteilnehmer abziehen, da mein PC-Interface als 2. Teilnehmer fungiert sendet der erste Teilnehmer immer noch Daten
Harald B. schrieb: > Es laufen > dabei ca. 760 Nachrichten pro Sekunde durch (Buslast 89%). Das ist nicht mehr gesund für deinen Bus, am besten versuchst du unter 70% zu bleiben. Hast du keine Möglichkeit die Busgeschw. zu erhöhen? Harald B. schrieb: > Sobald ich den MCP 2551 am Bus mit dazuhänge, geht die > Anzahl der Nachrichten in die Knie: 2-4 Nachrichten / Sekunde (Buslast > 0.2 - 0.4 %). Das klingt so als würden die anderen beiden Nodes in den "Bus Off" Modus wechseln. Das passiert, wenn der Error Counter > 255 erreicht wird. Der Busteilnehmer trennt ich dann via interner logic vom Bus und nimmt nicht mehr daran Teil. Nachdem an deinem Transreceiver noch kein eigentliches CAN device angeschlossen ist, würde ich mal darauf tippen, dass dein Transreceiver den Bus physikalisch kaputt macht. Kannst du den deinen MCP2551 mal außerhalb testen?
:
Bearbeitet durch User
Wie hast Du Deine Schaltung denn an den Bus angeschlossen? Kabellänge, Irgendwo in der Mitte oder am Ende, lange Stichleitungen vermieden, alles richtig verbunden, auch GND? Sollte bei 100 kbit/s zwar nicht so kritisch sein aber man weiss ja nie...
Salüü und wie oft sollten diese die Daten senden? evtl. könnte es auch ein nicht sauber eingestellten CAN sein... meine Überlegung: Beim CAN gibt es auch ein ACK, wenn dieses nicht gesendet wird kann es sein dass das Frame nochmals gesendet wird. Wenn nun bei beiden Teilnehmern das ACK des jeweilig anderen deaktiviert ist, aber beide senden die eigenen Daten wieder wenn das eigene Frame kein ACK bekommt hast du eine Endlosschleife. sobald der MCP dazukommt bekommen alle ein ACK und es wird nur noch so oft gesendet wie es eigentlich gedacht war. Ist doof formuliert... Beide erwarten ein ACK. Keiner sendet ein ACK. Wen kein ACK kommt werden die Frames wieder gesendet (automatic retransmit) -->Buslast sehr hoch. MCP kommt ins spiel und sendet bei allen Frames ein ACK -->Buslast normal hoch Gruss
Da es sich hier um Komponenten einer Maschine handelt die ich nicht gebaut habe, kann ich auch an der Geschwindigkeit oder den Telegrammen nichts ändern. Der Errorcount des Sniffers ist aber auf 0, d.h. es treten keine Fehler auf... Um mal das ganze Szenario zu erläutern: Ich habe eine Maschine mit sagen wir mal 10 Prozessoren, die innerhalb der Maschine verteilt sind und via CAN kommunizieren. Diese Maschine ist nicht von mir gebaut, ich habe also weder eine ausführliche Doku noch irgendwelche sonstigen Informationen. Insgesamt ist der Verkehr auf 3 CAN-Linien verteilt, davon arbeiten 2 mit 250 kBit/s, die dritte mit 100 kBit/s. An der dritten Linie hängen nur 2 Teilnehmer, der Hauptrechner und ein Slave. Und nur um diese Linie geht es mir. Beim Hochfahren der Anlage erteilt der Hauptrechner diesem Slave eine Freigabe via CAN (lt. Doku). Nun möchte ich aber zu Test und Simulationszwecken den Slave im Labor zum Laufen bringen, also ohne Hauptrechner. Ich muss also diese Freigabe vom Laptop aus schicken. Dazu muss ich einmal beim Hochfahren den Datenverkehr mitsniffen, um zu sehen wie diese Freigabe aussieht. Das Problem dabei ist, dass diese CAN-Linie als optischer CAN ausgeführt ist (also mit LWL-Leitern). Ich vermute jetzt, dass einfach die Rx und Tx Signale des Controllers auf entsprechende Fotoelemente geführt sind. Damit ich also den Datenverkehr dieser optischen Linie verfolgen kann, möchte ich einen Adapter bauen. Der Hauprechner bietet nun außer der optischen CAN-Schnittstelle auch eine kabelgebundene Schnittstelle an. Diesen Verkehr kann ich mit meinem CAN-Adapter auch verfolgen. Nun möchte ich als ersten Ansatz zu diesem Adapter einen MCP2551 an die kabelgebundene Schnittstelle des Hauptrechners zusätzlich anbinden, um zu sehen ob ich dann mit den Rx/Tx-Sgnalen eine LED /Photo Diode betreiben kann... Und genau da taucht diese Problematik auf....
Simi schrieb: > Beide erwarten ein ACK. > Keiner sendet ein ACK. > Wen kein ACK kommt werden die Frames wieder gesendet (automatic > retransmit) > -->Buslast sehr hoch. Damit könntest Du richtig liegen. Da es sich um einen otpischen CAN handelt, den ich derzeit noch nicht nachstellen kann, habe ich auch hier nicht den richtigen Teilnehmer angeklemmt. Möglicherweise pollt der Hauptrechner um zu sehen ob der richtige Teilnehmer auch da ist, der antwortet aber nicht deshalb pollt der Hauptrechner weiter...
Harald B. schrieb: > Damit könntest Du richtig liegen. Wenn Du das Problem gelöst hast, berichte bitte mal, woran es lag. Ich hatte auch schon unangenehme Probleme mit dem ACK.
Mache ich, aber derzeit ist es noch nicht soweit. Am ACK kann es nicht liegen befürchte ich. Dann müsste die Buslast ja wieder steigen, wenn ich dem MCP die Spannungsversorgung wegnehme. Tut sie aber nicht
Ok, ich denke es ist irgendwas mit der Verkabelung, werde die nochmal komplett neu aufbauen. Ich habe jetzt die Schaltung mit dem MCP komplett abgetrennt, und wenn ich das Oszi zwischen CanH und CanGnd klemme, habe ich auch ein astreines Signal bei hoher Buslast. Wenn ich das Oszi zwischen CanL und CanGnd klemme, dann geht die Buslast runter auf 0.5% und ein Signal ist eigentlich nicht zu erkennen
Bitte 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.