CAN-Bus Problem

[Harald B. (grieko)]

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...

[Peter D. (peda)]

Überbrücke mal R3 und nimm R1, R2 raus.

[Harald B. (grieko)]

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).

[Μαtthias W. (matthias)]

Hi

Leg mal tx von deinem mcp auf 5V

[Peter D. (peda)]

Harald B. schrieb:
> Ausgangsseitig ist der MCP noch nicht beschaltet, also Rx und Tx sind
> offen.

Aber die 5V sind doch angeschlossen?

[Marcus (Gast)]

Moin.

Liegt es vielleicht an einer doppelten CanID? Eine Buslast von 89% ist 
auch schon recht hoch, viel solltest du nicht mehr machen...

[Harald B. (grieko)]

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

[Zod M. (do0zy)]

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?

[Herr Bert (Gast)]

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...

[Simi (Gast)]

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

[Harald B. (grieko)]

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....

[Harald B. (grieko)]

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...

[Günter N. (turtle64)]

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.

[Harald B. (grieko)]

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

[Harald B. (grieko)]

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