- √ - Bus stürzt ab hängt sich auf

[enertegus]

Du meinst sicher 7 Telegramme pro Sekunde?
Ansonsten verweise ich auf meinen Beitrag #27

nein, ich dachte schon an die 7/min
7 Telgramme * 60 Minuten * 24 H= 10080.
Es kann schon mal sein, dass das pro Minute mehr sind. Da finde ich eben 5000/Tag eher sparsam.
Bei 7/s wären das ja 604800 Telegramme an einem Tag. Das wäre eher "verschwenderisch".

[Loxone]

wir sind bei unseren Tests auf 12 Telegramme/Sekunde gekommen. Bei komplexeren Telegrammen etwas weniger.

Grüße,
Florian

[Tessi]

Du meinst sicher 7 Telegramme pro Sekunde?

Ansonsten verweise ich auf meinen Beitrag #27

[enertegus]

Gibt es hier bereits einige Infos? Welcher Aktor/Taster hat das Dilemma ausgelöst? Oder war es eine Fehlprogrammierung?
Zum Hintergrund: Wir entwickeln an einem (zertifizierten) Busankoppler und da ist so ein Stresstest aus der Praxis sicherlich interessant.

Zur Telegrammrate: Man sollte schon mit 7 Telegrammen pro Minute rechnen dürfen (das ist so mein Erfahrungswert einer _einfachen_ aber kompletten Installation). Das wären dann 10.000 pro Tag. Wäre vielleicht eine Frage an die Profis, die mich auch interessieren würde, was hier durchschnittlich am unteren Ende liegt. Das obere hab ich schon mal gesehn: 500.000 in 24 Stunden.

[Tessi]

CAN: Die CR Logik ist (laut Spezifikation) aktiv innerhalb des ID Fields, 11 oder 29 Bits, danach nicht mehr.

Richtig, eine Kollision im Datenteil darf nicht vorkommen, wird als Busfehler angesehen und entsprechend behandelt.

Bei CAN gibt es keine "Quelladresse" in diesem Sinn, "NUR" die Message-ID.

Auch richtig, so werden diese 11 bzw. 29 Bit genannt, die nur ein Gerät am Bus so senden darf, wie CAN@home aber so schön zeigt, kann man auch die wie bei KNX interpretieren (ein paar Bit Priorität, ein paar Absender, ein paar funktionale ID). Fasse ich gedanklich PA und GA einfach zusammen, sieht es bei KNX ziemlich ähnlich aus.

In dieser muss dann also sowohl die Senderadresse als auch die "Multicast Bedeutung [==Gruppenadresse]" gepackt werden damit das "CR" funktioniert. Denn die CAN Spec sieht nach dem ID Field keine CR Funktionalität mehr vor.

Richtig, so wird es praktisch dann auch gemacht (s.o.). Und auch bei KNX dürfte im Datenteil nur noch ein Sender aktiv sein, ansonsten wurde eine PA im System mehrfach vergeben, was laut Spec nicht zulässig ist. Nur hat man sich bei KNX keine Gedanken darüber machen wollen, wie man diesen Fall denn behandeln müßte. CAN liefert einen Bus-Fehler, und damit einen Hinweis, das da etwas nicht stimmt. Bei KNX muß ich lange suchen, bekomme vielleicht die seltsamsten Reaktionen - ein echter Vorteil...

(meines Erachtens ein CAN Schwachpunkt gegenüber KNX, da also von den wenigen 11Bits der ID einige verbraten werden um den Teilnehmer zu identifizieren[ok 29 Bit mit nochmehr Overhead geht auch...])

Was den nun, sind 11 Bit zu wenig aber 29 zu viel? Wie viele Bits "verbrät" KNX für Priorität, PA und GA? Sind wohl mehr als nur 29, zu viel Overheat wird gerade KNX häufig vorgeworfen.

Aber, und das war mir eigentlich wichtig, solange beide Busse spezifikationsgemäß betrieben werden, findet die Arbitrierung noch vor dem Datenteil statt und da benutzen beide Busse die selbe Vorgehensweise. Das CAN und KNX auch sonst gleich sind, hat ja niemand behauptet.
Der meiner Meinung nach wichtigste Unterschied ist:
Bei CAN erfolgt das alles in Hardware (CAN-Controller), bei KNX muß sich der Applikations-Controller selbst darum kümmern, was meist in Software realisiert wird. So kann es dann vorkommen, das ein Gerät - warum auch immer - mal nicht erkennt, das sein rezessives Bit dominant überschrieben wurde und weitersendet, was dann zu den seltsamsten Resutaten führen kann. Einem validierten CAN-Controller passiert das nicht - außer es liegt ein Hardware-Defekt vor.

So tippe ich denn auch hier darauf, das so etwas in der Art passiert ist, wobei man dann eben nicht mehr anhand der Daten erkennen kann, wer es war, denn sie stellen eine Mischung zweier Telegramme dar...
An oberster Stelle in der Liste der verdächtigen Geräte stehen da natürlich die, die am komplexesten sind und die ggf. eine nicht validierte Schnittstelle verwenden...
Spontan sehe ich da nur ein Gerät, das gleich beide Kriterien für den 1. Platz erfüllt...

Nein, das muß nicht der "Übeltäter" sein, aber von allen möglichen Lösungen ist die einfachste und offensichtlichste auch die wahrscheinlichste - also würde ich dort anfangen zu prüfen (es einfach mal vom Bus trennen).

[makki]

@Makki:
/CA = vorher schauen, ob man senden kann - geht aber nur in langsam
/CR|CD = senden und danach schauen, obs gekracht hat - geht auch in schnell, aber die Geräte müssen das berücksichtigen..

Leider ist das Quatsch!

Gut, ich räume ein, das ich zu faul war mir jetzt noch ohne Not anzuschauen wie CAN tut.
Jetzt musste ich es wohl doch und setze nie wieder CR&CD gleich - versprochen

Jetzt folgt der Versuch der Beschreibung des eigentlichen Unterschieds
der Arbitrierung KNX/CAN:

Puh, also können wir uns darauf einigen, das /CR (CAN) und /CA (KNX) einfach nicht dasselbe ist.
Was allerdings auch sekundär ist, weil das Problem besteht im KNX, nicht im CAN

bei manchen Implementierungen sogar innerhalb des IACK Bytes.

Ich rate jetzt nicht bei welcher

Sorry das ist wohl erstmal verwirrend, aber FUNDIERT!
Nachfragen stets willkommen.

Falls es mich mal zu CAN verschägt.. Aber dann les ich vorher; Du weisst ja, ich stehe bei >9,6kbit soweiso eher auf Ethernet&IP, auspacken, anstecken geht, ohne über /Cx &Co überhaupt nachzudenken

Makki

P.S.: Sind wir OT? Ausgangspunkt war ja, das zalva zumindest sicher keine unerkannten/unbehaldelten Collisions im KNX haben sollte..

[Gamma]

Hallo Makki, Hallo Tessi!
Nur mal so meinen "Senf" dazu:
@Makki:
/CA = vorher schauen, ob man senden kann - geht aber nur in langsam
/CR|CD = senden und danach schauen, obs gekracht hat - geht auch in schnell, aber die Geräte müssen das berücksichtigen..

Leider ist das Quatsch!

Tatsache:
Die Nomenklatur CA(Collission Avoidance) bei KNX und CR(Collission Resolution) bei CAN ist funktionell identisch, es findet eine Kollisionsvermeidung statt. Und das hat nun garnix mit CD zu tun, BASTA.
CD heisst halt "alles Schrott, irgendwann wiederholen"... bei 100MBit kein Problem.

Nix für ungut Makki, aber die CAN Spec ist doch wirklich leicht zu googlen,
oddr?

Jetzt folgt der Versuch der Beschreibung des eigentlichen Unterschieds
der Arbitrierung KNX/CAN:

KNX: Die CA Logik ist für jedes Bit des Telegramms aktiv, bei manchen Implementierungen sogar innerhalb des IACK Bytes.
(Ich bevorzuge nach wie vor den Begriff IACK obwohl inzwischen die Nomenklatur "ACK Byte" eingeführt wurde)

CAN: Die CR Logik ist (laut Spezifikation) aktiv innerhalb des ID Fields,
11 oder 29 Bits, danach nicht mehr.

DAS ist der wesentliche Unterschied,
ODER auch nicht: {NERD ALERT!}

Weil:
Wenn auf dem KNX Bus keine 2 Teilnehmer eine IDENTISCHE Physikalische
Adresse haben (Was auch nicht vorkommen sollte ausser UNBEABSICHTIGT bei Wartungs/Programmierarbeiten)
erfolgt bei KNX die CA Auflösung entweder im Control Byte (1.tes Byte im TP1 Telegramm) oder in der Quelladresse (=Physikalische Adresse des Senders).
Aber im "worst case" erfolgt weiterhin die CA Arbitrierung.

Bei CAN gibt es keine "Quelladresse" in diesem Sinn, "NUR" die Message-ID.
In dieser muss dann also sowohl die Senderadresse als auch die "Multicast Bedeutung [==Gruppenadresse]" gepackt werden damit das "CR" funktioniert. Denn die CAN Spec sieht nach dem ID Field keine CR Funktionalität mehr vor.

(meines Erachtens ein CAN Schwachpunkt gegenüber KNX, da also von den wenigen 11Bits der ID einige verbraten werden um den Teilnehmer zu identifizieren[ok 29 Bit mit nochmehr Overhead geht auch...])

Sorry das ist wohl erstmal verwirrend, aber FUNDIERT!
Nachfragen stets willkommen.

@TESSI: Teilnehmerintern in "unseren" Devices: "BUSLOST=1", keine Kollision, solange die aktivbitzeit 56uSecs nicht überschreitet


Grüsse von GAMMA!

[Tessi]

CAN ist einer der wichtigsten und meistverwendetsten Busse in Kraftfahrzeugen. Interessant in Verbindung mit KNX ist nur, das das selbe Bit-Arbitrierungsverfahren verwendet wird.

CAN und auch KNX:
Es kracht gar nicht. Es lauscht jeder erst einmal, ob der Bus überhaupt frei ist. Eine laufende Telegrammübertragung muß auf jeden Fall abgewartet werden. Damit das nicht zu lange dauern kann, ist die Telegrammlänge bei beiden Systemen ziemlich begrenzt (verglichen mit z.B. Ethernet). Sollten tatsächlich mehrere Teilnehmer dann gleichzeitig anfangen zu senden kommt es ja erst dann zu einem Konflikt, wenn erstmals im Telegramm unterschiedliche Werte gesendet werden sollen (die ersten Bits sind ja bei allen Telegrammen gleich). Nun ist aber die 0 dominant, sobald einer sie sendet ist sie auf dem Bus zu sehen, egal wie viele andere Teilnehmer eine 1 senden wollen. Da jeder sendende Teilnehmer auch gleichzeitig empfangen muß, kann er erkennen, ob auf dem Bus das zu sehen ist, was er sendet. Falls nicht, hat er sofort das Senden abzubrechen, da offensichtlich ein anderer Teilnehmer mit höherer Priorität zeitgleich sendet. Dieser wiederum bemerkt das aber nicht, da er auf dem Bus ja genau das lesen kann, was er gerade auch sendet, und so sendet er einfach weiter. Auch alle anderen nur empfangenden Teilnehmer bemerken von diesem Konflikt nichts, sie sehen nur das höherpriore Telegramm - das gilt leider auch für alle Tools zur Busüberwachung. Nur die "unterlegenen" Sender wissen von dem Konflikt. Sie werden es im Anschluß an das vorherige Telegramm alle wieder gleichzeitig versuchen, wobei wieder einer gewinnen wird, die anderen es wieder im Anschluß erneut versuchen. Auf diese Weise werden dann alle Telegramme in der Reihenfolge ihrer Priorität im dichtest möglichen Abstand gesendet, ohne das aus Sicht aller nur empfangenen Teilnehmer dabei irgend ein Telegramm zerschossen wird.
Das ist der wichtige Unterschied zum Ethernet, wenn hier zwei gleichzeitig senden, sind beide Pakete unlesbar, müssen beide wiederholt werden und alle anderen bekommen das auch so mit.

Wie man dieses Vorgehen nun nennen will, ist mir eigentlich egal, man sollte sich aber wenigstens einigen.
Denn eigentlich geschied hier alles gleichzeitig: Um Kollisionen zu vermeiden wird zunächst mal gelauscht, hat das nicht gereicht, wird eine Kollision erkannt, hat einer sie erkannt, wird sie aufgelöst, indem dieser nicht mehr weitersendet und das Telegramm des "Siegers".

Bei CAN hat man das Resolution genannt, bei KNX Avoidance. Man könnte sich lange darüber streiten, was besser passt, ich hätte es einfach nur gut gefunden, wenn man das gleiche Verfahren in beiden Fällen auch gleich benannt hätte.

Es bleibt die Frage:
Wenn zwei Teilnehmer gleichzeitig anfangen zu senden, und einer bricht dann ab, ohne das die Übertragung des anderen dadurch Schaden nimmt und ohne das das von außen zu erkennen ist, hat dann eine Kollision stattgefunden oder nicht?

[makki]

Anscheinend ist man sich nicht einig, wie man es nennen will. KNX nennt es tatsächlich CA, während bei CAN der selbe Mechanismus..

Ähm, mit CAN kenne ich mich nicht aus, beim KNX ists aber ganz sicher CSMA/CA und es gibt da einen ganz deftigen Unterschied zu CSMA/CR - was wiederum fast dasselbe wie das bekannte CSMA/CD im "gehubbtem" Eth ist..
/CA = vorher schauen, ob man senden kann - geht aber nur in langsam
/CR|CD = senden und danach schauen, obs gekracht hat - geht auch in schnell, aber die Geräte müssen das berücksichtigen..

Stimmt aber: "sehen" kann man das wirklich nur lokal am TP1, mit isolierten Geräten und Oszi + ggfs. Logic-analyzer..

Makki

[Tessi]

da der Störer ohne jede Rücksicht sendet hast du doch trotzdem Müll im System!

Falls er ohne Rücksicht sendet ist das korrekt, leider kann man mit den üblichen Tools das wohl nicht sehen und solche Selbstüberwachungsfunktionen wie bei CAN gibt es wohl nicht.

(es ist übrigens CSMA/CA)

Anscheinend ist man sich nicht einig, wie man es nennen will. KNX nennt es tatsächlich CA, während bei CAN der selbe Mechanismus (wer beim ersten ungleichen Bit das dominante sendet hat gewonnen und darf weitersenden) CR genannt wird - bei einigen anderen Feldbussen wohl auch.

[rb84]

Im Übrigen ist so etwas ein Grund für eine Sternverkabelung (bzw. Baum)...

Ich halte es für nicht gut einen RING (offen) pro Etage zu legen: Maximal in jedem RAUM ein Ring und jeden Raum dann direkt zu einer UV führen. Abklemmen eines Raums/Teilnehmers: 10 Sekunden Zeitaufwand.

Bei einem RING nach Fehlern suchen: halber Tag...

[makki]

Nur am Rande: ich schreibe dazu nichts, bis das Problem im Detail identifiziert ist.
(und danach vielleicht auch nicht )

Meine Schlussfolgerung war: es gibt dort mind. ein defektes oder fehlerhaftes Gerät(*) oder eine bestimmte Kombination derer, die - wie auch immer - dazu führt, das
a) regelmässig, in deterministischen Zeitabständen von 10 Minuten, Telegramme "zerschossen" werden (es ist übrigens CSMA/CA)
b) sich der KNX wirklich dann irgendwann komplett "weghängt", was ich so bis dato nicht gesehen habe.

Woran das nun im Detail liegt kann und wage ich remote nicht ansatzweise zu beurteilen, ich wollte nur erstmal 100% sicherstellen&ausschliessen können, das es am WireGate liegt.


Warum es nach diesem "Absturz" (was auch immer da passiert) bei der TP-UART nicht wie üblich automatisch ohne manuellen Restart weitergeht untersuchen wir hier.

Makki

Edit *: was ich damit sagen will, es ist ja hier auch noch anderes, bisher ungenanntes Material unterwegs, eins davon von einem wissentlich auch recht neuen Hersteller -> es kann alles sein.

[rb84]

Das wird bei Ethernet so gemacht, KNX nutzt wie CAN ein Arbitrierungsverfahren (CSMA/Clarification required. siehe: Carrier Sense Multiple Access/Collision Resolution und Europäischer Installationsbus), bei dem im Konkurrenzfall das Telegramm mit der höheren Priorität unbeschadet übertragen wird, während das andere warten

Das mag richtig sein. Der Effekt istallerdings der selbe: da der Störer ohne jede Rücksicht sendet hast du doch trotzdem Müll im System!

[Tessi]

Zur Auslastung:
Auf meinem Bus wird viel zyklisch gesendet, da kommen rund 100 Telegramme/min zusammen. In nun über drei Jahren hat das nie zu Problemen geführt.
Soll heißen, 50000 Telegramme/Tag sind nicht (zu) viel...
Und 5000/Tag ist wenig.

[zalva]

Hallo zusammen,

möchte mich diesbezüglich auch wieder zu Wort melden.

Richtig ist, die Ursache ist noch nicht hunderprozentig ermittelt.
a.)
Mit Hilfe von wiregate (makki) konnten Fehlerquellen ausgeschlossen und restliche potentielle Kanditaten ermittelt werden.

b.)
Mit Hilfe von loxone (Florian, Herr Nader) konnten Konfigurationsfehler im Miniserver lokalisiert und eliminiert werden. An manchen Stellen wurde gepollt (Konfigurationsfehler, mea culpa), wo es nicht zwingend notwendig ist und der Status implizit vorliegt.

Tatsache ist allerdings auch, dass das Verkehrsaufkommen zwar nicht zu hoch insgesamt war über den Tag gesehen, aber wenn was kam, dann viel auf einmal. Auf meinem Bus ist jetzt relative Ruhe eingekehrt (im Moment spielt sich eh nur Licht/Steckdosen und die FBH dort ab und der Bus langeweilt sich)

Die Anzahl der Telegramme ist auf rund 5000 (von in der Spitze eher Richtung 80.000) gesunken.
Damit sinkt die Chance auf Überlast in einem kleinem Zeitintervall auch drastisch und damit auch die Wahrscheinlichkeit eines Hängers.

Fakt ist auch, dass seit der Behebung der Konfigurationsfehler beim Miniserver, kein Hängen mehr zu verzeichnen ist.

Wichtig ist allerdings auch, dass die Stabilität so bleibt, auch wenn ich nach und nach zusätzliche Funktionen implementiere (Logiken, Multiroom ...).

Falls das Problem bzw. die Ursache tatsächlich in der Sphäre Miniserver liegen sollte lösen das die Jungs und es wird z.B. mit einem Patch behoben, dann verbuche ich dass unter Kinderkrankheit in einem sonst sehr guten Produkt.

Für alle die mitlesen bezüglich Wiregate bzw. Miniserver.
Was mich angeht, lasse ich weder über meine Wiregate noch meinem Miniserver was kommen! Die Kombination von Beiden Geräten bezüglich günstiger Temperaturermittlung (Wiregate) und einfach und schnell zu realisiernden Logiken und Visualisierung (ipod/Web/Internet mit Miniserver) zu einem vernünftigen Preis ist IMHO super und (fast) unschlagbar.(Nein weder von Makki, noch von Florian bekomme ich Prozente, was allerdings beide Firmen leisten ist ein sehr schneller, super und unkomplzierten Support). Meine Erfahrungen diesbezüglich ist mit beiden Geräten sehr positiv.

Selbstverständlich bin ich nach wie vor offen für Ideen, welche Ursachen noch möglich sein könnten für Hänger
(auch um know-how weiter aufzubauen) offen und möchte mich hiermit bei allen für die Beiträge hier bedanken.

Liebe Grüsse und ein Schönes Wochende aus Freiburg i.Br.
Salvatore