photron

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?

Warum versuchst du eine Methode für den Servo Bricklet 2.0 PositionReached Callback auf den IPConnection Enumerate Callback Delegate zuzuweisen?

Wie die Dokumentation schon sagt schaltet eine Frequenz von 0 die PWM Funktion aus. Du solltest dir eine Frequenz (> 0) auswählen und diese dann fix beibehalten. Welche Frequenz du wählen solltest hängt von deiner Anwendung ab. Wenn du die Frequenz zu niedrig wählst dann kannst du bei niedrigen Duty Cycle die LED flackern sehen.

Das ist erwartet. Mosquitto erwartet bei "require_certificate true", dass sich der Client (tinkerforge_mqtt in diesem Fall) per Client Zertifikat ausweißt. Das tut tinkerforge_mqtt aktuelle nicht. Das müsste man tinkerforge_mqtt erst beibringen, damit du neben ca.cert auch client.crt und client.key angeben könntest.

Normalerweise lässt du die Frequenz fest und änderst den Duty Cycle. Bei 100% Duty Cycle liegen durchgehend 3,3V an.

Keine Fehler in den Logs. Für den RED Brick sieht es so aus also ob der Master Brick nicht da wäre. Ich bleibe dabei, die beste Erklärung ist ein Kontakt- oder Lötproblem an den Stapelsteckern, auch wenn es auf den Fotos (soweit sich das erkennen lässt) kein Problem zu sehen ist. Da bleibt mir als nächstes leider nur vorzuschlagen den Stapel zur Reparatur einzuschicken.

Weitere Fragen: Macht es einen Unterschied, wenn du die WIFI Extension aus dem Stapel weglässt? Macht es einen Unterschied, wenn du nach dem Booten des Stapels den Master Brick über dessen Reset Knopf im laufenden Betrieb neustartest? Kannst du das brickd.log vom RED Brick hier anhängen? Die Logdatei kannst du über Brick Viewer auf dem RED brick Tab unter Import/Export System Logs herunterladen.

Mir ist unklar was genau dein Problem hier ist. Brickd an sich kann kein SSL. Die MQTT Bindings können auf der MQTT Seite SSL. Welche Kommandozeilenargumenten meinst du? Das Problem hier ist das tinkerforge_mqtt in seiner Shebang Zeile noch auf Python 2 verweist. Das sollte ich mal auf Python 3 ändern, da Python 2 jetzt über ein Jahr EOL ist. Da du die Abhängigkeiten für Python 3 installiert hast, tinkerforge_mqtt aber mit Python 2 läuft, findest es Paho MQTT nicht. Teste mal bitte die angehängte Version die jetzt auf Python 3 gesetzt ist. tinkerforge_mqtt_bindings_2_0_14_rc1.zip

Dass das LCD Beispielprogramm auf dem RED Brick nicht funktioniert, wenn der RED Brick den Master Brick und damit das LCD Bricklet nicht sieht ist nicht verwunderlich. Von der Beschreibung her ist das ein Kommunikationsproblem zwischen RED Brick und Master Brick, vermutlich bedingt durch ein Hardwareproblem. Aber es fehlt dennoch der Master Brick in Brick Viewer auch wenn die Extension auf dem RED Brick anzeigt wird? Dann sind im Stapel die Leitungen für die Extension okay, aber zumindest für den ersten Brick im Stapel nicht. Hast du noch einen weiteren Brick (kein RED Brick) zur Hand? Was passiert, wenn du einen weiteren Brick zwischen RED Brick und dem problematischen Master Brick steckst? Ich vermute ein Kontakt- oder Lötproblem am linken oberen Stapelstecker (von der mini-USB Buchse aus gesehen) am RED Brick oder dem linken unteren Stapelstecker am Master Brick. Schau dir bitte mal genau die Kontakte dieser beiden Stecker an und auch deren Verlötung mit der Platine. Vielleicht sitzt da auch einfach nur etwas Schmutz in den Steckern der den Kontakt behindert? Kannst du ein Foto des Aufbaus mit RED Brick zeigen?

Brick Logger 2.1.5 Support für Performance DC Bricklet und Servo Bricklet 2.0 hinzugefügt Downloads: Windows, Linux, macOS, RED Brick

Brick Logger 2.1.5 Add support for Performance DC Bricklet and Servo Bricklet 2.0 Downloads: Windows, Linux, macOS, RED Brick

Brick Viewer 2.4.17 Add support for Performance DC Bricklet and Servo Bricklet 2.0 Downloads: Windows, Linux, macOS

Brick Viewer 2.4.17 Support für Performance DC Bricklet und Servo Bricklet 2.0 hinzugefügt Downloads: Windows, Linux, macOS

Bindings: C/C++ 2.1.31, C# 2.1.29, Delphi/Lazarus 2.1.30, Go 2.0.10, Java 2.1.30, JavaScript 2.1.32, LabVIEW 2.1.28, Mathematica 2.1.28, MATLAB/Octave 2.0.30, MQTT 2.0.13, Perl 2.1.29, PHP 2.1.28, Python 2.1.28, Ruby 2.1.28, Rust 2.0.17, Saleae 2.0.5, Shell 2.1.29, Visual Basic .NET 2.1.28 Add support for Performance DC Bricklet and Servo Bricklet 2.0 [all] Fix Base58 decoding in Delphi 7 [Delphi/Lazarus] Fix BigInt detection for 64-bit integer support [JavaScript] Fix bool array unpacking [Ruby] Download: C/C++, C#, Delphi/Lazarus, Go, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, MQTT, Perl, PHP, Python, Ruby, Rust, Saleae, Shell, Visual Basic .NET

Bindings: C/C++ 2.1.31, C# 2.1.29, Delphi/Lazarus 2.1.30, Go 2.0.10, Java 2.1.30, JavaScript 2.1.32, LabVIEW 2.1.28, Mathematica 2.1.28, MATLAB/Octave 2.0.30, MQTT 2.0.13, Perl 2.1.29, PHP 2.1.28, Python 2.1.28, Ruby 2.1.28, Rust 2.0.17, Saleae 2.0.5, Shell 2.1.29, Visual Basic .NET 2.1.28 Support für Performance DC Bricklet und Servo Bricklet 2.0 hinzugefügt [alle] Base58 Dekodierung in Delphi 7 repariert [Delphi/Lazarus] BigInt Erkennung für 64-bit Integer Support repariert [JavaScript] Bool Array Unpacking repariert [Ruby] Download: C/C++, C#, Delphi/Lazarus, Go, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, MQTT, Perl, PHP, Python, Ruby, Rust, Saleae, Shell, Visual Basic .NET