Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Im Bild wird das Senden des eibPCs über die ABB IPS/S 2.1 dargestellt, gecaptured über den Siemens N146/02.
Das ging bei Daten 0 los und endete bei FFFF. Der eibPC scheint die write()s aber irgendwie zu limitieren, denn durchgängig schaffte ich es nur bis ca. 1Telegramm/100ms (ich hab aber auch nicht alles getestet), schneller wurde er erst, wenn er Telegramme verwirft?! Obwohl ja trotzdem längere Passagen durchgängig sind.
Nee, der EibPC schickt die auch per LAN mit der angegeben Telegrammratenbegrenzung an die Schnittstelle. Das hab ich schon getestet. Er verwirft auch nix - lt. wireshark schickt er die Telegramme an die Schnittstelle und die fängt dann igrendwann an zu hacken. Oder wie meinst Du verwirft?
Schau mal im ETS Busmonitor. meine Schnittstelle konnte igrendwann ihre eigenen Telegramme nicht mehr lesen und hat dann Wiederholungen gesendet, was die Sache auch nicht schneller machte.
Nee, der EibPC schickt die auch per LAN mit der angegeben Telegrammratenbegrenzung an die Schnittstelle. Das hab ich schon getestet. Er verwirft auch nix - lt. wireshark schickt er die Telegramme an die Schnittstelle und die fängt dann igrendwann an zu hacken. Oder wie meinst Du verwirft?
Telegrammratenbegrenzung beim eibPC war anfangs aus und dann auf 50/s eingestellt.
Was ich mit Begrenzung meine ist:
[highlight=epc]
step = 2u64
dummy = 0u64
if eval(EIN) then dummy = dummy + 1u64 endif
if ( mod( dummy, step) == 0u64 ) then write ( '0/0/100'u16, convert( dummy/step, 0u16 ) ) endif
[/highlight]
Ich verwende obiges Programm um beliebig schnell (max. jede ms) ein Telegramm zu senden. Bei step 100 würde ich erwarten, dass alle 100ms ein Telegramm raus geht. Leider ist dem nicht so, es wird scheinbar intern gedrosselt. Die abgebildete Messung entstand mit step = 2, da sollten doch wohl viel mehr Telegramme verloren gehen, oder?
Oder mache ich da einen Fehler?
Schau mal im ETS Busmonitor. meine Schnittstelle konnte igrendwann ihre eigenen Telegramme nicht mehr lesen und hat dann Wiederholungen gesendet, was die Sache auch nicht schneller machte.
Der Log ist ja mit der ETS aufgenommen, wobei sich die Schnittstelle nie selbst überholt hat, sondern ab und zu mal eine Wiederholung fremder Telegramme kam.
Telegrammratenbegrenzung beim eibPC war anfangs aus und dann auf 50/s eingestellt.
Bei step 100 würde ich erwarten, dass alle 100ms ein Telegramm raus geht. Leider ist dem nicht so, es wird scheinbar intern gedrosselt. Die abgebildete Messung entstand mit step = 2, da sollten doch wohl viel mehr Telegramme verloren gehen, oder?
Die Telegramme werden nicht im EibPC so stark gedrosselt - die sollten maximal an die Schnittstelle übertragen werden - lt. meinen wireshark Aufzeichnungen werden sie es auch, wobei ich nun nicht mit Deinem Programm sondern mit meinen Lesetelgrammen getestet habe. In der IP Schnittstelle selbst werden nach meiner Erfahrung [mit einem anderen Hersteller] die Telegramme begrenzt. Auch beim Schreiben auf IP Interface ist - wie Du schon geschrieben hast- die einstellbare Telegrammratenbegrenzung des EibPCs wirksam, aber ich meine eben die der Schnittstelle.
Schau doch mal die ersten 50 Telegramme an, da müsste man das Anwachsen der Zeitabstände sehen. Das Fehlen von bestimmten Telegrammen sollte da auch nicht bei den ersten 20...50 Telegrammen auftreten. Ich vermute die Schnittstelle kriegt bei zu vielen Telegrammen einen Überlauf, der dann dazu führt, dass einfach nicht alle Telegramme auf den Bus kommen bzw. sie verwirft einfach Telegramme. Beim Frankenstammtisch war z.B. von Weinzierl der Wert 150 Telegramme als interner Puffer des IP Routers kommuniziert worden.
Offenbar ist der ABB hier besser beim Rausschreiben (immerhin schafft er mehr Telegramme als meine XXXXXXX), aber mehr als 10/s schafft auch er nicht . Die Frage ist dann, ob bei Telegrammbegrenzung im EibPC auf 10T/s zusätzlich Telegramme verloren gehen.
Lt. Messung von vento ist die zumindest in der Lage beim "Lauschen" auch mehr mitzubekommen, dass ist bei meinem Router auch so - war mir auch jetzt erst bewusst. Nur beim Schreiben auf den Bus eben nicht.
@vento66: Kannst Du auch mal in der Anlage dem Router aus mit der Performance schreiben lassen?
Zu Deiner Messung: damit der EibPC mit der Auflösung arbeitet, müsstest Du auch die Zeitscheibe des EiBPC auf 1ms stellen (Optionen Performance).
[..]Beim Frankenstammtisch war z.B. von Weinzierl der Wert 150 Telegramme als interner Puffer des IP Routers kommuniziert worden.
Einen so großen Puffer hätte ich nicht erwartet, aber das könnte es natürlich sein. Allerdings spricht das dann eher für höhere mögliche Datenraten während des Startes, oder? 150 Telegramme am Stück brauche ich noch lange nicht.
Offenbar ist der ABB hier besser beim Rausschreiben (immerhin schafft er mehr Telegramme als meine XXXXXXX), aber mehr als 10/s schafft auch er nicht .
Naja, kleinlich will ich ja nicht sein, aber überwiegend waren es schon eher 12/s. Im neuen Log sind es auch gleich mal 28/s
Die Frage ist dann, ob bei Telegrammbegrenzung im EibPC auf 10T/s zusätzlich Telegramme verloren gehen.
Momentan messe ich mit 50/s, aber was macht der eibPC, wenn man häufiger senden will? Wie groß ist denn der Puffer?
Zu Deiner Messung: damit der EibPC mit der Auflösung arbeitet, müsstest Du auch die Zeitscheibe des EiBPC auf 1ms stellen (Optionen Performance).
Das war natürlich der Fehler! Mit 1ms Zykluszeit fällt das Ergebnis gleich viel plausibler aus!
Das schreit allerdings nach einem Featurewunsch: Bitte die Konfigurationswerte im Programm verfügbar machen, also z.B. Konstanten, die man auswerten kann.
Bist Du sicher, dass keine Telegramme verloren gehen bei dieser Rate?
Also genau bei dieser Rate läuft der Bus ja im Normalzustand nicht, das war gestern nur zu Testzwecken, das die 2 Aktoren die Stromwerte im Sekundentakt auf den Bus posaunen Aber beim Start des HS werden alle Werte der Aktoren eingelesen, was eine ähnliche Buslast erzeugt. Die Stati der einzelnen Aktoren / Binäreingänge und Zähler passen aber immer 100%. Ich habe hier noch so einen Router rumliegen, den werd ich bei Gelegenheit mal mit ein paar read Anfragen stressen.
Einen so großen Puffer hätte ich nicht erwartet, aber das könnte es natürlich sein. Allerdings spricht das dann eher für höhere mögliche Datenraten während des Startes, oder?
Wie meinst Du das? Die Telegramme werden bei meiner am Anfang schnell, dann immer langsamer (mit Wiederholungen, weil offenbar nicht recht verstanden) geschickt.
150 Telegramme am Stück brauche ich noch lange nicht.
Dein Programm wird das Produzieren und wie beim ersten Log gehen dann einfach Telegramme verloren. Oft sieht man das gar nicht.
Naja, kleinlich will ich ja nicht sein, aber überwiegend waren es schon eher 12/s. Im neuen Log sind es auch gleich mal 28/s
Dauerhaft?
Momentan messe ich mit 50/s, aber was macht der eibPC, wenn man häufiger senden will? Wie groß ist denn der Puffer?
Ich weiss es nicht genau, aber ich denke 4096. Allerdings entleert den Puffer auch sehr schnell
Wie meinst Du das? Die Telegramme werden bei meiner am Anfang schnell, dann immer langsamer (mit Wiederholungen, weil offenbar nicht recht verstanden) geschickt.
Hm, wenn die Schnittstelle 150 Telegramme puffern kann, kann ich problemlos 100 Telegramme am Stück rausschicken, die werden ja auch abgearbeitet und nach dem Start des eibPCs entschärft sich die Sache extrem, auf durchschnittlich 2.3 Telegramme/s bei einer 30 Min. Messung.
Dein Programm wird das Produzieren und wie beim ersten Log gehen dann einfach Telegramme verloren. Oft sieht man das gar nicht.
Natürlich, am Anfang (und das wolltest du doch mal sehen) geht aber alles gut, bei Sendeanforderungen alle 10ms.
Dauerhaft?
Langsamer wurde meine Schnittstelle auch ab und an, was sicherlich auch an Kollisionen liegen kann (hatte ja extra solch einen Fall im 2. Log dargestellt), aber es geht dann gleich wieder mit >25 Telegrammen/s weiter, bis dann später (habe erst nach 4 Min. wieder nachgeschaut) Telegramme verloren gegangen sind -> Pufferüberlauf in der Schnittstelle?! D.h. aber, dass da die Kommunikation zwischen Schnittstelle und eibPC problematisch ist. Gibt es da keinen Handshake?
Ich weiss es nicht genau, aber ich denke 4096. Allerdings entleert den Puffer auch sehr schnell
Das ist dann aber auch schon das nächste Limit. Selbst wenn es einen Handshake gibt, müssten irgendwann die write()s gebremst werden. Auch mit Datenratenbegrenzung und riesigen Puffern kann ja der Bus schon voll sein und jedes Telegramme hätten ja 1,5s Timeout verfügbar, oder?
Am Ende kann man solch ein Problem nicht auf der Transportschicht in den Griff bekommen. Und das dann über 'meist', 'durchschnittlich' oder 'besser ist' zu versuchen ist eine ziemliche Bevormundung des Anwenders. Eine robuste Fehlerbehandlung würde ich vorziehen.
Aber selbst wenn es einen gibt, und wenn dadurch extern keine Telegramme mehr verloren gingen, wie soll es dann EPC-intern gehandhabt werden, wenn das Programm - warum auch immer - so viel in zu kurzer Zeit schreiben will, dass die internen Puffer überlaufen?
Bislang gehen die Daten einfach verloren, eine Chance darauf zu reagieren gibt es derzeit nicht - der EPC merk es ja wohl gar nicht...
Letztlich ist es wohl ein Software-Fehler, wenn mein Programm dauerhaft mehr schreiben will, als über den Bus gehen kann, aber mit zunehmender Komplexität kann man das nicht mehr sicher ausschließen, und daher sollte es Möglichkeiten geben, das wenigstens irgendwie dem Nutzer zu melden, ggf. auch irgendwie vom Programm her darauf zu reagieren...
Letztlich ist es wohl ein Software-Fehler, wenn mein Programm dauerhaft mehr schreiben will, als über den Bus gehen kann, aber mit zunehmender Komplexität kann man das nicht mehr sicher ausschließen, und daher sollte es Möglichkeiten geben, das wenigstens irgendwie dem Nutzer zu melden, ggf. auch irgendwie vom Programm her darauf zu reagieren...
In diesem Fall steht eine Fehlermeldung im Eventspeicher.
In diesem Fall steht eine Fehlermeldung im Eventspeicher.
Gut, bei meinem eibPC ist er allerdings leer.
Was bedeuten denn eigentlich die Fehlermeldungen?
Und warum teilt mir das EibStudio vor der Abfrage des Ereigenisspeichers mit, dass das Programm vorher neu kompiliert wird? Ist es wirklich notwendig diese Aktionen zu koppeln?
Gut, bei meinem eibPC ist er allerdings leer.
Was bedeuten denn eigentlich die Fehlermeldungen?
Dies sollte dann dabei stehen, also z.B. INVALID TELEGRAMM o.ä.
Und warum teilt mir das EibStudio vor der Abfrage des Ereigenisspeichers mit, dass das Programm vorher neu kompiliert wird? Ist es wirklich notwendig diese Aktionen zu koppeln?
Die Fehler können auch auf die Verarbeitung hindeuten. Z.B. könnte Variable
v=1/"GA-1/2/3"
für "GA-1/2/3"==0 einen Verarbeitungsfehler generieren (Fehler PROC OBJECT). Allerdings ist im Fehlerspeicher nicht der Klartext des Objekts hinterlegt, sondern nur die Objekt ID, die EibStudio durch den Compiliervorgang erfährt. Wenn man nun den Eventspeicher abfrägt, haben wir den Compiler nochmals angeschmissen, so dass die Rück-Übersetzung möglichst aktuell ist.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar