photron

Brick Viewer 2.4.18 ist veröffentlicht.

Brick Logger 2.1.6 Fehler beim Öffnen der Debug-Logdatei werden behandelt Downloads: Windows, Linux, macOS, RED Brick

Brick Logger 2.1.6 Handle errors while opening debug log file Downloads: Windows, Linux, macOS, RED Brick

Brick Viewer 2.4.18 Add minimal health monitor dialog Fix state handling for untabbed plugins Force correct UI state after aborting autoreconnect on error Handle errors while opening Data Logger debug log file Update download.tinkerforge.com certificate chain to fix update autodetection Autoselect download directory for Brick Viewer downloads Check if NFC Bricklet is in correct state to start cardemu discovery Downloads: Windows, Linux, macOS

Brick Viewer 2.4.18 Minimalen Health-Monitor-Dialog hinzugefügt Zustandlogik von ausgeklinkten Plugins repariert Korrekter GUI-Zustand wird beim Abbruch der Autoreconnect-Logik durch einen Fehler wiederhergestellt Fehler beim Öffnen der Data Logger Debug-Logdatei werden behandelt Zertifikat für download.tinkerforge.com aktualisiert um die automatische Update-Erkennung zu reparieren Brick Viewer Updates werden ins Download-Verzeichnis heruntergeladen NFC Bricklet Zustand wird vor dem Start einer Cardemu-Discovery geprüft Downloads: Windows, Linux, macOS

Laut Log wurde der Master Brick getrennt, brickd versucht die offenen USB Read Transfers abzubrechen. Das klappt aber nicht, da libusb behauptet diese nicht mehr zu kennen. Dann versucht brickd den libusb Handle für den Master Brick zu schließen. Intern läuft libusb dann über die Liste der offenen USB Transfers für den Master Brick und crasht dabei. Auch wenn die USB Geräte schnell auftauchen und wieder verschwinden sollte daran brickd bzw libusb nicht crashen. Ich befürchte fast, dass das ein alter Bug in libusb ist. Brick Daemon für Windows kommt aktuell mit einer 2 Jahre alten libusb Version. In der Zwischenzeit ist viel im Inneren von libusb passiert. Ich denke ich muss mal die ganzen libusb Altlasten aus brickd loswerden, allgemein die libusb Version erhöhen und unter Windows eine aktuelle libusb Version ausliefern. Kannst du diesen "Wackelkontakt" noch einen Moment nicht beheben? Ich würde dir gerne noch eine weitere brickd Version zum Testen geben mit aktueller libusb, um zu sehen, ob das dass Problem behebt. Wenn ich das schnell hinbekommen, vielleicht sogar noch heute.

Ich hatte es getestet und auf unserem älteren MacBook mit Mojave tritt das Problem auf, auf unserem neueren MacBook mit Catalina allerdings nicht. Bei einem anderen Kunden tritt es auf Big Sur auf. Mir ist auf Anhieb unklar warum. Bekommen wir aber raus.

Das Problem ist uns sein kurzem bekannt. Es betrifft das Abfragen der aktuellen Firmwareversionen und auch das automatische Herunterladen von Firmwares beim Updaten von Bricks und Bricklets. Händisches Updaten ist aber weiterhin möglich. Wahrscheinlich ein SSL Problem, das nichts mit deinem Mac an sich zu tun hat, sondern mit unserem Server. Brick Viewer warnt darüber dann aber sehr allgemein. Lösung verzögert sich leider bis nächste Woche, da @rtrbt diese Woche im Urlaub ist und ich auf die Schnelle nicht dazu kommen mir das anzuschauen.

Ich rate mal und sagt, dass du systemd verwendest. Systemd zeichnet standardmäßig die Ausgaben des Service auf und du kannst sie dir mit journalctl ansehen.

Das können die MQTT Bindings nicht. So funktioniert die Logik da nicht. Die Bindings reichen nur die Callbacks von der Hardware durch.

So, jetzt endlich! Zuerst den installieren Brick Daemon Dienst stoppen. Das kannst du über den Windows Dienste Manager oder den Brick Daemon Log Viewer tun. Dann die angehängte brickd.exe herunterladen. Ich habe sie unter C:\Users\photron\Downloads\brickd.exe gespeichert. Jetzt GDB installieren. Dazu lädst du dir mingw-w64-install.exe herunter. Auf der folgenden Seite dem Sourceforge Link folgen, der Download startet automatisch: http://mingw-w64.org/doku.php/download/mingw-builds Das dann mit den Standardeinstellungen installieren. Darauf hin findest du unter C:\Programme (x86)\mingw-w64 ein Verzeichnis mit kryptischen Namen, in meinem Fall i686-8.1.0-posix-dwarf-rt_v6-rev0. Darin wiederum ist eine mingw-w64.bat Datei. Diese starten. Darauf hin öffnen sind eine Kommandozeile. Jetzt GDB mit brickd.exe starten (angepasst auf den Pfad an dem du brickd.exe gespeichert hast): gdb --args "C:\Users\photron\Downloads\brickd.exe" --console GDB hat jetzt brickd.exe geladen, aber noch nicht gestartet. Dazu "r" eingeben (ohne Anführungszeichen) und Enter drücken. Brick Daemon sollte starten und Logmeldungen ausgeben. Jetzt das Problem erzeugen und brickd abstürzen lassen. GDB sollte den Absturz abfangen und unten links sollte (gdb) stehen. Dort jetzt "bt full" eingeben (ohne Anführungszeichen) und Enter drücken. Darauf hin gibt GDB länglich aus wo der Absturz passiert ist und wie das Programm zu dieser Stelle bekommen ist. Die gesamte Ausgabe des bt full Befehls bitte hier posten. brickd.exe

Ich habe gerade noch einen anderen Kunden beim dem brickd auch durch das USB Abziehen abzustürzen scheint. Ich bekomme es leider nicht hin das Problem hier zu reproduzieren. Kann ich dir zumuten eine spezielle brickd Version (die ich noch erstellen muss) in einem Debugger (z.B. GDB) laufen zu lassen, um einen Backtrace des Crashes zu bekommen?

@ts555 Sorry, das hat eine Weile gedauert, aber hier ist jetzt endlich eine brickd Testversion, die das Problem beheben sollte. brickd_windows_2_4_3_snapshot_b046504.exe

Moment, du hast auch dieses Problem hier: Laut diesem Thread kann man in MATLAB \r\n nicht so direkt hinschreiben. In Brick Viewer kannst du da aber einfach \r\n als Ende auswählen und da funktioniert es dann.

Du kannst die über RS232 empfangenen Daten auf 2 Weisen abfragen. Entweder durch Aufruf der read Funktion, oder durch Verwendung des Read Callbacks. Diese beiden Weisen schließen sich aber gegenseitig aus. Beim Read Callback registrierst du eine Funktion (in diesem Fall cb_read) beim rs232 Objekt. Diese Funktion wird dann vom rs232 Objekt aufgerufen, wenn ein Read Callback empfangen wird. Du selbst rufst nicht die cb_read Funktion auf, auch nicht mit dem Rückgabewert der write Funktion. Ein weiteres Problem ist, dass du nicht auf das Empfangen der Antwort vom Kalibrator wartest, sondern write, read und disconnect direkt hintereinander weg aufrufst. Zudem Zeitpunkt an dem read aufrufst ist das RS232 Bricklet möglicherweise noch nicht mal damit fertig die Daten an den Kalibrator zu senden. Im Loopback Beispiel wird über den Aufruf input('Press key to exit\n', 's'); das Beispiel laufen gehalten, so dass die Antwort ankommen kann. Die write Funktion blockiert nicht, bis die Daten wirklich über RS232 gesendet wurden und die read Funktion wartet nicht auf den Empfang von Daten. Beide arbeiten auf Buffern im Bricklet. Die write Funktion schreibt Daten in den Ausgangs-Buffer und die read Funktion liest Daten aus dem Eingangs-Buffer. Das Bricklet sendet und empfängt dann dazu asynchron Daten über die RS232 Schnittstelle und liest diesen aus den Buffern oder schreibt sie hinein. Wirf mal die cb_read Funktion raus und deren Registrierung (Zeile 17) und ersetzt die Aktivierung des Read Callback (Zeile 20) durch rs232.disableReadCallback(); um sicher zu sein das der Callback deaktiviert ist. Nach dem Aufruf der write Funktion baust du eine Pause von z.B. einer Sekunde ein, damit das Bricklet Zeit hat die Anfrage zu senden und die Antwort zu empfangen. Danach fragst du die Antwort über die read Funktion ab. Der read Funktion musst du mitgeben wie viel Zeichen der empfangenen Daten du lesen willst. Dazu musst du wissen wie lang die Antwort sein kann, hier nehmen ich mal 100 Zeichen an. rs232.write(String('DISP:LANG?\r\n').toCharArray()); pause(1); response = rs232.read(100); disp(response); ipcon.disconnect(); Das kann man jetzt noch effizienter machen, aber teste das erstmal so, um es ans Laufen zu bekommen.

Bindings: Shell 2.1.30 Force Python 3 in shebang line and deprecate Python 2 support Add gpio-state callback to Performance DC Bricklet API Download: Shell

Bindings: Shell 2.1.30 Shebang-Zeile erzwingt Python 3 und Python 2 Support ist deprecatet gpio-state Callback zur Performance DC Bricklet API hinzugefügt Download: Shell

Bindings: MQTT 2.0.14 Don't allow MQTT topic placeholders in init-file topics and topic prefix Force Python 3 in shebang line and deprecate Python 2 support Add gpio_state callback to Performance DC Bricklet API Fix streaming Accept integer parameters formatted as strings to allow JavaScript to properly send int64 arguments Add --int64-string-response commandline option to translate int64 results to string to allow JavaScript to properly receive int64 parameters Download: MQTT

Bindings: MQTT 2.0.14 MQTT Topic-Platzhalter sind in init-file Topics und dem Topic-Prefix nicht erlaubt Shebang-Zeile erzwingt Python 3 und Python 2 Support ist deprecatet gpio_state Callback zur Performance DC Bricklet API hinzugefügt Streaming repariert Integer Parameters werden als String formatiert akzeptiert, um JavaScript das Senden vom int64 Argumenten zu ermöglichen --int64-string-response Kommandozeilenoption hinzugefügt um int64 Werte als Strings auszugeben, damit JavaScript int64 Parameter korrekt empfangen kann Download: MQTT

Ich denke wir haben das Problem gefunden. Es gibt eine relevante Änderung zwischen 2.1.31 und 2.1.32, die betrifft aber nur Node.js < 10.4. Testet bitte mal die angehängte Version. tinkerforge_javascript_bindings_2_1_33.zip

So funktioniert TCP/IP nicht. Eine Verbindung bleibt solange bestehen bis sie aktiv geschlossen wird. Das passiert aber beim Trennen der Stromversorgung nicht. Daher denke die IPConnection weiterhin verbunden zu sein, weil sie das rein technisch auch ist. Der aktuell beste Weg damit in deinem Fall umzugehen ist auf die Timeout Fehler zu achten. Wenn z.B. 3 Timeouts hintereinander passieren dann kannst du das als Auslöser für ein Neuverbinden nehmen und auf der IPConnection disconnect() gefolgt von connect() aufrufen.

Teste mal bitte das Loopback Beispiel, ignoriere dabei aber den Kommentar über RX1 und TX Pin, sondern lass den Jumper auf RX1 und RX2: https://www.tinkerforge.com/de/doc/Software/Bricklets/RS232V2_Bricklet_MATLAB.html#loopback-matlab Dort änderst du die UID von XYZ auf MbG und den Host von localhost auf 192.168.42.1. Ansonsten änderst du vielleicht noch die Konfiguration wenn der Fluke Kalibrator nicht mit 115200 Baud 8N1 kommuniziert.

0 lx always indicates an invalid measurement. Unfortunately, the datasheet of the sensor doesn't document under which conditions this could happen. With testing we found that this happens if you saturate the sensor. For example, by selecting an illuminance range that is way too small or an integration time that is way too long for the current light conditions. Hence the documentation suggesting to adapt the configuration in that case. But another user already found that this could also happen under very dim light conditions. I could reproduce this by covering the sensor with two sheets of printer paper and a piece of duct tape. I was going to update the documentation about this at the time. But it seems this never happend. If updated the documentation now.

Sorry, bisher nicht. Aktuell ist hier alles auf Wallboxen fokussiert.

Es gibt keine Änderungen zwischen 2.1.31 und 2.1.32, die das Problem erklären könnten. Überhaupt sind die Änderungen zwischen 2.1.31 und 2.1.32 sehr minimal. Ich habe gerade ein Callback Beispiel in Node.js 12.20.1 mit Bindings 2.1.31 und 2.1.32 getestet. Diese funktionieren wie erwartet. Tritt das Problem nur in deinem Programm auf, oder auch wenn wenn du z.B. das Callback Beispiel des Temperature Bricklet 2.0 testest?