CAN- "Nachrichten haben IDs, keine Knoten"

Ich habe viele Leute sagen hören, dass CAN-Nachrichten IDs und keine Knoten haben. Ich denke, das könnte daran liegen, dass unabhängig von der Vergabe einer eindeutigen ID für jeden Knoten alle Knoten die Nachrichten erhalten. Außerdem können im Fall einer erneuten Übertragung einer Nachricht doppelte Nachrichten verworfen werden, wenn Nachrichten IDs zugewiesen werden, wenn sie an jeden Knoten gesendet werden.

Aber was ist, wenn ein System 3 Master hat, die mit vielen Slaves sprechen, und alle 3 Master denselben Code ausführen (wie in einem 2-von-3-Abstimmungssystem). In einer solchen Architektur ist es sinnvoll, jedem Knoten eine eindeutige ID zuzuweisen, damit der Slave weiß, welcher Master ihm Daten gesendet hat, und jedem Master eindeutig antworten kann. Ich kann mir auch keine Situation vorstellen, in der ein Knoten eine doppelte Nachricht empfangen könnte, da eine erneute Übertragung nur im Falle einer Fehlererkennung erfolgt und wenn ein Fehler von einem Knoten signalisiert wird, zerstört jeder Knoten, der die Daten empfangen hat, die empfangenen Daten.

Ich bin jetzt verwirrt, weil ich vorhabe, jedem Knoten eindeutige IDs zuzuweisen, und die Master Nachrichten an jeden Knoten senden sollen, basierend auf seiner Knoten-ID (aber die überwiegende Mehrheit der CAN-Experten da draußen ist anderer Meinung). Jeder Nachricht eine eindeutige ID zuzuweisen würde bedeuten, dass, wenn Master A 500 Nachrichten sendet, 500 eindeutige IDs von 2048 möglichen IDs (11-Bit-Identifizierer) von Master A verwendet werden müssen. Die restlichen 500 von Master B und die restlichen 500 von Master C. Alle Erkenntnisse darüber, was ein guter Ansatz wäre, würden sehr geschätzt.

Auch jede Situation, in der eine doppelte Nachricht an einem Knoten ankommen kann, der die Nachricht bereits empfangen hat, wäre eine große Hilfe, da dies eine solide Erklärung dafür wäre, warum jeder Nachricht eine eindeutige ID und kein Knoten gegeben werden muss. Dies wird mir helfen zu verstehen, dass, wenn Master A immer dieselbe Kennung sendet, der Empfänger keine Möglichkeit hat, zu unterscheiden, ob es sich um eine doppelte Nachricht handelt oder nicht.

Antworten (1)

Ich glaube du missverstehst das:

Ich habe viele Leute sagen hören, dass CAN-Nachrichten IDs und keine Knoten haben.

Dies bedeutet nicht, dass jede auf dem Bus gesendete Nachricht eine eindeutige ID haben sollte oder dass Sie niemals in der Lage sein sollten, zu identifizieren, welcher Knoten die Nachricht gesendet hat. Dies bedeutet, dass IDs am besten verwendet werden, um anzugeben, welche Art von Daten gesendet werden, und nicht, wohin die Daten gehen. Wenn Sie beispielsweise einen Temperatursensor haben, der Daten sendet, können Sie eine ID-Nummer zuweisen, die "Temperaturdaten von Sensor Nr. 1" bedeutet. Dann kann jeder Knoten, der sich um Temperaturdaten kümmert, diese empfangen. Viele (die meisten?) CAN-Controller können problemlos mehrere IDs senden und empfangen, daher macht es oft keinen Sinn zu sagen, dass ein Knoten nur eine ID hat.

In Ihrem Fall könnten Sie IDs für "Befehl von Master 1 an Slave 5", "Befehl von Master 2 an Slave 8", "Antwort an Master 3 von Slave 7" usw. erstellen. Ich weiß nicht genug über Ihr System zu sagen, ob das der beste Weg ist.

Ich verstehe nicht, warum Sklaven jedem Meister separat antworten müssen. Wenn dies ein Mehrheitswahlsystem ist, sollte dann nicht eine Sklavenantwort ausreichen? Sie könnten separate Nachrichten-IDs für Fehler haben.

Denken Sie daran, dass alle Knoten alle Nachrichten erhalten. Es ist dem Knoten überlassen, ob er die Nachricht speichert oder nicht.

Ich dachte an ein solches ID-Schema, ID = (Sender-ID + Empfänger-ID). Der Empfänger prüft, ob die Nachricht zu ihm gehört und auch, ob er die Erlaubnis hat, die Daten des Absenders zu verarbeiten. Die vollständigen Daten können nicht in einer einzigen 8-Byte-CAN-Nachricht verarbeitet werden. Zur vollständigen Dekodierung einer Nachricht muss ein Slave ca. 5*8 Byte Daten zurückgeben. Auch was ist mit der Möglichkeit einer doppelten Nachricht???
Auch wenn es viele Slaves gibt (z. B. 100 Knoten), besteht die Wahrscheinlichkeit, dass der Slave mit der niedrigsten ID (dh: ID 4) den Bus weiterhin belegt, sodass höhere IDs ihre Daten nicht senden können. Szenario: Slave 4 sendet seine Daten-->Kurze Zeit, um neue Daten zu bilden, Slave 5 bis 40 haben das Senden ihrer Daten beendet-->Slave 4 sendet neue Daten-->Wie oben wiederholen. Die Sklaven 41 bis 100 werden niemals den Bus bekommen, wenn das so weitergeht, richtig?
Es hört sich so an, als ob Sie ein übergeordnetes Protokoll mit paketierten Daten implementieren möchten. Es gibt viele Möglichkeiten, wie Sie das tun können. Sie könnten ein paar Byte in den Daten für die Sequenzierung zuweisen. Sie könnten auf 29-Bit-IDs umsteigen. Dies hängt von den Fähigkeiten Ihrer Knoten ab.
Um zu verhindern, dass Knoten den Bus in Beschlag nehmen, müssen Sie ihre Übertragungen begrenzen und die Busauslastung niedrig halten. CAN ist ein Low-Level-Protokoll; Es erledigt diese Dinge nicht für Sie, wie es TCP/IP tun würde.
Vielleicht möchten Sie sich vorhandene High-Level-Protokolle ansehen, anstatt Ihre eigenen zu entwerfen: kvaser.com/about-can/higher-layer-protocols
Aus diesem Grund kann ich, anstatt High-Level-Protokolle zu verwenden, den Datenfluss kontrollieren, da es nur 3 Master gegenüber 100 Slaves gibt. Die Master können einen Slave veranlassen, Daten zu geben. Auf diese Weise können alle Slave-Daten abgerufen werden.
Die Arbitrierung zwischen den Mastern kann von der Hardware gehandhabt werden, und die Slaves antworten nicht auf eine Nachricht, die nicht für sie bestimmt ist. Das einzige Problem unter den Mastern wäre, dass 1 Master den Status von Slave 1 früher erhalten könnte als Master 2 oder 3. Dies kann die Synchronisation im 2oo3-Voting-Prozess durcheinander bringen.
Wie sieht es mit der Weiterverbreitungssituation aus? Kann ein Knoten doppelte Nachrichten empfangen?
Das würde ich nicht denken. Eine erneute Übertragung erfolgt nur, wenn ein Fehler vorliegt. Vielleicht möchten Sie mehr über das CAN-Protokoll lesen. Ich empfehle A Comprehensive Guide to Controller Area Network von Wilfried Voss.
"Wenn dies ein Mehrheitsabstimmungssystem ist, sollte eine Slave-Antwort nicht ausreichen?" - Derselbe Code wird in allen 3 Mastern abgelegt. Das sind alle 3 Fragen und alle 3 werden verarbeiten.
CAN- "Nachrichten haben IDs, keine Knoten"
AntwortenHierDatenschutz-Bestimmungen1y, 0v