photron

Okay, mit einer neueren GCC Version können wir hier das Problem nachstellen. Es ist jetzt in der aktuellen GitHub Version behoben. https://github.com/Tinkerforge/master-brick/commit/80ded4b682ffb063fe88133eecf81c7770a9b6d2

Teste mal bitte #define logf(str, ...) {} durch #define logf(str, ...) ((void)0) zu ersetzen.

Dann leg mal bitte die Umgebungsvariable HTTPS_PROXY mit dem Wert www.example.com:3128 (natürlich angepasst auf deinen Proxy) an. Wenn du Brick Viewer startest sollte er dir das als Proxy Einstellung anzeigen.

Ich kann das Problem hier unter Linux mit Docker und dem aktuellen GitHub Stand der Master Brick Firmware nicht nachstellen. Hast du dir mit build_environment_setup.sh unter Linux oder in einer VM die Build Umgebung ausgesetzt, oder nutzt du das Docker Image?

Unfortunately. this ist not true. The CMP11 pyranometer outputs a 0 to 20 mV signal, this cannot be measured with a PTC Bricklet 2.0. The PTC Bricklet 2.0 is designed to measure the resistance of a PTC sensor. Also there is no Bricklet that can measure such small voltages accurately enough for this use case. There is the SMP series of pyranometers that output a 4 to 20 mA signal, that can be measured using an Industrial Dual 0-20mA Bricklet 2.0: https://www.rg-messtechnik.de/smp-pyranometer.php

ts555, was ich in Python tun müsste ist klar. Ich will aber vermeiden, dass händisch tun zu müssen, da Python das automatisch kann, wenn in Windows der Proxy richtig eingestellt ist. Bei dir scheint das aber nicht der Fall zu sein. Heißt das, dass du in jedem Programm, das sich mit dem Internet verbindet, auf deinem Firmen PC händisch den Firmen Proxy eingestellt hast? Versuch mal in Windows den Proxy einzustellen, anstatt für jedes Programm einzeln: Einstellungen -> Netzwerk und Internet -> Proxy -> Manuelle Proxyeinrichtung "Proxyserver verwenden" einschalten Adresse: www.example.com Port: 3128 "Proxyserver nicht für lokale Adressen verwenden" einschalten Änderungen mittels "Speichern" Knopf speichern. Die Werte für Adresse und Port habe ich jetzt entsprechend deines Beispiels gewählt. Da musst du natürlich deine richtig Proxy Konfiguration eintragen. Dann sollte dir das Brick Viewer beim Start auch anzeigen und die Firmware Abfrage sollte funktionieren.

ts555, du hast da noch einen anderen Bug gefunden. Du versuchst da gerade eine Co-Prozessor Bricklet Firmware auf ein nicht vorhandenes Bricklet an Port B des Master Bricks zu flashen. Das geht nicht. Das erzeugt diese falsche Fehlermeldung, da diese Situation in Brick Viewer nicht richtig behandelt wird. Ich habe das gerade für die nächste Brick Viewer Version behoben. Wenn du da jetzt das XMC1400 Breakout Bricklet mit dessen Standard-Firmware flashen würdest, dann sollte das funktionieren. Testet auch mal bitte diese Version: https://download.tinkerforge.com/_stuff/brickv_windows_2_4_11_snapshot_e750b42.exe Die zeigt beim Start jetzt eine Meldung mit der von Python erkannten Proxy Konfiguration an. Ich vermute das bei euch beiden nur eine Proxy Konfiguration für HTTP, aber nicht für HTTPS erkannt wird und das das Problem hier ist. Wenn ich hier testweise unter Windows 10 in den Windows Netzwerkeinstellungen als Proxy foobar.com:5544 einstelle, dann zeigt mir Brick Viewer das beim Start so an: http: http://foobar.com:5544 https: https://foobar.com:5544 ftp: ftp://foobar.com:5544 Wenn ich aber bei der Proxy Einstellung http://foobar.com:5544 eintrage, dann kommt das in Python nur als HTTP Proxy an: http: http://foobar.com:5544 Wie und wo ist bei euch der Proxy in Windows eingestellt?

Teste mal bitte diese beiden Versionen: https://download.tinkerforge.com/_stuff/brickv_windows_2_4_11_snapshot_9857a16_http.exe https://download.tinkerforge.com/_stuff/brickv_windows_2_4_11_snapshot_9857a16_https.exe Die HTTP Version ist der aktuelle Entwicklungsstand mit allen https://download.tinkerforge.com URLs auf http:// geändert. Die HTTPS Version ist der aktuelle Entwicklungsstand unverändert. Damit sollte jetzt raus zu bekommen sein, ob es rein an HTTPS liegt. Laut Dokumentation sollte Python automatisch einen in Windows eingestellten Proxy nutzen: https://docs.python.org/3.7/library/urllib.request.html#urllib.request.getproxies

Ja ist es. Es gibt 6 Slider. Der Fehler ist korrigiert. Danke für den Hinweis.

The documentation should actually have said "\x08" for the \x escape sequence, but due to incomplete escaping the documentation on the website was missing the backslash. Thank you for reporting this bug. The documentation text cannot be programming language specific, that's why it used the common \x escape sequence. Unfortunately, Java doesn't support the \x escape sequence. I've added the missing backslash for the \x escape sequence and also added the \u escape sequence for programming languages that lack support for \x.

Firmware: WIFI Extension 2.0 2.1.4 Enforce minimum AP password length of 8 chars Try three times to load config from EEPROM before using default config Remove support for mesh router password getter Download: WIFI Extension 2.0

Firmware: WIFI Extension 2.0 2.1.4 Minimale AP Password Länge von 8 Zeichen wird überprüft Erst nach drei erfolglosen Versuchen die Konfiguration aus dem EEPROM zu laden wird die Standardkonfiguration verwendet Support für Mesh Router Password Getter entfernt Download: WIFI Extension 2.0

Du kannst an jeden Brick so viele Bricklets anschließen, wie dieser dafür Anschlüsse hat. Dabei kann jedes Bricklet frei mit jedem Brick kombiniert werden. Bricks werden im einfachsten Fall per USB an einem PC angeschlossen und von dort ausgesteuert. Es können aber auch mehrer Bricks übereinander gestapelt werden und der ganze Stapel dann über ein USB Kabel kontrolliert werden, dabei muss dann der unterste Brick im Stapel ein Master Brick sein. Wenn USB nicht das Mittel der Wahl ist, kann dem Stapel auch noch eine WIFI oder Ethernet Extension hinzugefügt werden, um den Stapel anstatt über USB dann über WLAN oder Ethernet Kabel zu steuern. Ohne jetzt genauer die benötigenden Spannungen und Stromstärken für die Weichen und Signale zu kennen schlage ich für 60 digitale Ausgänge folgenden Aufbau vor: 1x Master Brick 4x IO-16 Bricklet 2.0 4x Bricklet Kabel 7p-10p 1x miniUSB Kabel Das zusammengebaut gibt dir 64 digitale Ein-/Ausgänge die mit 3,3V oder 5V jeweils 10mA treiben können. Wenn das bezüglich Spannung oder Stromstärke nicht reicht, dann kann die Treiberleistung durch einen vorgeschalteten Transistor pro Ausgang oder Treiber ICs wie dem 8-Kanal ULN2803A erhöht werden.

Teste mal bitte wirklich unter freiem Himmel. Schau auch mal nach, ob der Antennenstecker richtig sitzt. Der goldene kleine Stecker oben links hier im Bild:

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