Callback verloren

[chuckle]

Hi,

 

Nach ein wenig lesen hier im Forum, sehe ich das ja eigentlich kein Callback verloren gehen sollte. Allerdings wird bei mir ab und zu einer nicht registriert.

Konkret geht es um einen IO16 der über Brick-Modbus-Modbus-Brick an einem Raspi hängt. Brickv und Pyhton laufen auf einem Laptop dann via lan-verbindung.

Wenn ich parallel den Brickv aufhabe zeigt dieser den korrekten Zustand zeitnah an. Soll heissen der Brickv bekommt alle Zustandsänderungen mit, das Python Script, welches ich laufen habe verschluckt einige.

Python-Script (interrupt) direkt von hier:

http://www.tinkerforge.com/de/doc/Software/Bricklets/IO16_Bricklet_Python.html#io16-bricklet-python-api

 

Habt ihr eine Erklärung für die Diskrepanz?

 

Schönen Gruss

Christoph

[photron]

Zeigt der Brick Viewer IO-16 Tab Timeouts an, oder steht die Timeout anzeige auf 0?

[chuckle]

Die Anzeige stand auf 1. Kann aber nicht sagen wann sie auf 1 gegangen ist.

Müsste das nochmal genauer testen.

[chuckle]

Hab eben nochmal einen Stresstest gemacht.

3mal kam in Python kein Callback an aber der Brickviewer hat alles "gesehen" und die Timeout Anzeige blieb auf 0.

[photron]

Das Brick Viewer es "sieht" wird daran liegen, dass Brick Viewer nicht den Interrupt Callback verwendet, sondern pollt.

 

Dennoch darf kein Callback verloren gehen.

 

Wenn du sagst 3mal hat dein Script den Callback nicht erhalten, von wie viel Prozent Verlust reden wir dann hier? Wie viele Interrupts hast du erzeugt?

 

Was passiert, wenn du den Aufbau vereinfachst? Also z.B. die RS485 Extensions aus dem Spiel nimmst und das IO-16 Bricklet direkt an den Master Brick am Raspberry Pi hängst?

[chuckle]

Der Brick Viewer pollt? Mit welcher Frequenz? Polling kommt für mich kaum in Frage

 

Ich habe keine Liste geführt, aber von ca. 5-10% reden wir.

 

Okay, ich werde das mal heute abend testen.

[photron]

Brick Viewer benutzt keine konfigurierbaren Callbacks, wie den Interrupt Calback, mehr. Das hat zu viele Probleme gemacht, wenn Brick Viewer und ein anderes Programm gleichzeitig Callback konfiguriert haben. Weil dann das andere Programm möglicherweise nur dann richtig funktioniert wenn Brick Viewer auch läuft und den richtigen Tab auf hat. Um diese Verwirrung zu vermeiden, pollt Brick Viewer z.B. die IO-16 mit 20Hz.

 

5-10% sind sehr viel. Da würde ich viele Timeouts im Brick Viewer erwarten, wenn wirklich 5-10% der Nachrichten verloren gingen.

[chuckle]

Habe gestern einen kleinen Testaufbau gemacht und da zeigt sich wie sehr im praktischen Betrieb Zustände auftreten die ich so nicht erwatet hätte.

 

Ich habe ein Relais des DualRelay Bricks and einen IO16 eingang angeschlossen und dann das Relais alternieren lassen. Dabei ist mir aufgefallen das die 100ms Prellabstand ein Teil des Problems sind.

 

Zum Vergleich: im praktischen Betrieb habe ich 6 Schranktüren mit Magnetschalter an das IO16 angeschlossen. Gerade am Schaltpunkt des Magnetschalters schaffe ich unter die 100ms zu kommen.

 

Gut, Prellabstand mal auf 1ms eingestellt und wieder mit Relais getestet. Die Schaltzeiten hab ich Asyncron gewählt um besser hören zu können welchen Zustand das Relais hat.

 

Mit Modbus am Brick (egal ob via Modbus oder direkt mit USB verbunden):

Unterhalb dieser Schaltzeiten fehlen Callbacks:

Zwischen Schaltvorgängen 100-120ms

Schaltvorgang 80-100ms

Bei 10 Schaltvorgängen sollten 20 callbacks ankommen, meist kamen nur 18 an, manchmal nur 14.

Im Brickviewer konnte man alle sehen.

Timeouts wurde gestern während der gesamten Zeit kein einziger angezeigt.

 

"Gefühlt" kam es mir vor als würde ein Speicher überlaufen, die ersten 5-10 Callbacks kamen alle an, dann meist nur noch einer pro Schaltvorgang. Gegen Ende wieder 2.

 

Für den praktischen Betrieb, werde ich den Prellabstand abschalten (geht das überhaupt?) Lieber habe ich zuviele, als zuwenige Events.

Überhaupt erst aufgefallen ist mir das Verhalten, wenn ich 2 Türen gleichzeitig geöffnet/geschlossen habe und dann ab und zu das Licht bei einer nicht reagiert hat.

 

Welche Vorschläge habt ihr? Polling will ich nicht, es wird noch mehr über den Bus kommuniziert werden. Verzögerungen (auch spürbare) wären nicht so schlimm wie komplett Aussetzer.

Timeouts würden mir zumindest zeigen, das was nicht stimmt und ich könnte einmalig den Zustand abfragen.

 

Vielen Dank und schönen Gruss,

Christoph

 

[photron]

Ich habe das mal gerade nachgebaut und kann das Problem nachstellen. Irgendwo ist das ein Bug, sorry. Ich kümmere mich drum.

[chuckle]

Juhuu, Ich habe einen Bug gefunden

 

Bei der Gelegenheit kann ich mal loswerden das ich Euer System ziemlich Klasse finde. Kenne einige Automatisierungssysteme von Gasturbinen und Ihr bietet mir alle Features die ich von dort gewohnt bin.

Ausserdem merkt man das Ihr voll hinter dem Produkt steht. Ihr habt nicht zufällig vor einen Schweizer Branch zu eröffnen? 

[photron]

Okay, das Problem war eine Race Condition in der Erkennung von Interrupts. Hier eine korrigierte Firmware für dich zum Testen.

 

Danke für das Lob! Momentan gibt es aber keine Pläne eine Niederlassung in der Schweiz.

io16-bricklet-206-rc1.bin

[chuckle]

Prima, das ging ja schnell. Leider werd ich wohl heute und morgen keine Zeit zum Testen haben. Spätestens am Wochenende sollte ich es aber schaffen.

[chuckle]

hab's doch geschafft gestern die Firmware zu flashen und ein paar kleine Tests zu machen.

Das Problem trat gestern nicht mehr auf.

Prima, Danke.

[photron]

Sehr gut! Neue Version ist veröffentlicht. Danke für den Hinweis auf das Problem.