mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Probleme mit Can Hausbus


Autor: Daniel W. (albireo_01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich lese hier schon lange mit und habe schon viele Informationen für 
mein Projekte hier gefunden.

Jetzt stehe ich allerdings vor einem Problem bei dem ich nicht 
weiterkomme. Ich habe mir eine Alarmanlage mit über Can Bus vernetzte 
Sensoren gebaut. Im Moment laufen 5 Sensoren in einer Liniestruktur 
problemlos. Die Länge des Busses beträgt etwa 30 Meter. Der Anfang und 
das Ende des Busses sind mit je einem 120 Ohm Widerstand abgeschlossen. 
Als Kabel habe ich ungeschirmtes 2x2 Telefonkabel verwendet. Der Bus 
läuft mit einer Geschwindigkeit von 10kb/s. Alle Sensoren werden über 
das Can Kabel mit Strom versorgt, 16V die dann mit einem StepDown 
Wandler auf 5V reduziert werden.
Soweit läuft das alles prima. Wenn ich jetzt jedoch einen weiteren 
Sensor anschließe geht nichts mehr. Egal wie kurz oder lang die Leitung 
zum neuen Sensor ist.  Habe auch die Sensoren getauscht, immer wenn der 
6. angeschlossen wird ist Schluss. Ich habe die Can 
Parameter/Geschwindigkeit geändert, habe die slope-control Werte 
geändert, nichts hilft. Ich bin jetzt am Ende meiner Ideen, könnt ihr 
mir hier noch einen Tipp geben was hier das Problem sein könnte?

Viele Grüße
Daniel

Autor: Max D. (max_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jeder can Baustein am bus belastet den zusätzlich. Guck mal in dein 
Datenblatt was es dazu zu sagen hat. Oder testweise mal die 
Abschlusswiderstände runter.

Autor: dunno.. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was für transceiver sind es denn?

An und für sich klingt das jetzt nicht kritisch..

Autor: Daniel W. (albireo_01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Abschlusswiderstände hatte ich schon reduziert, auf jeweils 60 Ohm 
anstatt 120 Ohm.

Als Transceiver verwende ich den MCP2551.

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reduzier mal in die andere Richtung,  z.b. 180 Ohm

Autor: Daniel W. (albireo_01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hatte ich auch schon probiert bis 220Ohm, hilft nichts :-(

Autor: Sebastian S. (amateur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jeder Teilnehmer "belastet" das System. Bist Du auch wirklich im grünen 
Bereich? Frag mal Oszi.
Sollte der Fehler in diesem Bereich liegen, so könnte das Gegenteil 
(Abschlusswiderstand verringern) der vorherigen Vorschläge vorübergehend 
helfen.

Ist sichergestellt, dass alle Teilnehmer eine andere Hausnummer haben?

Autor: Daniel W. (albireo_01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich arbeite in einer Master-Slave Konfiguration. Die Sensoren antworten 
nur nach Aufforderung durch den Master. Die Adressierung erfolgt nicht 
auf der Can Netzwerk Ebene, hier werden allen Nachrichten von allen 
Sensoren empfangen. Aber das kann doch nicht das Problem sein, oder?

Auf dem Oszilloskop habe ich mir das Signal noch nicht angesehen, müsste 
ja dann zwischen 4 Und 5 Volt liegen von Can H und L gegen Masse, 
richtig?

Autor: CAN (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Normal ist das nicht.....

Autor: Hugo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel W. schrieb:
> Die Adressierung erfolgt nicht
> auf der Can Netzwerk Ebene, hier werden allen Nachrichten von allen
> Sensoren empfangen. Aber das kann doch nicht das Problem sein, oder?

Heißt das, daß du keine CAN-IDs vergeben hast? Bzw. überall die gleiche 
ID? Da muß es ja Kollisionen geben. Wundert mich, daß es nicht schon 
längst geknallt hat. Jeder Bus-Teilnehmer benötigt eine eigene ID, sonst 
kommen die sich beim Senden in die Quere. Als übergeordnetes Protokoll 
kannst du ja gerne Master/Slave nehmen, aber auf CAN-Ebene geht das 
nicht...

Autor: Julian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel W. schrieb:
> Alle Sensoren werden über
> das Can Kabel mit Strom versorgt, 16V die dann mit einem StepDown
> Wandler auf 5V reduziert werden.

Es liegen also 16V auf der Versorgungsleitung und an jedem Sensor hast 
du einen Step-Down-Regler? Versteh ich dich richtig?
Was für einen Step-Down-Regler damit ich mir mal das Datenblatt 
anschauen kann. Wie erzeugst du die 16V? Was ist das für ein Netzteil? 
Welche Leistung? Hier bitte mehr Infos mehr.

Daniel W. schrieb:
> Im Moment laufen 5 Sensoren in einer Liniestruktur
> problemlos.

Was für Sensoren? Auch hier bitte nähere Angaben, idealerweise Link zum 
Datenblatt

Daniel W. schrieb:
> Auf dem Oszilloskop habe ich mir das Signal noch nicht angesehen, müsste
> ja dann zwischen 4 Und 5 Volt liegen von Can H und L gegen Masse,
> richtig?

Falsch!
U_CAN_High dominant: 3.5V
U_CAN_High rezessiv: 2.5V
U_CAN_Low dominant: 1.5V
U_CAN_Low rezessiv: 2.5V
Daraus folgt augfrund der Differenz-Übertragung:
U_diff dominant: 2V
U_diff rezessiv: 0V
Nur mal der Vollständigkeit halber, die korrekten Pegel.

Wenn du die notwendigen Datenblätter rausgesucht hast, kann ich dir 
weiter helfen. Das Problem sollte schnell gelöst sein.

Autor: Julian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hugo schrieb:
> Jeder Bus-Teilnehmer benötigt eine eigene ID, sonst
> kommen die sich beim Senden in die Quere

Sorry aber das ist falsch. CAN ist eben NICHT Adress-orientiert sondern 
Nachrichten-orientiert. Jeder Teilnehmer liest alles und filter anhand 
der Nachrichten-ID für sich, ob die Nachricht für ihn relevant ist oder 
nicht.
Die höchswertige ID im Arbitrations-Segment kommt durch. Ein Teilnehmer 
hört sein Telegramm selber ab und überprüft somit, ob es eine Kollision 
gab, wenn z.B. nicht das auf dem Bus anliegt, was er gesendet hat. 
Stichwort: CSMA/CA

Daran liegt dein Problem nicht.

Autor: Stefan K. (stefan64)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann es sein, daß Dein 6. Controller einfach einen Hardware-Defekt hat? 
Funktioniert der Bus, wenn dieser Controller angesteckt ist, aber ein 
anderer entfernt wird?

Kannst Du die CAN-Signale mit einem Oszi messen?

Ist auf den Controllern ein Widerstand oder ein anderes Bauteil zwischen 
den CAN-Leitungen verbaut?

Kann es sein, daß der 6. Controller mit derselben ID wie einer der 
anderen Controller sendet?

Gruß, Stefan

Autor: Daniel W. (albireo_01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die 6 Sensoren sind letztlich jeweils ein PIC18F2480 mit einem eigenem 
Step Down Wandler LM2574 und diversen Sensoren wie Akustik, IR 
Temperatur.

Die 16V kommen aus einem zweckentfremdeten Laptop Netzteil. Die Zentrale 
ist ein Raspberry Pi mit einem CAN Interface mit einem PIC 18F4580. Wie 
gesagt fragt die Zentrale die Sensoren seriell ab, kein Sensor darf ohne 
Aufforderung senden. Adressierung erfolgt auf der Applikation Ebene, 
grundsätzlich hören alle Sensoren alles was auf dem Bus passiert.

Autor: Daniel W. (albireo_01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe hier noch zwei weitere fertig aufgebaute Sensoren, bei allen 
passiert das Selbe, ein Hardware defekt ist ausgeschlossen :-( Ich sag 
ja ist ne harte Nuss, quäle mich jetzt schon seit 14 Tage damit rum.

: Bearbeitet durch User
Autor: Stefan K. (stefan64)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann es sein, daß 2 Controller gleichzeitig mit derselben ID senden? 
Dann können beide Controller ihre msg ständig wiederholen und keine 
andere msg kommt mehr durch.

Stell mal sicher, daß die anderen Controller nichts zurücksenden bzw. 
nur der 6. senden kann, und schaue, ob das Problem immer noch besteht.

Alternative: miss mal auf dem CAN-Bus. Wenn obiges Problem auftaucht, 
dann siehst Du ständigen Traffic auf dem Bus.

Viele Grüße, Stefan

Autor: Hugo (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Stefan K. schrieb:
> Kann es sein, daß 2 Controller gleichzeitig mit derselben ID senden?
> Dann können beide Controller ihre msg ständig wiederholen und keine
> andere msg kommt mehr durch.

Genau das war auch mein Ansatz.

> Hugo schrieb:
>> Jeder Bus-Teilnehmer benötigt eine eigene ID, sonst
>> kommen die sich beim Senden in die Quere
>
Daraufhin antwortete Julian:
> Sorry aber das ist falsch. CAN ist eben NICHT Adress-orientiert sondern
> Nachrichten-orientiert. Jeder Teilnehmer liest alles und filter anhand
> der Nachrichten-ID für sich, ob die Nachricht für ihn relevant ist oder
> nicht.

Das ist mir völlig klar, daß CAN message-orientiert ist. Aber es darf 
trotzdem keine zwei Sender geben, die mit der gleichen CAN-ID senden. 
Hören darf jeder alles, das kann man auch durch konfigurierbare Filter 
einschränken. Aber zweimal die gleiche Sende-ID geht definitiv nicht.

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel W. schrieb im Beitrag #4858787
> Als Kabel habe ich ungeschirmtes 2x2 Telefonkabel verwendet.

Ist das eigentlich getwisted?

Manchmal hilft eine Split-Terminierung oder kleine Kondensatoren (4,7pF) 
von CAN-H und CAN-L nach GND.

Ansonsten erstmal versuchen, ob ein Sensor alleine am Master geht.

Autor: temp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich halte das auch für einen groben Designfehler. Wenn du eine 
Master-Slave Umgebung willst hättest du besser RS485 genommen.
Bei CAN ist es zwar prinzipiell möglich, dass mehrere Sensoren auf der 
gleichen ID zu unterschiedlichen Zeiten senden, dass muss man aber auch 
ordentlich überwachen. Die einzelnen Sensoren müssen dann selbst dafür 
sorgen, dass sie nicht versuchen eine Nachricht endlos neu zu senden 
sondern wirklich nur in ihrem Timeslot aktiv sind. Spätestens wenn der 
zweite Sensor auch versucht seine fehlgeschlagene Nachricht zu 
wiederholen hast du den Deadlock.

Mit der ganzen Probiererei der Abschlusswiderstände kannst du getrost 
aufhören. Damit hat das mit Sicherheit nichts zu tun. Nicht bei 10kb/s. 
Ich habe bei mir im Haus den Bus mit 100kb/s laufen in einer gemischten 
Topologie mit Sternen und Reihen und teilweise unverdrillten Leitungen 
die seit 30Jahren in der Wand liegen. Das funktioniert seit mehreren 
Jahren völlig Problemlos. Die meisten Treiber sind da ISO1050.

Vorausgesetzt natürlich die Verkabelung ist in Ordnung und es gibt keine 
Kurzschlüsse/Unterbrechungen und extreme Potentialverschiebungen 
zwischen den Teilnehmern.

Versuch bitte nicht gegen den Grundgedanken von CAN anzustinken, das 
bringt nichts. Gib jeden Sensor eine ID und lass sie Senden wenn sie es 
für nötig halten. Und vor allem kümmere dich um eine Möglichkeit an 
deinem Bus etwas zu messen. Ob mit Oszi oder LA ist egal aber bitte 
nicht im Kaffeesatz stochern.

Autor: H.Joachim Seifert (crazyhorse)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dieter schrieb:
> Ist das eigentlich getwisted?

Völlig egal bei 10kBit und 30m Buslänge

Daniel W. schrieb:
> Wie
> gesagt fragt die Zentrale die Sensoren seriell ab, kein Sensor darf ohne
> Aufforderung senden.

Das ist eigentlich nicht der Sinn von CAN. Genau um dieses nicht tun zu 
müssen wurde der ganze Aufwand gemacht. In deinem Fall wäre RS485 die 
billigere, einfachere und sogar noch schnellere Lösung gewesen. CAN ist 
ein Multimaster-Bus, der auf fast geniale Weise den Buszugriff 
kollisionsfrei regelt. Gibts irgendeinen Grund, warum du von dieser 
Grundidee abweichst? Gib jedem Knoten eine eigene ID und lass die 
fröhlich in sinnvollen Abständen (Busbandbreite beachten!) vor sich 
hinplappern.

Autor: Steffen Rose (steffen_rose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan K. schrieb:
> Alternative: miss mal auf dem CAN-Bus. Wenn obiges Problem auftaucht,
> dann siehst Du ständigen Traffic auf dem Bus.

Kollisionen (gleiche CANID, unterschiedliche Daten) führen zum Busoff 
und man sieht keinen Traffic mehr.

Dauerhaftes Senden der gleichen Nachricht hat man nur bei einem aktiven 
Teilnehmer und fehlendem Acknowledge anderer Teilnehmer. Diese Situation 
kann z.B. auch dann entstehen, wenn die anderen Teilnehmer in Busoff 
gegangen sind.

Autor: Steffen Rose (steffen_rose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hugo schrieb:
>> Hugo schrieb:
>>> Jeder Bus-Teilnehmer benötigt eine eigene ID, sonst
>>> kommen die sich beim Senden in die Quere
>>
> Daraufhin antwortete Julian:
>> Sorry aber das ist falsch. CAN ist eben NICHT Adress-orientiert sondern
>> Nachrichten-orientiert. Jeder Teilnehmer liest alles und filter anhand
>> der Nachrichten-ID für sich, ob die Nachricht für ihn relevant ist oder
>> nicht.
>
> Das ist mir völlig klar, daß CAN message-orientiert ist. Aber es darf
> trotzdem keine zwei Sender geben, die mit der gleichen CAN-ID senden.
> Hören darf jeder alles, das kann man auch durch konfigurierbare Filter
> einschränken. Aber zweimal die gleiche Sende-ID geht definitiv nicht.

Jein. Es dürfen nicht gleichzeitig zwei Sender mit der gleichen CANID 
senden. (Ausnahmen gleiche Daten, z.B. CANopen-LSS, geht aber mit CAN-FD 
definitiv nicht mehr).

Dies stellt man am besten sicher, dass es keine zwei Geräte gibt, die 
die gleichen IDs benutzen. Technisch funktioniert es aber, solange die 
Sender zu unterschiedlichen Zeitpunkten senden.

Unschön ist es aber auf jeden Fall.

Autor: Erwin D. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
temp schrieb:
> Bei CAN ist es zwar prinzipiell möglich, dass mehrere Sensoren auf der
> gleichen ID zu unterschiedlichen Zeiten senden

Das sieht die CAN-Spezifikation aber ganz anders:
"Ein Teilnehmer kann Empfänger und Sender von Nachrichten mit
 beliebig vielen Identifiern sein, aber umgekehrt darf es zu
 einem Identifier immer nur maximal einen Sender geben, damit
 die Arbitrierung funktioniert."

Autor: temp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erwin D. schrieb:
> Das sieht die CAN-Spezifikation aber ganz anders:
> "Ein Teilnehmer kann Empfänger und Sender von Nachrichten mit
>  beliebig vielen Identifiern sein, aber umgekehrt darf es zu
>  einem Identifier immer nur maximal einen Sender geben, damit
>  die Arbitrierung funktioniert."

Ich sprach auch von "möglich" im Sinne von technisch möglich und nicht 
davon was irgendwo geschrieben steht. Das heißt noch lange nicht dass 
ich es machen würde und das es gut ist oder eine Empfehlung. Aber der 
der hier die Probleme hat macht genau das und hat wohl die 
Besonderheiten einer solchen Krampflösung nicht im Griff.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieviel Strom zieht denn ein Modul und wieviel kann das Netzteil?

Es kann sein, daß das Netzteil ab 6 Modulen schwingt bzw. die 6 Regler 
zuviel Ripple erzeugen.
Wie hast Du das Netzteil und die Regler gefiltert?

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich könnte mir vorstellen das der weitere CAN-Controller nicht richtig 
oder vollständig konfiguriert ist und ununterbrochen Versucht seine 
Nachricht auf den Bus zu bekommen (Hohe Buslast).

Ich sehe es auch nicht als Vorteilhaft wenn der Master jeden anklingeln 
muss entweder man gibt das dem Slave vor je nach Wichtigkeit der 
Nachricht die Zeitinterwalle zu ändern oder man schränkt es noch weiter 
ein.  Ist es z.B. nötig einen gleichen Wert ständig neu zu übertragen? 
Man könnte das nur machen wenn sich der Wert um eine gewisse Abweichung 
verändert.

Zum Signalabgriff kannst du auch ein 2 Kanaloszi mit Math Funktion 
nehmen einfach auf Differenz stellen.

Oder dein Oszi an den CAN-Tranceiver aber dann hat man nur das 
glattgebügelte Signal.

Autor: Daniel W. (albireo_01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

erst mal danke für die rege Beteiligung und Hilfestellung!
Jeder CAN Knoten (Sensoren) hat seine eigene Adresse (CANID), das kam 
oben glaube ich falsch rüber. Es gibt aber auch eine Broadcast Adresse 
wenn alle Sensoren angesprochen werden sollen, hier soll dann aber auch 
keiner Antworten sondern nur eine Aktion ausführen. Die Auswertung ob 
die CANID die Richtige ist erfolgt aber nicht im CAN Modul selbst 
sondern in meiner Software für den Sensor oder der Zentrale, das wollte 
ich eigentlich sagen.

Das alle Sensoren wild vor sich hin brabbeln, kann man so machen, ist in 
meinem Anwendungsfall aber nicht nötig. Hier wird einfach nur von der 
Zentrale gefragt, wie der Status des jeweiligen Sensors ist und der 
Antwortet dann. Da der Sensor mit seiner Adresse angefragt wird, 
antwortet auch nur er. Da ich später die komplette Haussteuerung über 
den CAN Bus machen möchte und hier eine weitere Zentralen dazukommen 
wird, macht hier RS485 keinen Sinn.

Viele Grüße
Daniel

: Bearbeitet durch User
Autor: Cyblord ---- (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel W. schrieb:
> Das alle Sensoren wild vor sich hin brabbeln, kann man so machen, ist in
> meinem Anwendungsfall aber nicht nötig.

Das SOLLTE man aber so machen, weil man sonst kein CAN macht sondern 
irgendwas undefinierbares.

> Hier wird einfach nur von der
> Zentrale gefragt, wie der Status des jeweiligen Sensors ist und der
> Antwortet dann.

Genau das Prinzip widerspricht CAN völlig.

Autor: Daniel W. (albireo_01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Sensor Module ziehen jeweils 0,02 A, das Netzteil hat 16,5V und 
2,6A. Der Raspberry Pi hängt da allerdings auch mit dran, zieht ja auch 
bis zu 1,8A, das könnte durchaus eng werden. Muss ich mal nachmessen, 
wenn das wirklich das Problem ist wäre das schon irgendwie ziemlich blöd 
;-)

Autor: Clemens S. (zoggl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Hier wird einfach nur von der
>> Zentrale gefragt, wie der Status des jeweiligen Sensors ist und der
>> Antwortet dann.

definiere bitte "anfragen"
-remote Frame
-anfrage mit einer eigenen message id und sensor ID als payload => 
sensor liest und antwortet
-irgend ein selbstbau Pfusch
-??

sg

edit: falsch zitiert

: Bearbeitet durch User
Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
H.Joachim S. schrieb:
> In deinem Fall wäre RS485 die
> billigere, einfachere und sogar noch schnellere Lösung gewesen.

Warum sollte man sich ohne Not diesen riesen Softwareoverhead aufhalsen?

Auch wenn die Slaves nur auf Anforderung senden, hat CAN nur Vorteile.
Die CAN-Hardware übernimmt vieles, was man unter RS-485 mühsam selber 
programmieren müßte (Arbitration, Kollisionserkennung, CRC, Retry, 
Richtungsumschaltung, Fehlererkennung, Frameerkennung, Adressierung).

Autor: Daniel W. (albireo_01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Anfragen an den Sensor werden mit einer Speziellen CAN-ID gesendet. 
Der Payload enthält dann die Befehle was abgefragt wird. Hatte ich 
weiter oben aber auch schon so beschrieben.

Autor: Erwin D. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel W. schrieb:
> Die Anfragen an den Sensor werden mit einer Speziellen CAN-ID
> gesendet.
> Der Payload enthält dann die Befehle was abgefragt wird. Hatte ich
> weiter oben aber auch schon so beschrieben.

Da stellt sich mir trotzdem die Frage: Warum machst du sowas?
Sollen doch alle Sensoren ihre Daten auf den BUS legen in geeigneten 
Zeitabständen. Wer von den Aktoren die Daten braucht, verwendet sie 
einfach. So wie es im CAN vorgesehen ist.

Ich vermute den Fehler in deinem selbstgestrickten Prozedere.

Autor: paul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim CAN werden Nachrichten zyklisch gesendet. In deinem Fall sollten 
die Sensorwerte also von den Slaves zum Master gesendet werden.

Alternativ könntest du auch versuchen das Ganze über das RTR Bit zu 
lösen. Das ist eigentlich für so was vorgesehen. Der Master schickt dann 
einen Frame mit der ID, die zum Sensorwert (oder Slave) passt, um dessen 
Werte anzufordern. Das RTR Bit ist dabei rezessiv gesetzt. Einige CAN 
Controller antworten dann automatisch mit den Daten, bei anderen muss 
man das selber implementieren.

Autor: Steffen Rose (steffen_rose)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Erwin D. schrieb:
> einem Identifier immer nur maximal einen Sender geben, damit
>  die Arbitrierung funktioniert."

Standards definieren daher, wann Objekte gültig sind und wann nicht. Man 
schiebt sich quasi die CANID zu. Somit sind nicht mehrere gleichzeitig 
Sender dieser CANID. Das ist ja genau der schwierige Teil, damit es 
nicht zu Kollisionen kommt.

Oft nennt man es auch banal die Konfiguration zur Laufzeit.

Erwin D. schrieb:
> Da stellt sich mir trotzdem die Frage: Warum machst du sowas?

Inwiefern hilft das bei der Problemlösung?

paul schrieb:
> Beim CAN werden Nachrichten zyklisch gesendet.

Kommt auf das Protokoll an. Bei CANopen wird eher das Senden bei Bedarf 
(Eventbasierend) bevorzugt.

paul schrieb:
> Alternativ könntest du auch versuchen das Ganze über das RTR Bit zu

RTR wird aufgrund der verschiedenen Implementierungen der 
Hardwarehersteller eher nicht mehr empfohlen und wurde für CANFD auch 
nicht mehr berücksichtigt.

Aber auch hier sehe ich keinen Ansatz für eine Problemlösung.

Klar gehen die Protokolländerungen auf die Vermutung ein, dass es 
Konflikte bei der CANID gibt. Der TE hat aber bestätigt, dass er dies 
bedacht hat. (Beim Protokoll, nicht notwendigerweise bei der 
Implementierung)

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Julian schrieb:
> Die höchswertige ID im Arbitrations-Segment kommt durch. Ein Teilnehmer
> hört sein Telegramm selber ab und überprüft somit, ob es eine Kollision
> gab, wenn z.B. nicht das auf dem Bus anliegt, was er gesendet hat.

 Die niedrigstwertige ID.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
paul schrieb:
> Beim CAN werden Nachrichten zyklisch gesendet. In deinem Fall sollten
> die Sensorwerte also von den Slaves zum Master gesendet werden.

Das ist auch seitens der Software im Master einfacher und robuster. Die 
besteht beispielhaft aus 3 Teilen:

(1) kriegt von allen Slaves regelmässig Statusberichte und legt sie 
mitsamt Timestamp in den Speicher. Kann u.U. schon im Interrupt 
passieren. Oder direkt in der CAN-Hardware, wenn die mit ausreichend 
vielen ID-spezifischen Mailboxen arbeitet.

(2) nutzt diese Daten aus dem Speicher für die Steuerung oder 
Überwachung, sofern gültig (also nicht veraltet und in sinnvollem 
Zustand).

(3) meckert ab und zu bei ungültigen Daten, weil offenbar ein Slave 
defekt ist.

: Bearbeitet durch User
Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist der Traffic auf dem CAN Bus zu hoch? Wenn zu viel auf dem Bus los 
ist, dann kommen nicht mehr alle Daten durch.

Autor: xxx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bis jetzt habe ich noch fast keine sinnvollen Antworten gesehen, die 
beim Problem helfen, schade eigentlich. Die meisten Antworten sind nur 
von der Art: "warum machst du das so? Das macht man doch so ... oder so 
...!"

Um hier weiterzukommen geht es nicht ohne einen gewissen Aufwand (ein 
CAN Analyser wäre jetzt nicht schlecht).

1. herausfinden ob es ein Hardware oder ein Software Problem ist
=> auf dem Modul, das anscheinend Probleme macht, eine Schleife 
programmieren in der ständig (z.B. alle 100 ms) ein CAN Frame gesendet 
wird
(Anmerkung: es macht Sinn, dieses "Testprogramm" zuerst auf einem der 
funktionsfähigen Module laufen zu lassen um zu sehen ob alles 
wunschgemäß funktioniert, denn in dem Testprogramm könnten ja auch 
Fehler sein)
=> auf dem Master kontrollieren ob die Nachricht ankommt

Kommt die Nachricht auf dem Master an, dann ist die Hardware schon mal 
i.O.

Kommt die Nachricht nicht an, dann alle anderen Module vom Bus nehmen 
und dann testen. -> mit hoher Wahrscheinlichkeit ein Hardwareproblem

Anmerkung:
Ist es bei CAN nicht auch so, das bei aktiven CAN Controllern der 
Empfang quitiert wird (irgendein Bit wird auf Low gezogen, dann weiss 
der Sender das die Nachricht empfangen wurde). Passive CAN controller 
machen das nicht. Was wäre jetzt, wenn die einzelnen Module (oder eines) 
die Nachricht korrekt empfängt und dementsprechend quitiert, aber der 
Master die Nachricht nicht empfängt? Wäre so etwas denkbar?

Wenn die Hardware Tests OK sind, dann bleibt nur ein Softwareproblem. 
Hierzu sollte wieder überall die Originalsoftware installiert werden und 
am Master sollte man alle empfangenen Nachrichten loggen (alternativ ein 
CAN ANalyser, oder Oszi).

Autor: xxx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus M. schrieb:
> Ist der Traffic auf dem CAN Bus zu hoch? Wenn zu viel auf dem Bus los
> ist, dann kommen nicht mehr alle Daten durch.

Denke ich nicht, angeblich werden die Sensoren gepollt und senden nur 
auf ANfrage einen CAN Frame. Außerdem sind es nur 5 Stationen.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, leider wenig sinnvolles hier.
CAN regelt die Übertragung, welches Protokoll man sich ausdenkt ist 
erstmal völlig egal. So wie es der TO macht geht es problemlos.

Ich würde vorschlagen mal nachzuschauen ob der CAN Controller im PIC ein 
Fehler anzeigt. Den Typ kenne ich nicht genau, aber da gibt es sicher 
ein Fehlerregister das einem sagt ob er in einem Fehlerzustand (zB Bus 
passive) ist. Das ist erstmal das einfachste und aussagekräftiger als 
eine Oszimessung in dem Fall.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
COMSTAT heisst das Register. Lies das mal aus, wenn alles gut ist müsste 
es auf 0 stehen.

Autor: Daniel W. (albireo_01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das COMSTAT BIT werde ich mal lesen, mal sehen was hier steht.

Grundsätzlich verstehe ich im Moment nicht wer bei einer CAN Nachricht 
das Acknowledge sendet, wenn alle Teilnehmer empfangen können...alle?

Autor: H.Joachim Seifert (crazyhorse)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alle, die die Botschaft formal richtig empfangen. D.h. im Normalfall 
tatsächlich alle anderen.

: Bearbeitet durch User
Autor: Daniel W. (albireo_01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
okay, also ist das Acknowledge im positiven Fall rezessiv, ansonsten 
dominat also 0. Dann weis der Sender nur das das Paket fehlerhaft war 
aber nicht wer es falsch empfangen hat (ist ja auch egal).

Autor: xxx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das habe ich bei Wikipedia gefunden:
(Vor allem der letzte Satz)

Der Acknowledge-Slot wird verwendet, um den Empfang eines korrekten 
CAN-Frames zu quittieren. Jeder Empfänger, der keinen Fehler feststellen 
konnte, setzt einen dominanten Pegel an der Stelle des ACK-Slots und 
überschreibt somit den rezessiven Pegel des Senders. Im Falle einer 
negativen Quittung (rezessiver Pegel) muss der fehlererkennende Knoten 
nach dem ACK-Delimiter ein Error-Flag auflegen, damit erstens der Sender 
vom Übertragungsfehler in Kenntnis gesetzt wird und zweitens um 
netzweite Datenkonsistenz sicherzustellen. Wird der rezessive Pegel von 
einem Empfänger durch einen dominanten überschrieben, kann der Absender 
jedoch nicht davon ausgehen, dass das Telegramm von allen anderen 
Empfängern erhalten wurde.

Autor: Steffen Rose (steffen_rose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
xxx schrieb:
> Ist es bei CAN nicht auch so, das bei aktiven CAN Controllern der
> Empfang quitiert wird (irgendein Bit wird auf Low gezogen, dann weiss
> der Sender das die Nachricht empfangen wurde). Passive CAN controller
> machen das nicht.

Du meint CAN Controller im Error Passive Mode? Sie sind nur im 
Fehlerfall ruhig. Im Gutfall, wie dem Acknowledge, spielen sie noch mit.

Ruhig ist er im Listen-only mode. Aber um den geht es hier ja nicht.

Soweit ich es verstanden habe, ist nicht ein spezielles Modul betroffen, 
sondern das jeweils 6.Modul bringt das System zum erliegen.Egal welches 
der Module man zuletzt ins System einbringt. Daher auch die vielen 
Spannungsbezogenen Hinweise.

Hans schrieb:
> Den Typ kenne ich nicht genau, aber da gibt es sicher
> ein Fehlerregister das einem sagt ob er in einem Fehlerzustand (zB Bus
> passive) ist. Das ist erstmal das einfachste und aussagekräftiger als
> eine Oszimessung in dem Fall.

Hat man einen Oszi zur Hand, kommt man hier schneller zu Erkenntnissen. 
Die Fehlerregister helfen, führen aber zu weiteren Spekulationen.

Daniel W. schrieb:
> Grundsätzlich verstehe ich im Moment nicht wer bei einer CAN Nachricht
> das Acknowledge sendet, wenn alle Teilnehmer empfangen können...alle?

Natürlich alle, die es empfangen haben. Wer einen Fehler erst jetzt 
bemerkt hat, zieht es in die Länge und macht darauf spätestens jetzt ein 
Error Frame. Kein Acknowledge würde insofern darauf hindeuten, dass 
keiner mithört.

Daniel W. schrieb:
> okay, also ist das Acknowledge im positiven Fall rezessiv, ansonsten
> dominat also 0. Dann weis der Sender nur das das Paket fehlerhaft war
> aber nicht wer es falsch empfangen hat (ist ja auch egal).

Kein Acknowledge heißt somit nicht, dass es fehlerhaft war.

Zum Wiki Zitat:
Das Error Frame wird sofort beim Erkennen des Fehlers auf den Bus 
gelegt.
Ein Fehler zu einem so späten Zeitpunkt kann somit nur den Ack Delimiter 
betreffen (dominant statt rezessiv). Ich wäre mir hier aber unsicher, ob 
diese Situation überhaupt noch erkannt wird.
Führt aber hier eh zu weit.

Autor: MiWi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel W. schrieb:
 Ich habe die Can
> Parameter/Geschwindigkeit geändert, habe die slope-control Werte
> geändert, nichts hilft. Ich bin jetzt am Ende meiner Ideen, könnt ihr
> mir hier noch einen Tipp geben was hier das Problem sein könnte?
>


Was hälst Du davon einmal einen Schaltplanauszug zu Deinem System zu 
liefern und auch zu zeigen wie der Bus aufgebaut ist? Sprich: eine 
Zeichnung, in der zu sehen ist ob Du Stichleitungen etc hast.

Bei einer Bitzeit von 100us kann das Signal schon ziemlich devastiert 
werden wenn das eine Spaghetti-Sternverkabelung mit größeren Kabellängen 
ist...

MiWi

Autor: Amateur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Daniel
Hast Du mal durch das Abklemmen der anderen Teilnehmer versucht 
herauszubekommen, ob sich da bestimmte, funktionierende Kombinationen 
abzeichnen?
Dein Ärger begann ja mit der Nummer 6.
Läuft diese (6) allein im System?
Gibt es bestimmte Kombinationen - außer der beschriebenen (1 – 5), die 
Laufen?

Vielleicht kann man auf diesem Wege etwas erkennen. Du weigerst Dich ja 
weitere Informationen rauszulassen.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Steffen R. schrieb:
> Hat man einen Oszi zur Hand, kommt man hier schneller zu Erkenntnissen.
> Die Fehlerregister helfen, führen aber zu weiteren Spekulationen.

Einspruch. Wenn man mit dem Oszi auf den Bus geht wenn schon alle auf 
passive oder off stehen (was schnell gehen kann), dann sieht man nur 
dass auf dem Bus tote Hose ist, das bringt wenig Erkenntnis. Wenn man 
mit dem Oszi (und am besten Dekodierung) zur richtigen Zeit am richtigen 
Ort misst ist natürlich alles gut.

@Daniel: COMSTAT ist kein Bit sondern ein ganzes Register mit allen 
möglichen CAN Fehlern.

Autor: Steffen Rose (steffen_rose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hans schrieb:
> Wenn man mit dem Oszi auf den Bus geht wenn schon alle auf
> passive oder off stehen (was schnell gehen kann), dann sieht man nur
> dass auf dem Bus tote Hose ist, das bringt wenig Erkenntnis.

Damit weißt du, dass alle Geräte nicht senden.
Und du kennst den Pegel.

Und ja, bei Busoff ist es egal ob Oszi oder Register. Es gibt aber viele 
Probleme dazwischen.

Autor: Daniel W. (albireo_01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich habe jetzt mit dem Oszi nachgemessen, wenn der 6. Sensor nicht 
dran ist (Stromversorgung aus, also +16V abgeklemmt Masse und CAN H und 
L sind noch dran), werden kurze CAN Nachrichten geschickt ansonsten ist 
Ruhe auf dem Bus. Wenn der 6. Sensor dran ist, wird kurz versucht eine 
Nachricht zu schicken und dann ist Dauerfeuer auf dem Bus, bis ich den 
Sensor vom Strom trenne, also +16V am Sensor wieder abmache. So richtig 
kann ich mir da keinen Reim darauf machen. Doppelte Can IDs sind 
ausgeschlossen, das habe ich nochmal gecheckt. Auch den transceiver IC 
der Zentrale habe ich jetzt vorsichtshalber getauscht.

Und wie schon geschrieben ich habe hier mehr als einen Sensor versucht 
und auch schon mit den Funktionierenden getauscht immer der 6 ist zu 
viel. Ich werde morgen noch versuchen das Netzteil zu ersetzen, aber ich 
glaube nicht das das Problem daher kommt.

Ach ja, wenn ich den 6. Sensor mit Strom versorge und den CAN Bus 
abklemme gibt es auch keine Probleme.

Wenn ich nur 1-5 Sensoren nacheinander dazu schalte alles kein Problem, 
dann ist aber Schluss.

Ich werde mir jetzt einen CAN Hub bauen, wenn es nur ein Problem mit der 
Leitungsanpassung ist sollte es dann gehen, wenn nicht ist es eher ein 
Softwareproblem.

: Bearbeitet durch User
Autor: xxx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist mit hoher Wahrscheinlichkeit ein Hardwareproblem oder ein 
Konfigurationsproblem der CAN Controller. Bei mir ist es halt schon sehr 
lange her das ich mit CAN etwas gemacht habe, aber hier gab es ja schon 
sehr kompetente Antworten.

Soweit ich mich noch erinnere, ist es so, das der CAN Controller 
automatisch wiederholt wenn ein Fehler erkannt wird (das ist das 
"Dauerfeuer"). Ich hatte das mal, als die Baudrate falsch eingestellt 
war. -> evtl. ist auch das dann das Problem, bei CAN kann man da relativ 
viel einstellen z.B. mal versuchen den Abtastzeitpunkt etwas nach hinten 
zu verlegen.

Vielleicht die Error Flags des sendenden CAN controller auslesen und 
kontrollieren was da gemeldet wird.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Laufen die µC mit dem internen RC Oszillator?
Wenn die Frequenz bei allen Devices nicht exakt gleich ist kann sich bei 
den CAN Frames ein Bit verschieben und irgend ein Device meldet dann 
NACK. Damit sendet der Sender das Telegramm erneut und schlussendlich 
hat man "Dauerfeuer".
Versuche mal die µC mit Quarz zu betreiben, dann wäre dieser Fehler 
ausgeschlossen.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
NACK kann man nicht melden.

Sobald irgendeiner die Nachricht akzeptiert wird das ACK bit Dominant 
gesetzt. Ein NACK hat man nur wenn niemand die Nachricht erkennt.

Das ist übrigens der Schwachpunkt wenn die Filter und Masken wie bei dir 
so eingestellt werden dass alles durchgeht, dann kann jeder das ACK 
setzen. Sollte aber in deinem Fall kein Problem sein.

Bei "Dauerfeuer" schafft es keiner das ACK Dominant zu setzen.
software würde ich ausschließen. Leitung und Terminierung definitiv auch 
bei der Geschwindigkeit.

Nochmal eine Frage: Sind das 6 exakt gleiche Leiterplatten die du 
anschliesst? Weil es eigentlich nach einem Hardwarefehler klingt, zB 
CANL und CANH vertauscht oder kurzschluss in irgendeine richtung oder 
sowas.

Ich wiederhole den Tipp mit dem COMSTAT Register und behaupte dass 5 
einen Fehler anzeigen und einer nicht, der eine ist dann der Übeltäter.

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hans schrieb:
> Das ist übrigens der Schwachpunkt wenn die Filter und Masken wie bei dir
> so eingestellt werden dass alles durchgeht, dann kann jeder das ACK
> setzen. Sollte aber in deinem Fall kein Problem sein.

ACK ist unabhängig vom Filter. Eine Node ACKed auch dann, wenn ihr 
Filter die Message verwirft.

Autor: Daniel W. (albireo_01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Controller laufen alle mit einem Quarz, die CAN Konfiguration ist 
bei allen gleich, ist ja auch jeweils der selbe Controller. Ich benutze 
übrigens die ECAN Library von Microchip.

Irgendwie bringt der 6. Can Konten einen Fehler in den Bus, daher ja 
auch das Dauerfeuer. Ich vermute jetzt ganz stark ein Anpassungsproblem 
der Bus Leitung oder eine Störeinstrahlung auf die Leitung. So ganz 
sauber sieht die auch nicht aus wenn ich mit dem Oszi auf die Leitung 
gucke.

Ich mache jetzt erst mal zwei Sachen, ich werde den CAN HUB 
zusammenbrutzeln und über diesen dann den 6. Sensor in den Bus hängen. 
Und ich werde jetzt einen Bus simulieren, indem ich alle Sensoren abbaue 
und mit einem neuen Kabel verbinde, das hat meine Faulheit bisher 
verhindert aber ich werde wohl nicht drum rum kommen :-(

Wenn das beides funktioniert ist mein Kabel kaputt oder läuft irgendwo 
parallel zu eine Netzkabel oder einer anderen Störquelle.

Das schöne an Problemen ist, man steigt sehr tief in die Materie ein was 
einen ja auch nicht dümmer macht ;-)

Autor: Daniel W. (albireo_01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alle Sensoren sind exakt gleich aufgebaut, nur die Zentrale ist auf 
einer anderen Platine als Shield für den Raspi gesetzt.

Wie sieht das eigentlich mit der CAN Masse aus, sollte diese geerdet 
werden?

: Bearbeitet durch User
Autor: Dietrich L. (dietrichl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel W. schrieb:
> Ach ja, wenn ich den 6. Sensor mit Strom versorge und den CAN Bus
> abklemme gibt es auch keine Probleme.
>
> Wenn ich nur 1-5 Sensoren nacheinander dazu schalte alles kein Problem,
> dann ist aber Schluss.

Hast Du auch die Nr. 6 mal alleine angeschlossen?

Denn ich sehe in dem Zusammenhang 2 Fehlermöglichkeiten:
1. Nr. 6 beeinflusst den Bus elektrisch so, die andere daraufhin 
Dauerfeuer machen
2. Nr. 6 macht selber Dauerfeuer.

Es wäre also sinnvoll, mal nur Nr. 6 anzuschließen und dann nacheinander 
1-5 dazu hängen.
Die Ergebnisse könnten bei der Suche nach der Ursache hilfreich sein.

Autor: Steffen Rose (steffen_rose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel W. schrieb:
> Ich werde mir jetzt einen CAN Hub bauen, wenn es nur ein Problem mit der
> Leitungsanpassung ist sollte es dann gehen, wenn nicht ist es eher ein
> Softwareproblem.

Das hättest du anhand der Signale auf dem Oszi bewerten können.

xxx schrieb:
> Soweit ich mich noch erinnere, ist es so, das der CAN Controller
> automatisch wiederholt wenn ein Fehler erkannt wird (das ist das
> "Dauerfeuer").

Mmh. Ja. Ich würde meinen, dieses Verhalten tritt eigentlich nur bei 
zwei gleichzeitig am Bus hängenden CAN Controllern auf. Und beide müssen 
Senden wollen. Einer sendet und geht aufgrund der Error Frames in den 
Busoff. Dem anderen Fehlen dann die Ack.

Wenn hier der sechste Sensor Mist sendet und dadurch in den Busoff geht, 
sollte der Rest noch funktionieren. Allerdings erwarte ich, dass die 
restlichen Knoten im Error Passive sind. Wenn diese Knoten von Haus aus 
jedoch schon im Error Passive sind, könnte es etwas anders aussehen.
Jetzt wäre COMSTAT für das funktionierende Netz interessant (und 
natürlich auch vom Problemnetz.)

Oder vielleicht ein Softwarefehler, der alle Knoten beim Request des 
sechsten Sensors senden läßt?

Die Abstände der Nachrichten wäre interessant. Manchmal kann man daraus 
ablesen, ob es eine Sendewiederholung ist oder ob die Knoten per 
Software so schnell senden wollen. Aber bei 10k hab ich da wenig 
Hoffnung, dies zu unterscheiden.

Autor: Cyborg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In der Vergangenheit sind doch in div. Threads mal Probleme diskutiert
worden, wenn Sende-/Empfangsmodule an so einem Bus Zentral an einer
Stromversorgung und damit nicht galvanisch getrennt betrieben wurden.
Wenn die Masseschleife dann immer größer wurde, wird das Problem erst
akut. Wenn der TO nicht mal ein Blockschaltbild hier veröffentlicht,
kann man rum raten wie Blöde ohne dem Problem näher zu kommen.
Wenn das das Problem ist, würde ich mal die Module dezentral mit
Batterien betreiben. Die Masse wird beim Bus nicht mitgeführt, was
aber hier auch schon kontrovers diskutiert wurde. Man kann es ja
optional machen ob es da einen Unterschied gibt.

xxx schrieb:
> Um hier weiterzukommen geht es nicht ohne einen gewissen Aufwand (ein
> CAN Analyser wäre jetzt nicht schlecht).

Der Meinung bin ich auch und daher sollte man sich da nach einer
Lösung umschauen oder selbst eine Lösung zusammen zu klicken.
https://www.google.de/?gws_rd=ssl#q=can-analysator
Ein Datenmonitor könnte ja schon reichen. So ein Laptop mit
passender Schnittstelle um auf dem Bus zu schnüffeln könnte doch
reichen. Ein Oszilloskop hilf da wenig.

Autor: Route 66 (route_66)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Cyborg schrieb:
> Die Masse wird beim Bus nicht mitgeführt, was
> aber hier auch schon kontrovers diskutiert wurde.

Genau. Die ist ja als Karosserie im ursprünglichen CAN-Umfeld überall 
sowieso vorhanden.

Autor: Steffen Rose (steffen_rose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Cyborg schrieb:
> In der Vergangenheit sind doch in div. Threads mal Probleme diskutiert
> worden, wenn Sende-/Empfangsmodule an so einem Bus Zentral an einer
> Stromversorgung und damit nicht galvanisch getrennt betrieben wurden.
> Wenn die Masseschleife dann immer größer wurde, wird das Problem erst
> akut. Wenn der TO nicht mal ein Blockschaltbild hier veröffentlicht,
> kann man rum raten wie Blöde ohne dem Problem näher zu kommen.
> Wenn das das Problem ist, würde ich mal die Module dezentral mit
> Batterien betreiben. Die Masse wird beim Bus nicht mitgeführt, was
> aber hier auch schon kontrovers diskutiert wurde. Man kann es ja
> optional machen ob es da einen Unterschied gibt.

Ich nehme an, dass der CAN nicht galvanisch getrennt ist. Im allgemeinen 
würde man dies zumindest erwähnen. Insofern sollte die Spannungs-Masse 
dem CAN-GND entsprechen, oder?

Cyborg schrieb:
> xxx schrieb:
>> Um hier weiterzukommen geht es nicht ohne einen gewissen Aufwand (ein
>> CAN Analyser wäre jetzt nicht schlecht).
>
> Der Meinung bin ich auch und daher sollte man sich da nach einer
> Lösung umschauen oder selbst eine Lösung zusammen zu klicken.
> https://www.google.de/?gws_rd=ssl#q=can-analysator
> Ein Datenmonitor könnte ja schon reichen. So ein Laptop mit
> passender Schnittstelle um auf dem Bus zu schnüffeln könnte doch
> reichen. Ein Oszilloskop hilf da wenig.

Da der Raspi verwendet wird und dort vermutlich socketCAN zum Einsatz 
kommt, könnte man als ersten Versuch auch hier Infos abziehen 
(can_dump). Ansonsten wäre es gut hier einen Analyzer zu haben, den man 
auch in den Listen-only Mode schalten kann. Ansonsten kommt man nicht an 
die Nachricht ran, die dauerhaft gesendet wird, wenn dies durch einen 
Ack Error verursacht wird.
Der müßte dann entsprechend Cyborgs Vorschlag ein extra Teilnehmer sein, 
da scheinbar auch der raspi in einen Fehlerzustand geht.

Die anderen Nachrichten interessieren hier herzlich wenig. Wollen ja 
keinen Fehler in seinem Protokoll suchen.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Cyborg schrieb:
> Die Masse wird beim Bus nicht mitgeführt, was
> aber hier auch schon kontrovers diskutiert wurde.

Es kann ohne GND gehen, da sich die Teilnehmer quasi an der eigenen 
Stiefelstrippe (Eingangsstrom) hochziehen. Zuverlässig ist das 
allerdings nicht. Und erst recht nicht störsicher.

Die CAN-L/H dürfen gegenüber GND nur innerhalb -5V .. +10V liegen. Daher 
muß man GND immer mit anschließen.

Autor: Cyborg (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Die CAN-L/H dürfen gegenüber GND nur innerhalb -5V .. +10V liegen. Daher
> muß man GND immer mit anschließen.

Erscheint mir nicht als Grund relevant zu sein.
Du weißt aber auch, dass nach 30 Meter die Masse an der Quelle nicht
die gleiche Masse wie am Ende ist? Ein paar Ohm und noch so einiges
mehr kommen da schon zusammen. Im Kfz sind das nur ein paar Meter und
abschirmend wirkt so eine Karosserie auch. Wie in den Modulen da noch
Zusatzmaßnahmen zur galvanischen Trennung getroffen werden, weiß ich
nicht.
Wenn der TO nicht mit etwas Schematischem mal rüber kommt, wird der
Thread sowieso verhungern, weils dann nicht weiter geht. Das alte Lied.

Autor: Wumo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Cyborg schrieb:
> Du weißt aber auch, dass nach 30 Meter die Masse an der Quelle nicht
> die gleiche Masse wie am Ende ist?

Nach 30m hast du auf der Masse Spannungsunterschiede bis zu 10V?
Da würde ich doch mal nachdenklich werden...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Cyborg schrieb:
> Du weißt aber auch, dass nach 30 Meter die Masse an der Quelle nicht
> die gleiche Masse wie am Ende ist?

Bei DeviceNet werden GND und -24V getrennt geführt und sind nur im 
Netzteil miteinander verbunden und geerdet.
Die +/-24V Leitungen sind auch deutlich dicker, so daß kaum >5V Abfall 
auf den -24V auftreten sollten. Daher kann -24V als GND für den 
Transceiver verwendet werden.

Autor: Stefan K. (stefan64)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schreib mal die Firmware Deiner Teilnehmer testweise so um, dass nur 
einer der Teilnehmer sendet und die anderen garantiert still bleiben.

Gruß, Stefan

Autor: Paul Baumann (paul_baumann)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Stefan K. schrieb:
> Schreib mal die Firmware Deiner Teilnehmer testweise so um, dass nur
> einer der Teilnehmer sendet und die anderen garantiert still bleiben.

Das ist ein Verhalten, das man sich auch von den Leuten in den sog. 
TalgShows
wünscht.
:)
mfG Paul

Autor: temp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich verstehe an der Stelle noch nicht was das alles mit der Verkabelung 
oder Spannungsabfällen zu tun haben soll. Hast du die 6 Teilnehmer nicht 
vor dir liegen und mit ein paar cm-Kabel zusammengeschlossen? Wenn nicht 
ist es so als ob man ein Aquarium baut und als erstes die Fische 
kauft....

Autor: Wumo (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
temp schrieb:
> Hast du die 6 Teilnehmer nicht
> vor dir liegen und mit ein paar cm-Kabel zusammengeschlossen?

Daniel W. schrieb:
> Und ich werde jetzt einen Bus simulieren, indem ich alle Sensoren abbaue
> und mit einem neuen Kabel verbinde, das hat meine Faulheit bisher
> verhindert aber ich werde wohl nicht drum rum kommen :-(
>
> Wenn das beides funktioniert ist mein Kabel kaputt oder läuft irgendwo
> parallel zu eine Netzkabel oder einer anderen Störquelle.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> ACK ist unabhängig vom Filter. Eine Node ACKed auch dann, wenn ihr
> Filter die Message verwirft.

Stimmt, da lag ich falsch.

Autor: Daniel W. (albireo_01)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So sieht übrigens der Can BUS aktuell aus wenn er im Fehlermodus ist, 
wird da einer schlau daraus? Gelb CanH Blau CanL

Viele Grüße
Daniel

: Bearbeitet durch User
Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitte mal die vielen Fragen von oben erst mal beantworten.

Autor: Steffen Rose (steffen_rose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Deine Einstellungen sind mystisch und für mich ist nicht erkennbar, 
welche absoluten Spannungen zu sehen sind.

CAN-L scheint mir ein Übersprechen von CAN-H zu zeigen und ist ansonsten 
tot. Verdrahtungsfehler? CAN-L nicht angeschlossen.

Der Peak dürfte der Sender sein, der sein eigenes Signal nicht 
zurücklesen kann.

(Sender Error Passiv = 18bit rezessiv zwischen zwei Versuchen)

Ist aber geraten.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel W. schrieb:
> So sieht übrigens der Can BUS aktuell aus wenn er im Fehlermodus ist,
> wird da einer schlau daraus? Gelb CanH Blau CanL

CAN_H und CAN_L gleichsinnig?
CAN_H mit 5V/div und CAN_L mit 0,1V/div?

Autor: Thomas O. (kosmos)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das sollte doch gegenläufig sein.

Autor: CAN (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Du betreibst den MCP2551 außerhalb der Spezifikation. Die minimal 
erlaubte Bitfrequenz ist 16kbit/s.

Dein Oszibild zeigt schön das in Kapitel 1.5 TXD Permanent Dominant 
Detection beschriebene Verhalten, dass nach 1,25 ms low abgeschaltet 
wird.

Bevor du also weiter suchst, erhöhe erst mal die Frequenz oder nimm 
einen Transceiver der 10 kit/s erlaubt.

Momentan produzierst du bei jedem CAN-Fehler einen Errorframe, wodurch 
sich dann der Transceiver ausschaltet. So wirst du auf keinen grünen 
Zweig kommen.

Autor: Daniel W. (albireo_01)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

ich habe den Fehler gefunden! Es war ein Fehler auf der Platine der 
Sensoren, ein Schriftzug hat CAN-L mit Vdd des Sensors Verbunden. Bild 
im Anhang. Ich staune das das dann überhaupt funktioniert hat, spricht 
dafür, dass CAN ein sehr robustes Protokoll ist.

Danke für Eure Unterstützung!

Wegen eurer Tipps werde ich meine Software wohl auch dahingehend ändern, 
dass die Sensoren ihre Daten permanent senden, das scheint mir doch 
einige Vorteile zu haben.

Viele Grüße
Daniel

: Bearbeitet durch User
Autor: Max707 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel W. schrieb:
> Hallo Leute,
>
Ich staune das das dann überhaupt funktioniert hat, spricht
> dafür, dass CAN ein sehr robustes Protokoll ist.
>

>
> Viele Grüße
> Daniel

Und ich staune immer wieder,(sowohl über die Fragen und antworten), daß 
für so einfach zu findene Fehler fast 80 Postings erforderlich wurden...

Autor: Daniel W. (albireo_01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man gute Augen hat ist der Fehler bestimmt leicht zu finden, leider 
hat mich die Natur hier etwas benachteiligt :-(

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel W. schrieb:
> Wenn man gute Augen hat ist der Fehler bestimmt leicht zu finden

Und der Design-Rule-Check hat Dir sowas durchgehen lassen?

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel W. schrieb:
> Ich staune das das dann überhaupt funktioniert hat, spricht
> dafür, dass CAN ein sehr robustes Protokoll ist.

Ich staune noch mehr darüber, dass das Layout überhaupt so in die 
Fertigung gegangen ist. Hat der DRC dort keine Fehlermeldung 
geschmissen?
Fehler im CAD oder Nachlässigkeit?

Das hätte viele Zeit gespart - ein Tastendruck ...

Autor: Daniel W. (albireo_01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sieht so aus...:-(

Gerade noch mal probiert, DRC meckert nicht, EAGLE 6.4.

: Bearbeitet durch User
Autor: Sven K. (svenk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sicher das Du alle Layer eingeschaltet hast, der muss mindestens ein 
Warning ausgeben!
Hänge doch mal die Eagle Datei an.

Gruß Sven

Autor: pegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe noch eine kurze Frage zur Verlegung.
Daniel hat 2x2 ungeschirmte Telefonleitung verwendet.
Die hätte ich auch da. CAN Geschwindigkeit auch so 10kb/s.
Ist es möglich die teilweise in den Stromkabel Kanal zu verlegen?
So ca. 8-10m von 40m?

Danke.

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel W. schrieb:
> Gerade noch mal probiert, DRC meckert nicht, EAGLE 6.4.

Das kommt mir sehr merkwürdig vor. Eagle 6.6 schmeißt einen bei 
überlappendem Text im Bottom Layer mit Overlap-Fehlern zu.

Autor: Daniel W. (albireo_01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Kabel liegen auch parallel zu Stromkablen etwa 10m , wie es 
aussieht ist das kein Problem, weil es jetzt perfekt funktioniert :-)

Autor: Daniel W. (albireo_01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja stimmt, war wohl mein Fehler. CRC klappt jetzt auch mit dem Text, 
also wie immer der Fehler sitzt for dem Computer.

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Ist es möglich die teilweise in den Stromkabel Kanal zu verlegen?

Möglich, aber wohl nur erlaubt, wenn du die einschlägigen VDE 
Vorschriften dabei beachtest.

Autor: pegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel W. schrieb:
> Meine Kabel liegen auch parallel zu Stromkablen etwa 10m

Danke. Dann probiere ich das auch.

Autor: Max 707 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist ein eindeutiger Design Fehler! Die Leitungen gehören getrennt.

Was heute mal funktioniert hat muss morgen nicht auch noch 
funktionieren...

Dann viel Spaß bei der Fehlersuche...

Autor: asdf (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Max 707 schrieb:
> Das ist ein eindeutiger Design Fehler! Die Leitungen gehören
> getrennt.
>
> Was heute mal funktioniert hat muss morgen nicht auch noch
> funktionieren...
>
> Dann viel Spaß bei der Fehlersuche...

Wovon sprichst du? Was ist ein Designfehler? Welche Leitungen gehören 
wovon getrennt?

Welche Fehlersuche? Daß der Fehler schon längst gefunden wurde, ist dir 
bestimmt entgangen?

Daniel W. schrieb:
> ich habe den Fehler gefunden!

Autor: posti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Zur Parallelverlegung mit Netzleitungen: Dafür ist EIB-Kabel zugelassen.
Der Aufbau unterscheidet sich (zumindest) nicht (großartig) von einem 
normalem IY(ST)Y=Telefonkabel.


Wenn's also etwas VDE-konform werden darf, nimm das 'grüne Telefonkabel' 
(=EIB-Kabel, 4 Drähte=2 Pärchen=ro/sw & ws/ge).

Alternativ musst Du damit leben, daß Du besser hier nicht erwähnst, was 
und wo Du verlegt hast, da dann hier wieder konstruiert wird, bis der 
Arzt mit der Jacke kommt :)

MfG

Autor: pegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In Ordnung. Überredet.

20€ für 50m von dem grünen ist im Rahmen.
Da es für Neuverlegung sein soll ist das sicher besser als das 
mindestens 20 Jahre alte grau Telefonkabel.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die CAN Leitunen sollten mit einer Supressordiode noch geschützt sein: 
NUP2105L
Damit das nicht bei jedem kleinen Gewitter durchschlägt.

Autor: Thomas O. (kosmos)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Habe in einem Neubau letztens ein rotes EIB/KNX Kabel gesehen weiß 
jemand ob sich hier was geändert hat.

Autor: Hans (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hans schrieb:
> Weil es eigentlich nach einem Hardwarefehler klingt, zB
> CANL und CANH vertauscht oder kurzschluss in irgendeine richtung oder
> sowas.

Der Punkt geht wohl an mich.

Autor: hp-freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der hat einige Videos zum Thema gemacht:

Youtube-Video "CAN-Bus Fehlerbilder - 100kBaud Bus"

Sehr lehrreich.

Beitrag #4863919 wurde von einem Moderator gelöscht.
Autor: Huh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rabenstein schrieb im Beitrag #4863919:
> komplizierten Drahtverhau

OOOch, eine Doppelader möchte ich nicht gerade als "komplizierten 
Drahtverhau" bezeichnen.

Außerdem frage ich mich, wie du z.B. die CAN-Arbitrierung über Funk 
lösen willst.

Jetzt bist du am Zug :-)

Autor: Felix F. (wiesel8)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus M. schrieb:
> Die CAN Leitunen sollten mit einer Supressordiode noch geschützt sein:
> NUP2105L
> Damit das nicht bei jedem kleinen Gewitter durchschlägt.
Braucht man das für jeden "Sensor" oder nur 1x am gesamten Bus?

mfg

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Felix F. (wiesel8)

>> Die CAN Leitunen sollten mit einer Supressordiode noch geschützt sein:
>> NUP2105L
>> Damit das nicht bei jedem kleinen Gewitter durchschlägt.

>Braucht man das für jeden "Sensor" oder nur 1x am gesamten Bus?

An jedem Sensor.

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oder die PESD2CAN Doppeldiode.

Autor: H.Joachim Seifert (crazyhorse)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kommt auch ein bisschen auf den Einbauort an. Festverdrahtet und zu 
Hause und richtig angeklemmt (Masse zuerst) passiert auch ohne 
Schutzdioden nichts. Im industriellen Umfeld unverzichtbar.

Autor: Alex W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Paul B. schrieb:
> Stefan K. schrieb:
>> Schreib mal die Firmware Deiner Teilnehmer testweise so um, dass nur
>> einer der Teilnehmer sendet und die anderen garantiert still bleiben.
>
> Das ist ein Verhalten, das man sich auch von den Leuten in den sog.
> TalgShows
> wünscht.
> :)
> mfG Paul

Oder von Paul Baumann

Autor: Peter Dannegger (peda)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
H.Joachim S. schrieb:
> Im industriellen Umfeld unverzichtbar.

Wir nutzen CAN >20 Jahre in Produkten, es sind wohl 1 oder 2 PCA82C251 
gestorben, also nicht der Rede wert.
Damals wurden noch keine Schutzdioden und EMV-Drosseln verwendet, 
trotdem gab es keine Probleme mit CE.
Stecker sind ganz normale D-Sub 9, also kein voreilender GND und die zu 
steuernden Geräte erzeugen bis 15kV.

Autor: Thomas Forster (igel)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Stecker sind ganz normale D-Sub 9, also kein voreilender GND

CAN_GND wird also mit dem Bus mitgezogen? Wie ist diese Masse dann an 
die Schaltungsmasse gekoppelt?

Was hältst du vom Vorschlag auf dem Bild um einen Massebezug 
herzustellen?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf dem D-Sub 9 sind noch +24V. Die versorgen über Spannungsregler den 
PCA82C251 und 2 Optokoppler HCPL0710. Der MC (z.B. T89C51CC01) ist somit 
vom CAN galvanisch getrennt. +24V-GND und CAN-GND sind am 24V-Netzteil 
geerdet. An den beiden Enden des CAN-Stranges sind Abschlußwiderstände 
124R.

Autor: Thomas Forster (igel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Auf dem D-Sub 9 sind noch +24V. Die versorgen über Spannungsregler den
> PCA82C251 und 2 Optokoppler HCPL0710.

Okay, Danke für diese Schaltungsvariante.

Autor: Rabenstein (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Huh schrieb:
> Außerdem frage ich mich, wie du z.B. die CAN-Arbitrierung über Funk
> lösen willst.

Gar nicht :)

Autor: Huh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rabenstein schrieb:
> Huh schrieb:
>> Außerdem frage ich mich, wie du z.B. die CAN-Arbitrierung über Funk
>> lösen willst.
>
> Gar nicht :)

Das ist mir schon klar.
Aber wer mit solchen altklugen Vorschlägen daher kommt, sollte ja auch 
wissen, wie das genau gehen soll :-)

Autor: Cyblord ---- (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Huh schrieb:
> Rabenstein schrieb:
>> Huh schrieb:
>>> Außerdem frage ich mich, wie du z.B. die CAN-Arbitrierung über Funk
>>> lösen willst.
>>
>> Gar nicht :)
>
> Das ist mir schon klar.
> Aber wer mit solchen altklugen Vorschlägen daher kommt, sollte ja auch
> wissen, wie das genau gehen soll :-)

Er macht das ALOHA Protokoll ;-)

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Auf dem D-Sub 9 sind noch +24V. Die versorgen über Spannungsregler
> den
> PCA82C251 und 2 Optokoppler HCPL0710. Der MC (z.B. T89C51CC01) ist somit
> vom CAN galvanisch getrennt. +24V-GND und CAN-GND sind am 24V-Netzteil
> geerdet. An den beiden Enden des CAN-Stranges sind Abschlußwiderstände
> 124R.

Sitzen die Optokoppler nach dem Transceiver in den CAN Leitungen oder 
wie trennst du sonst die Versorgungsspannung des Transceivers?
Ich benutze immer einen DC/DC und einen 2-kanaligen ADUM vor dem 
Transceiver...

Autor: Thomas Forster (igel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd schrieb:
> Sitzen die Optokoppler nach dem Transceiver in den CAN Leitungen

Ist das jetzt davor oder danach?

Ich habe Peda so verstanden dass die Optokoppler an TXCAN und RXCAN, 
also zwischen Transceiver und uC sitzen.
Nicht an CANH und CANL.

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit "nach dem Transceiver" hatte ich zum Bus hin gemeint. Also an CAN 
high und low... Aber ich denke das wäre eher unsinnig. Bei mir sitzt der 
ADUM zwischen uC und Transceiver.

Autor: temp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab bei mir im Haus nur CANL und CANH verdrahtet und kein GND. 
Allerdings benutze ich ISO1050 als Treiber (die gibt es jetzt auch bei 
Reichelt) und einen Standard DC/DC Wandler im SIL7 Gehäuse. Das eröffnet 
dann auch die Möglichkeit SELF-Teilnehmer anzubinden wenn der Rest nicht 
SELF ist, je nachdem was für ein Wandler bestückt ist. Ausfälle hatte 
ich dabei noch keinen. Ob die galvanische Trennung wirklich Vorteile 
bring kann man nur spekulieren, solange man noch keine negativen 
Erfahrungen gemacht hat. Ob bei diesem Treiber Schutzdioden wie PESD2CAN 
noch eine wesentliche Verbesserung bringen würde ich auch gern mal 
wissen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.