Brick Daemon - Warnungen in Ereignisanzeige

[RSchiessl]

Hallo,

ich frage über ein Programm manche Bricklets per polling (USB) alle paar Sekunden ab. Ziemlich genau alle 3 Stunden bekomme ich mehrere Einträge in der Windows Ereignisanzeige:

 

"Read transfer 0098BAF8 for Master Brick [6JLTym] got stalled"

oder "Dropped 1 pending request(s) (uid: tgf)"

 

Was läuft hier falsch bzw. was wollen mir diese Meldungen sagen?

 

Danke - Ralf

[photron]

Den Fehler habe ich noch nie gesehen.

 

Beschreibe mal deinen Aufbau genauer:

 

- welche Windows Version?

- wie ist dein Stack aufgebaut?

- wie ist der Stack angeschlossen (USB2, USB3, Hub dazwischen etc.)?

- wie häufig kommunizierst du mit dem Stack?

[RSchiessl]

Hi photron,

habe folgenden Aufbau:

Windows 10,  1xMaster, 2xIndustrial-Relais, 1xIndustrial-DigtalIn, 1xTemperatur

Alles per USB 2.0 verbunden mit 0.5m Kabel; alle Updates eingespielt.

 

Hier ein aktueller Log-Eintrag: fast genau alle 3 Stunden;

21.01.2016 03:40:14; ERROR in xxx: Did not receive response in time for function ID 10

21.01.2016 06:41:28; ERROR in yyy: Did not receive response in time for function ID 2

 

Kommuniziere mit allen Bricklets alle paar Sekunden reihum per .NET Programm und frage Werte ab bzw. schalte Relais.

 

Danke - Ralf

 

[markus5766h]

Moin,

nur als ergänzende Information :

ich hatte auch schon mal auf Win10 umgestellt, habe aber dann festgestellt,

dass Programmierumgebungen wie .NET, Delphi instabiler waren.

Nach Rückkehr zu Win7(64Bit) waren die Probleme wieder verschwunden . . .

 

an alle wissenden : ist das "got stalled" eine reguläre Windows-Meldung ?

[photron]

Mit Windows 10 haben wir noch keine großen Erfahrungen, es sind mir aber auch keine aktuellen Probleme bekannt.

 

Dennoch wäre das mein erster Ansatzpunkt. Besteht die Möglichkeit, dass du das auf einer älteren Windows Version testen kannst?

[photron]

an alle wissenden : ist das "got stalled" eine reguläre Windows-Meldung ?

 

Das gibt brickd aus, wenn ein USB Bulk Read Transfer (um Daten vom Brick zu lesen) mit dem libusb Fehlercode LIBUSB_TRANSFER_STALL endet.

 

libusb gibt diesen Fehlercode zurück wenn WinUsb_ReadPipe mit dem Windows Fehlercode ERROR_GEN_FAILURE scheitert, siehe:

 

https://msdn.microsoft.com/de-de/library/Windows/Hardware/ff540297(v=vs.85).aspx

[markus5766h]

. . .

Dennoch wäre das mein erster Ansatzpunkt. Besteht die Möglichkeit, dass du das auf einer älteren Windows Version testen kannst?

 

VM WARE Player ? . . .

 

@ photron : ah, danke, das hatte ich gesucht . . .

[photron]

Virtualisierung ist eine Option, bringt aber auch einen weiteren Layer an möglichen Problemen mit sich.

[photron]

Was man testen könnte, wäre die libusb Version die brickd mitbringt zu aktualisieren. Die Version die beiliegt ist relative alt. Ich habe mich bisher vor einem Update gescheut, weil es mit der Version bisher keine Problem gab und es in letzter Zeit viele Änderungen in libusb gab. Die Chance ist also halbwegs hoch sich mit der neuen Version auch neue Probleme einzufangen.

 

Gerade gibt es aber auch einen Thread auf der libusb Mailing über Windows 10 und Transfer Stalls. Möglicherweise ist da was dran.

 

Wenn ich heute noch dazu kommen baue ich eine neue brickd Version mit einer aktualisierten libusb Version zum Testen.

[RSchiessl]

Hallo Zusammen,

vielen Dank für die Antworten von Euch.

Habe leider fast keine Möglichkeit Win7 zu testen. Denke aber auch, daß es mit Win10 bzw. mit libusb zu tun haben könnte. Deshalb gebe ich der Aktualisierung von PHOTRON die größten Chancen. Da das Problem zu 100% reproduzierbar ist, habe ich ein paar Stunden stäter die Antwort.

 

Gruß - Ralf

[photron]

Okay, teste mal bitte die angehängt brickd Version. Diese verwendet jetzt die neuste libusb Version.

brickd_windows_2_2_2_libusb1.exe

[RSchiessl]

Hi Photron,

 

leider hat das Update nix gebracht. Das Verbindungsproblem tritt ziemlich genau alle 4 Stunden auf:

  01.02.2016 03:50:43; Did not receive response in time for function

  01.02.2016 06:51:57; Did not receive response in time for function

  01.02.2016 09:53:11; Did not receive response in time for function

  01.02.2016 12:54:24; Did not receive response in time for function

==> hat hier jemand noch eine Idee

Danke - Ralf

 

[Nic]

Ich würde systematische vorgehen:

1) Hardware? TabletPC/Laptop/Nuc/ServerPC...

2) Alles ausgeschlossen was den Einfluß des Betriebssystem bedeutet?

3) Wie sieht das aktuelle Powermanagement unter Win10 aus?

4) Sind da noch weitere konkurrierende Dienste/Timer/Jobs/Tasks die auf USB-Ports zu greifen, diese ev. initialisieren?

Ein technisches Versagen tritt i.d.R. nie exakt nach 3 oder 4Std auf.

5) Wie ist der TF-Stack exakt aufgebaut, beginnend von unten nach oben?

6) Ist ausgeschlossen, dass es Fehler im eigenen Prog. sind ?

7) Alternativ den Brick-Logger verwenden, eigene SW abschalten und das Polling der Daten nur über den Logger machen. Was passiert dann nach 3 oder 4 Std?

Komplette BrickD Log an diesen Thread attachen das Log liest photron immer so gerne Spass beiseite, vielleicht stehen noch Hinweise einige Zeilen vor dem "got stalled"

Ich benutze auch gelegentlich die Stacks unter Win10, aber noch keine Probleme, allerdings für Langzeit-Betrieb und regelmäßiger Datenerfassung erscheint mir ein Desktop-Win recht ungeeignet