Hallo, ich plane ein CAN-Netzwerk zwischen einer Zentralsteuereinheit (Master) und 64 IO-Einheiten (Slaves). Der Informationsaustausch ist gegliedert in folgende Nachrichtengruppen: EINGÄNGE AUSGÄNGE Meldeaufforderung vom Master an die Slaves (Broadcast) Rückmeldung von den Slaves zum Master Für den Master verwende ich den XE167 von Infineon. Dieser unterstützt 128 Message Objekte (MO). Damit ich mit diesen klarkomme habe ich folgendes überlegt: Senden: Beim Senden der Telegramme (AUSGÄNGE) vom Master zu den Slaves reicht mir ein M0 im XE167, welches ich vor dem Senden mit dem jeweiligen Identifier beschreibe. Das heißt, ich kann alle Slaves ansprechen mit nur einem Message Objekt im Master. Empfangen: Die Slaves arbeiten ereignisgesteuert, senden also nur bei Bedarf Infos zum Master. Es kann also passieren, daß mehrere Slaves ihre Eingangszustände gleichzeitig übertragen wollen. Damit hier keine Telegramme verlorengehen, muß für jeden Knoten eine eigene Nachricht reserviert werden. Das heißt, die zu übertragenen Objekte der Knoten müssen je einen eigenen Identifier erhalten. Das würde bedeuten, ich benötige im XE167 64 MO für die EINGÄNGE. Ich weiß jetzt nicht genau, wie ich das mit der Reaktion der Slaves auf die Meldeanforderung vom Master realisieren soll. Die vom Master gesendete Meldeaufforderung hat einen Identifier, welcher von allen Slaves gelesen wird. Daraufhin sollen sich diese beim Master melden. Ich denke, ich muß hierfür dieselben M0 verwenden wie für die EINGÄNGE, da ich keine weiteren 64 Identifier mehr frei habe, um für jeden Slave eine eigene Nachricht für die Knotenrückmeldung zu reservieren. Hat jemand eine bessere Idee bzw. entsprechende Erfahrungen? Gruß Holger
Hallo Holger, Ich verstehe deinen letzten Absatz nicht ganz. Haben die Slaves zwei Arten von Nachrichten die sie verschicken? Einmal eine Ereignisgetriggerte, wei du sie im Absatz "Empfangen" beschreibst. Und eine zweite, welche so zusagen die Reaktion auf die Anfrage vom Master ist? Du kannst auf alle Fälle in einer Messagebox (MO) mehrere CAN-Ids annehmen. Jedes MO hat ein Overflow flag, wenn du nur zwei Ids auf ein MO appst erkennst du also recht zuverlässig welche ID verloren gegegangen ist. Man könnte aber auch per PEC eine eingegangene Nachricht sehr schnell aus dem MO heraus holen und danach bearbeiten. Noch als Tip: man könnte das Senden mit einer HW-Queue aus MOs (es sind ja noch welche übrig) vereinfachen und sicherer gestalten. Was aber ein anderes Problem noch ist: Willst du wirklich 65 CAN-Knoten an einem Bus betreiben. Mir fehlt kein Transceiver ein der das zuverlässig schafft. Da der XE167 aber 4 Nodes hat könnte man den als Gateway/Master nutzen und verteilt die 64 Slaves auf vier getrennte (nicht zwingend symetrische) Busse. Gruß, TManiac
Hallo TManiac, erstmal Danke für Deine Tips ! Das mit den 64 Knoten muß ich mal mit unserem Hardwareentwickler besprechen. Zur Software: Du hast das richtig verstanden. Ich habe geplant, daß die Slaves 2 Arten von Nachrichten haben: a) Ereignisgetriggert b) Bestätigungstelegramm als Reaktion auf eine Masteranfrage Und wegen b) habe ich jetzt folgendes Problem: Das Bestätigungstelegramm sollen alle Slaves zum Master schicken, sofern dieser eine entsprechende Anfrage gesendet hat. Das heißt, es werden im Worst Case zeitgleich 64 Telegramme von den Slaves gesendet - als Reaktion auf eine Masteranfrage. Hierbei muß jedes Telegramm mit einem eigenen Identifier versehen werden, damit über die Arbitrierung sichergestellt wird, daß alle Telegramme ordnungsgemäß zum Master gelangen. Wenn die Nachricht zum Master von allen Slaves mit demselben Identifier versehen wäre, kann die Arbitrierung meiner Meinung nach nicht funktionieren. Im Master selbst hätte ich kein Problem, wenn die Telegramme auf ein MO sehr schnell nacheinander eintreffen, da über einen FIFO-Puffer sichergestellt ist, daß keine verloren geht. Eventuell kann ich auch auf diese Anfragebestätigungen der Slaves ganz verzichten. Zum CAN allgemein habe noch eine generelle Frage: Das Protokoll an sich bietet ja eine hohe Fehlersicherheit. Ist es da erforderlich, daß irgendwelche Bestätitungen auf eingegangene Telegramme versendet werden oder kann davon ausgegangen werden, daß ein fehlerfrei abgesendetes Telegramm auch beim Empfänger ankommt ? Wie wird das allgemein in CAN-Netzwerken gehandhabt? Gruß Holger
Holger Betz schrieb: > Telegramme ordnungsgemäß zum Master gelangen. Wenn die Nachricht zum > Master von allen Slaves mit demselben Identifier versehen wäre, kann die > Arbitrierung meiner Meinung nach nicht funktionieren. Korrekt. Aber üblicherweise sind CAN Controller in der Lage, die Handhabung gleichartiger aber aus besagtem Grund verschieden nummerierter IDs über eine Bitmaske zusammenzufassen. Dann ist das nur noch ein Objekt, sind nicht mehr 64. Ist dann nur noch ein Tempoproblem, weil der Controller die fix genug abfischen muss (evtl. können die Slaves mit zufälligem oder aus der ID abgeleitetem Delay antworten).
Hallo Holger, Laut CAN Spec muss sowieso jeder verschiedenartige Nachricht eine eigene ID haben (Multiplexnutzung ausgenommen). Ist ja auch klar, weil die ID ja den Inhalt der Nachricht beschreibt. Die ganzen Bestätigungen über einen FIFO abzufangen ist natürlich auch eine Möglichkeit. Du brauchst aber auch für den FIFO mehrere MOs (je nach Größe) aber eben nicht unbedingt 64 Stück. Deine 64 Antworten werden ja wegen der Arbitierung nicht zeitgleich eintreffen, sondern schön den IDs folgenden (wenn alle Slaves gleich schnell sind). Die Bestätigung über den Bit-Richtigen Erhalt einer CAN-Nachricht ist in der Hardware schon integriert. Das heißt der Sendende Knoten weiß schon bevor er das letzte Bit gesndet hat, ob die Daten korrekt bei mindestens einem Empfänger angekommen sind und das kein Empfänger die Daten als fehlerhaft erkannt hat. Du könntest also deinen angedachten Bestätigungsmechanismus direkt zur Bestätigung zur Bearbeitbarkeit der Anforderung (Ähnlich dem UDS Protokoll im Fahrzeugsektor) nehmen. Gruß TManiac
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.