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
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.
Was für transceiver sind es denn? An und für sich klingt das jetzt nicht kritisch..
Die Abschlusswiderstände hatte ich schon reduziert, auf jeweils 60 Ohm anstatt 120 Ohm. Als Transceiver verwende ich den MCP2551.
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?
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?
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...
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.
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.
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
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.
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
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
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.
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.
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.
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.
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.
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.
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."
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.
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?
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.
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
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.
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 ;-)
>> 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
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).
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.
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.
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.
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)
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.
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
Ist der Traffic auf dem CAN Bus zu hoch? Wenn zu viel auf dem Bus los ist, dann kommen nicht mehr alle Daten durch.
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).
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.
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.
COMSTAT heisst das Register. Lies das mal aus, wenn alles gut ist müsste es auf 0 stehen.
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?
Alle, die die Botschaft formal richtig empfangen. D.h. im Normalfall tatsächlich alle anderen.
:
Bearbeitet durch User
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).
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.
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.
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
@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.
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.
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.
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
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.
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.
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.
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.
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 ;-)
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
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.
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.
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.
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.
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.
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.
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.
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...
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.
Schreib mal die Firmware Deiner Teilnehmer testweise so um, dass nur einer der Teilnehmer sendet und die anderen garantiert still bleiben. Gruß, Stefan
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
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....
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.
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.
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
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
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?
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.
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
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...
Wenn man gute Augen hat ist der Fehler bestimmt leicht zu finden, leider hat mich die Natur hier etwas benachteiligt :-(
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?
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 ...
Sieht so aus...:-( Gerade noch mal probiert, DRC meckert nicht, EAGLE 6.4.
:
Bearbeitet durch User
Sicher das Du alle Layer eingeschaltet hast, der muss mindestens ein Warning ausgeben! Hänge doch mal die Eagle Datei an. Gruß Sven
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.
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.
Meine Kabel liegen auch parallel zu Stromkablen etwa 10m , wie es aussieht ist das kein Problem, weil es jetzt perfekt funktioniert :-)
Ja stimmt, war wohl mein Fehler. CRC klappt jetzt auch mit dem Text, also wie immer der Fehler sitzt for dem Computer.
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.
Daniel W. schrieb: > Meine Kabel liegen auch parallel zu Stromkablen etwa 10m Danke. Dann probiere ich das auch.
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...
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!
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
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.
Die CAN Leitunen sollten mit einer Supressordiode noch geschützt sein: NUP2105L Damit das nicht bei jedem kleinen Gewitter durchschlägt.
Habe in einem Neubau letztens ein rotes EIB/KNX Kabel gesehen weiß jemand ob sich hier was geändert hat.
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.
Der hat einige Videos zum Thema gemacht: https://www.youtube.com/watch?v=OEedDP6T4pM Sehr lehrreich.
Beitrag #4863919 wurde von einem Moderator gelöscht.
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 :-)
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
@ 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.
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.
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
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.
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?
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.
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.
Huh schrieb: > Außerdem frage ich mich, wie du z.B. die CAN-Arbitrierung über Funk > lösen willst. Gar nicht :)
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 :-)
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 ;-)
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...
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.
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.
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.
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.