photron

Das Log kann in der Version (fd1) nicht mehr so explodieren, denn sobald der Fehler auftritt beendet sich brickd , anstatt die Platte vollzuschreiben. Was mich auch wundert ist, dass vor dem Fehler im Log immer lange Pause sin,. teils 22 Stunden: 2019-12-17 00:19:17 Letzte Meldung vor dem Fehler 2019-12-17 22:46:23 Fehlermeldung 2019-12-20 22:49:39 Letzte Meldung vor dem Fehler 2019-12-21 00:51:20 Fehlermeldung 2019-12-22 23:08:19 Letzte Meldung vor dem Fehler 2019-12-23 21:06:26 Fehlermeldung Kannst du noch nachvollziehen, was du zum Zeitpunkt des Fehlers am PC gemacht hast? Hast du ihn zu dem Zeitpunkt in Standby oder irgendeinen Schlafzustand geschickt, oder ihn daraus aufgeweckt? Teste mal bitte diese brickd Version (fd2) und zeig mal bitte deine brickd.ini (C:\ProgramData\Tinkerforge\Brickd\brickd.ini) Datei vor. Diese brickd Version beendet sich jetzt bei Auftreten des Fehlers nicht mehr direkt, sondern versucht den Fehler zu reparieren. Sprich das Problem wird weiterhin auftreten können, aber brickd erkennt das jetzt und versucht damit umzugehen. Das Problem sollte also im Log noch sichtbar sein, aber den Betrieb nicht mehr stören. Auch ist das Log jetzt auf 5 Dateien a 5 MB (also 25 MB gesamt) beschränkt. brickd_windows_2_4_1+fd2.exe

Port 4223 ist der normale TCP/IP Port. WebSockets laufen nicht über Port 4223, sondern über Port 4280. Dieser Port ist auch in allen Beispielen korrekt voreingestellt. Hast du das händisch auf Port 4223 abgeändert? Darüber hinaus musst du WebSockets erst in brickd aktivieren: https://www.tinkerforge.com/de/doc/Software/API_Bindings_JavaScript.html#id2

Das verwundert mich jetzt. Die brickd_windows_2_4_1_tcpip.exe Version führt bei der Installation sc config "Brick Daemon" depend=tcpip aus. Als du das vorher mit brickd 2.4.0 händisch gemacht hast, sagtest du, das hätte das Problem behoben. Schau mal bitte in der Dienste-Ansicht nach, ob das geklappt hat, also ob Brick Daemon eine Abhängigkeit auf den TCP/IP-Protokolltreiber hat. Nur damit ich das richtig verstehe, tritt das Problem mit brickd_windows_2_4_1_tcpip.exe noch genauso auf wie vorher? Sprich, ist brickd nach dem Windows Start in diesem kaputten Zustand und wenn du den Dienst von Hand neustartet dann geht es? Dein Log sieht komisch aus. Hast du das komisch zusammen geschnitten? Der lange Zeitsprung ist komisch: 2019-12-16 22:38:06.518538 <I> <usb.c:194> Added USB device (bus: 1, device: 6) at index 0: IMU Brick 2.0 [6wVmVp] 2019-12-16 22:38:11.020795 <I> <network.c:304> Added new client (N: 127.0.0.1:62490, T: plain-socket, H: 956/956, B: 0, P: 0, A: disabled) 2019-12-17 00:19:17.431758 <I> <client.c:252> Client (N: 127.0.0.1:62490, T: plain-socket, H: 956/956, B: 0, P: 0, A: disabled) disconnected by peer 2019-12-17 22:46:23.991284 <E> <event_winapi.c:228> Could not write to USB ready pipe: WSAECONNABORTED (71010053) 2019-12-17 22:47:26.695720 <I> <network.c:304> Added new client (N: 127.0.0.1:64583, T: plain-socket, H: 972/972, B: 0, P: 0, A: disabled) Die ReadPipe/WritePipe Fehler sind auch komische, aber das mag alles ein Folgefehler von WSAECONNABORTED sein. Hast du etwas in der brickd.ini umgestellt? Mich wundert, dass brickd da eine Warnung ausgibt. Ich hab den WSAECONNRESET Fehler, der das Log vollmüllt jetzt mal fatal gemacht. Brick Daemon beendet sich jetzt, wenn dieser Fehler auftritt anstatt das Log voll zu schreiben. Das ist so auf Dauer keine schöne Lösung, aber erstmal besser als es vorher war. Die angehängt brickd Version ist nicht signiert. Ich habe hier gerade nicht meinen normalen Entwicklungsrechner zur Hand. Windows wird also etwas mehr meckern. Kannst du mit dieser Version ein Debug Log des WSAECONNABORTED Problems erzeugen? Dazu in brickd.ini das log.level von info auf debug stellen. Ich habe versucht mich über die möglichen Ursachen von WSAECONNABORTED zu belesen, verstehe aber dennoch nicht, wie das hier in diesem speziellen Fall zu Stande kommen kann. brickd_windows_2_4_1+fd1.exe

Teste mal bitte diese Version, die hat jetzt von sich aus "tcpip" als Abhängigkeit gesetzt. Das sollte dein direktes Problem beheben: https://download.tinkerforge.com/_stuff/brickd_windows_2_4_1_tcpip.exe Logrotation kommt dann in Kürze auch noch.

Sorry, das steht beides noch auf der TODO Liste ist mir aber durch die Lappen gegangen. Sprich, das alte Problem ist noch da, du kannst es aber durch sc config "Brick Daemon" depend=tcpip begeben und die Logdatei Explosion entsteht durch das Loggen wegen dieses Problems?

Brick Viewer 2.4.11 Lower Hardened Runtime restrictions to make ctypes work again on macOS Fix encoding issues in Server Monitoring script Downloads: Windows, Linux, macOS

Brick Viewer 2.4.11 Hardened Runtime Einschränkungen wieder reduziert, damit ctypes wieder auf macOS funktioniert Encoding Probleme im Server Monitoring Skript behoben Downloads: Windows, Linux, macOS

Brick Daemon 2.4.1 mit den Änderungen fürs HAT ist jetzt veröffentlicht.

Brick Daemon 2.4.1 Rename bundled libusb to avoid potential collision with system libusb on macOS Add missing network dependency to systemd service on Linux Make sleep time between SPI reads for HAT (Zero) Brick configurable Add experimental support for HAT (Zero) Brick (SPI connected Bricklets) on Windows 10 IoT Core, disabled by default due to missing HAT detection Notarize Brick Daemon app to make it ready for macOS 10.15 Downloads: Windows, Linux (amd64, i386, armhf), macOS

Brick Daemon 2.4.1 Mitgelieferte libusb umbenannt um mögliche Kollision mit System libusb auf macOS zu vermeiden Fehlende Network Abhängigkeit zu systemd Service auf Linux hinzugefügt Wartezeit zwischen SPI Lesevorgängen für HAT (Zero) Brick einstellbar gemacht Experimenteller Support für HAT (Zero) Brick (SPI verbundene Bricklets) zu Windows 10 IoT Core hinzugefügt, standardmäßig deaktiviert bedingt durch fehlende HAT Erkennung Brick Daemon App ist notariziert, um bereit für macOS 10.15 zu sein Downloads: Windows, Linux (amd64, i386, armhf), macOS

Brick Viewer 2.4.10 Make Thermal Imaging Bricklet image view detachable Fix firmware auto-update for Co-MCU Bricklets Avoid potential config file writing collision between two Brick Viewer instances on Linux and macOS Notarize Brick Viewer app to make it ready for macOS 10.15 Fix potential crash in WIFI Extension 2.0 firmware update detection logic Fix exception hook for Python 3.8 Prefer hPa over mbar and Tesla over Gauss Add Data Logger support for RS232 Bricklet 2.0 data reading Add Server Monitoring support for Humidity Bricklet 2.0 temperature value Downloads: Windows, Linux, macOS

Brick Viewer 2.4.10 Thermal Imaging Bricklet Bildansicht ist abtrennbar Firmware-Auto-Update für Co-MCU Bricklets repariert Mögliche Config-Datei-Schreibkollision zwischen zwei Brick Viewer Instanzen auf Linux und macOS verhindert Brick Viewer App ist notariziert, um bereit für macOS 10.15 zu sein Möglichen Crash in der WIFI Extension 2.0 Firmware Update-Erkennung behoben Exception Hook für Python 3.8 repariert Bevorzugt hPa über mbar und Tesla über Gauss Data Logger Support für Lesen der Daten des RS232 Bricklet 2.0 hinzugefügt Server Monitoring Support für Humidity Bricklet 2.0 Temperature Wert hinzugefügt Downloads: Windows, Linux, macOS

Brick Logger 2.1.2 Add support for RS232 Bricklet 2.0 data reading Downloads: Windows, Linux, macOS, RED Brick

Brick Logger 2.1.2 Support für Lesen der Daten des RS232 Bricklet 2.0 hinzugefügt Downloads: Windows, Linux, macOS, RED Brick

Bist du mit deinem PC denn im gleichen Netz wie der RED Brick? Teste auch mal bitte mit der IP Adresse des RED Bricks (laut Screenshot: 192.168.1.163) in Brick Viewer, anstatt mit dem Hostnamen red-brick. Vielleicht verbindet dein Router die Informationen aus DNS und DHCP nicht miteinander, so dass der Hostname nicht aufgelöst werden kann.

Die aktuelle brickd Version ist auf GitHub verfügbar: https://github.com/Tinkerforge/brickd https://github.com/Tinkerforge/daemonlib

Und was genau hat jetzt geholfen?

Well, Microsoft kills that hope too. I've looked into this shortly after you suggested this. It's basically working but auto-detection is the problem again. I've now commit the experimental HAT (Zero) Brick support, that I had sitting on my PC since summer, collecting dust. You can test it using the latest brickd source code from GitHub. See the Windows 10 IoT Core readme section for some hints about how to enable it. It's disabled by default, because Windows 10 IoT Core doesn't provide any kind of HAT detection. As far as I can tell, there is no proper way for Brick Daemon to detect if a HAT is connected or not or what kind of HAT it is. The UWP Devices API doesn't even allow access to the GPIO pins that Raspbian uses for HAT detection on Linux.

Seit der Beta ist da nicht viel passiert. Es gab ein paar kleine Bugfixes zu diesem Thema in Brick Daemon, das grundsätzliche Problem ist aber immer noch vorhanden. Bricks tauchen unter Windows 10 IoT Core nicht so als USB Geräte auf, dass brickd direkt mit ihnen arbeiten könnte. Erst nach der beschriebenen manuellen Registryänderung kann brickd auf per USB angeschlossene Bricks zugreifen. Nach meinem Verständnis ist das bei Bug im USB Stack von Windows 10 IoT Core, da es mit Windows 10 IoT Desktop ohne Probleme funktioniert. Ich habe versucht das Problem an Microsoft zu melden, aber ohne Erfolg. Daher gibt da keine Pläne, denn ich wüsste nicht was ich tun sollte, außer darauf zu warten, das Microsoft das Problem irgendwann behebt. Der aktuelle Stand ist folgender: Der Windows 10 IoT Core Support für über USB an einem Raspberry Pi angeschlossene Bricks ist Teil der normalen Brick Daemon Codebase. Es gibt aktuell aber keinen vorkompilierten direkt installierbaren Brick Daemon für die Universal Windows Platform (UWP) und damit Windows 10 IoT Core. Du kannst aber mit der kostenlosen Visual Studio 2019 Version den aktuellen Brick Daemon Sourcecode für UWP kompilieren und auf einem Raspberry Pi installieren. Abgesehen von der händischen Registryänderung funktioniert das problemlos. Die Readme hat mehr Details dazu, siehe den Windows 10 IoT Core Abschnitt.

RED Brick Image 1.15 Add support for RTL8821CU USB WiFi + Bluetooth dongle Workaround Ethernet Extension W5500 buffer config reset bug Update Brick Viewer to version 2.4.9 Update all API bindings: C/C++ 2.1.27, C# 2.1.25, Delphi/Lazarus 2.1.26, Java 2.1.25, JavaScript 2.1.25, Octave 2.0.25, Perl 2.1.25, PHP 2.1.24, Python 2.1.24, Ruby 2.1.24, Shell 2.1.24, Visual Basic .NET 2.1.24 Download: RED Brick Image

RED Brick Image 1.15 Support für RTL8821CU USB WLAN + Bluetooth Stick hinzugefügt Workaround für Ethernet Extension W5500 Buffer Config Reset Bug hinzugefügt Brick Viewer auf Version 2.4.9 aktualisiert Alle API Bindings aktualisiert: C/C++ 2.1.27, C# 2.1.25, Delphi/Lazarus 2.1.26, Java 2.1.25, JavaScript 2.1.25, Octave 2.0.25, Perl 2.1.25, PHP 2.1.24, Python 2.1.24, Ruby 2.1.24, Shell 2.1.24, Visual Basic .NET 2.1.24 Download: RED Brick Image

Es gibt ein paar kleine API Unterschiede: read/write/CALLBACK_READ: Bei 1.0 wird immer eine Liste der Länge 60 Byte übergeben, zusammen mit einem zusätzlichen Längenwert der ausdrückt wie viele Bytes in der Liste gültig sind. Bei 2.0 gibt es den zusätzlichen Längenwert nicht mehr und die Länge der Liste ändert sich entsprechend der Länge der gültigen Daten. set_configuration: Die beiden Flowcontrol Parameter wurden bei 2.0 zusammengefasst

Der HAT Brick ist der erste Brick, der nicht mehr die alten 10 Pol Bricklets unterstützt, sondern nur noch die neuen 7 Pol Bricklets. Siehe Hinweis in der Dokumentation: https://www.tinkerforge.com/de/doc/Hardware/Bricks/HAT_Brick.html#beschreibung Alle andere Bricks unterstützen die alten 10 Pol und die neuen 7 Pol Bricklets. Da das RS232 Bricklet (1.0) aber ein 10 Pol Bricklets ist funktioniert es an einem HAT Brick leider nicht, auch wenn du es durch falsche Verwendung eines 10 Pol auf 7 Pol Brickletkabels an einem HAT Brick rein mechanisch anschließen kannst. Es gibt keine Möglichkeit ein 10 Pol Bricklet an einem HAT Brick zu betreiben.

In den Daten sehen ich Folgendes: Es kommen sehr häufig mehrere Pakete in einem Socket Read an (data_history, 3. Spalte ist die Paketlänge), bis dann dauerhaft 8192 Byte pro Socket Read ankommen mit längeren Pausen dazwischen. Die Kommunikation ist also sehr Burst-artig. Das ist unerwartet. Die Exception kommt dann, weil da zwischen zwei Paketen 3 Byte extra stehen, die da nicht hingehören. Zur Veranschaulichung: Es kommen abwechselnd zwei Callbacks an, A und B. In der ersten Zeile die normale Abfolge ABAB, alles vollständig, alles okay. In der zweiten Zeile der kaputte Fall. Erst kommt ein normales A an, gefolgt von den ersten 3 Byte eines B, das sind die 3 Byte die da nicht hingehören. Dann ein normales B, gefolgt von einem A bei dem die ersten 3 Byte fehlen, dann wieder ein normales B. [ A ][ B ][ A ][ B ] [ A ][ B.. ][ B ][ ..A ][ B ] Die Frage ist jetzt wo diese Veränderung der Daten wegkommt. Ist es möglich den Master Brick über USB statt Ethernet anzuschließen, um zu testen ob das Problem durch die Ethernet Verbindung bzw die Ethernet Extension entsteht? Läuft auf allen Brick und Bricklets die aktuelle Firmware (Brick Viewer kann dir das sagen)?

Ich muss mir die Ausgabe noch genauer ansehen, was aber schon auf den ersten Blick auffällt ist, dass die pending_data 6645 Byte lang sind. Es scheint doch zu passieren, was ich für unwahrscheinlich hielt. The Receive Thread ließt eingehende Daten vom Socket und sammelt die in pending_data auf. Nach jedem Empfangen wird dann geprüft , ob genug Daten da sind um daraus ein Paket zu dekodieren. Die absolute maximale Paketlänge ist 80 Byte. Damit sich 6645 Byte in pending_data aufstauen können, müssen die mehr oder weniger in einem Receive Aufruf ankommen. Das sollte erstmal kein Problem sein, die IP Connection kommt damit zurecht. Das Problem hier ist, dass die IP Connection hier versucht ein Paket der Länge 0 zu dekodieren. Die minimale Länge ist aber 8 Byte. Das hat jetzt zwei mögliche Ursachen. Entweder schickt eines der Bricklets ein Paket mit falschen Wert im Längenfeld, das führt zu einem Offset in der Dekodieren der IP Connection die dann ultimativ die Daten falsch versteht. Oder beim Ethernet Transport gehen Daten verloren oder werden verfälscht, was zum gleichen Ergebnis führt. Hilfreich wäre es einen vollständigen Dump zu haben.