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

[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.

[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]

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?

[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!

[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..

[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).

[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]

Du meinst sicher 7 Telegramme pro Sekunde?

Ansonsten verweise ich auf meinen Beitrag #27

[Loxone]

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

Grüße,
Florian

[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".

[enertegus]

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

Meinst Du "komplexer" im Sinne von länger [als was]? Bei Euren Tests bezüglich was?

[Tessi]

Irgendwie verstehe ich das nicht ganz:
KNX-TP läuft mit 9600 Bit/s entspricht 1200 Byte/s.
Die längsten Telegramme haben 24 Bytes, die kürzesten 9 Byte.
Die meisten dürften zwischen 9 und 12 Byte liegen.
Selbst mit kleinen Pausen müßte der Bus also mindestens 40 Telegramme/s schaffen, bei im Mittel 10 Byte langen Telegrammen müßten rund 100 Telegramme/s über den Bus gehen können. Dauerhaft!

Welcher Designfehler führt den dazu, das man in der Realität gerade mal 10% davon schafft? Und das noch nicht einmal sicher?

Mal rechnen: 7 * 9 Byte pro Sekunde sind 36 Byte/s. Ziemlich wenig, wenn das Transportmedium eigentlich 1200 Byte/s schaffen sollte, oder?
Selbst wenn ich nur Strings sende sind 7 * 24 Byte = 168 Byte immer noch sehr mager.

Ich kenne kein anderes System, das derart ineffizient ist. Und ich rede hier nicht von Netto-Nutzdaten (9 Byte Telegramme für 1 Bit Nutzdaten - nun ja) sondern vom Brutto-Telegramm - da ist der gesammte Protokolloverheat schon enthalten.

Also was macht KNX eigentlich so entsetzlich langsam?

[enertegus]

Selbst mit kleinen Pausen müßte der Bus also mindestens 40 Telegramme/s schaffen, bei im Mittel 10 Byte langen Telegrammen müßten rund 100 Telegramme/s über den Bus gehen können. Dauerhaft!

Nach jeder Nachricht am Bus kommt ein ACK (ich glaube innerhalb 12ms) vom Empfänger. Ganz ohne Sicherungsschicht läuft das also nicht ab. Das drückt Rate wohl auf 50/s, theoretisch.
Sollte das Telegramm nicht ankommen wird wiederholt (3xmal [meistens]).

[Gamma]

Hallo Tessi,
man schafft definitiv 49 Telegramme pro Sekunde(mit 1-6 Bit Daten).

Deine Rechnung von theoretisch 100/s geht nicht auf da du
auf Start,Stopbit, Parity und pausen verzichtest.

Grüsse von Gamma!

[Tessi]

Hm, ich bin davon ausgegangen, das für ein Byte tatsächlich 8 Bit gesendet werden...

Und das ACK ist meines Wissens nach ein Bit am Ende des Telegramms das die Empfänger zeitlich exakt (und synchron) treffen müssen, das Zeitfenster entspricht da wohl einer Bitlänge, also rund 104 us. Das macht den Kohl nicht fett.

Wiederholungstelegramme würde ich jeweils mitzählen, sie treten auf meinem Bus aber fast nie auf. OK, wenn ich über eine Schnittstelle hinweg arbeite, die beim Senden selbständig Telegramme wiederholt, dann sieht das sendende Gerät dahinter das wohl nicht. Ich meine hier aber die Telegrammzahl, die ein hörendes Gerät direkt am Bus sieht.

Aber selbst wenn durch zusätzliche Bits und Pausen ein Telegramm zeitlich doppelt so lang wird, als von mir angenommen, sind 7-12 Telegramme/s einfach zu wenig.

Und wenn man tatsächlich praktisch 49 Telegramme/s über den Bus bekommt, warum gibt es dann so viele Geräte, die zwar zertifiziert sind, aber garantiert keine 49 Telegramme/s schaffen? Nicht einmal lesend und erst recht nicht schreibend? Gut, nicht jedes Gerät hat einen solchen Informationsbedarf, aber Schnittstellen und Koppler/Router müssten auf jeden Fall mehr Bandbreite besitzen als der Bus selbst - was anscheinend nicht bei allen der Fall ist - trotz Konnex-Segen...

Nebenbei: Hat jemand mal einen Link auf eine ganz genaue Beschreibung was da physikalisch tatsächlich auf die Leitung moduliert wird? Anscheinend finde ich immer nur Beschreibungen, die von Pausen und zusätzlichen Bits nichts wissen...