photron

That's strange, that dpkg doesn't complain like this when you tried to install the amd64 version. Anyway, we currently don't provide a precompiled brickd for arm64. Therefore, compiling from source is the best option you currently have for arm64.

The NVIDIA Jetson TX2 has an ARM CPU, but you're trying to install the amd64 version of brickd. Try the armhf version instead.

The Mathematica Bindings don't use MathLink, they use .NET/Link. Did you follow the insallation guide here? https://www.tinkerforge.com/en/doc/Software/API_Bindings_Mathematica.html

Auf dem RED Brick läuft eine Bash Konsole. Die offizielle Anleitung dazu: https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html Zu Bash gibt es im Internet haufenweise Anleitungen und Tutorials.

Versuch auf deinem PC mal nicht irgendwelche Verzeichnisstrukturen nachzubilden, sondern gib beim Hochladen über den "Add Files" Knopf mal nur die EmailComTest.exe und die Testdatei.txt Datei an. Dann guckst du dir mit ls auf der RED Brick Console mal Schritt für Schritt an, wie die Verzeichnisstruktur aussieht: ls programs ls programs\EmailComTest ls programs\EmailComTest\bin

Den Pfad programs/EmailComTest/bin/ kannst du beim Hochladen des Programms über Brick Viewer gar nicht angeben. Der wird automatisch konstruiert. Ich glaube hier liegt das Missverständnis. Ich hatte angenommen, du hättest beim Hochladen einfach nur die Datei EmailComText.exe angegeben. Jetzt glaube ich du hast da ein Verzeichnis mit Unterverzeichnissen angegeben. Es passiert da intern folgendes: Es gibt auf dem RED Brick im Home-Verzeichnis des tf Nutzers das programs-Verzeichnis. Der Name ist fest, davon siehst du in Brick Viewer nichts. Beim Hochladen des Programms muss du dem Kind einen Namen geben. Ich ging davon aus, dass du da EmailComTest angegeben hast. Daraus ergibt sich dann der Name des Unterverzeichnisses im programs-Verzeichnis: programs/EmailComTest/ Darin wird dann wiederum das bin-Verzeichnis angelegt. Der Name ist fest, davon siehst du in Brick Viewer nichts: programs/EmailComTest/bin/ Darein lädt jetzt Brick Viewer die Dateien hoch, die du für das Programm angegeben hast. Wenn du beim Hochladen ein Verzeichnis angegeben hast, dann erstellt Brick Viewer den Inhalt des Verzeichnisses samt Unterverzeichnissen im bin-Verzeichnis: programs/EmailComTest/bin/ Da du beim Hochladen aber vermutlich nicht einfach EmailComText.exe angeben hast kommt da dann nicht programs/EmailComTest/bin/EmailComText.exe beim rum, sondern zwischen bin/ und /EmailComText.exe sind noch mehr Unterverzeichnisse, die du Brick Viewer mit hochladen lassen hast.

WebSockets auf der WIFI Extension 2.0 können aktuell nicht deaktiviert werden. Die JavaScript Browser Bindings nutzen WebSockets, alle anderen Bindings nutzen normale Sockets.

Lau deinen Screenshots muss es so lauten: mono programs/EmailComTest/bin/EmailCom.exe

Schwierig, am wahrscheinlichsten ist das Bricklet tot. Was du versuchten kannst, ist das Bricklet an einem anderen Port des Bricks anzuschließen, mit der Annahme, dass der Port am Brick an dem des jetzt hängt beschädigt ist, warum auch immer. Mal ein anderes Bricklet Kabel testen? Du kannst auch noch prüfen, ob am Brick überhaupt noch Bricklets funktionieren. Ist das IDI4 das einzige Bricklet an diesem Brick, oder sind noch andere Bricklets am gleichen Brick angeschlossen die noch funktionieren. Der Brick an dem das IDI4 hängt tauch aber noch in Brick Viewer auf? Was für ein Brick ist das überhaupt?

Teste mal bitte diese Version: https://download.tinkerforge.com/_stuff/brickv_macos_2_4_9_snapshot_f1b3cde.dmg

Brick Viewer 2.4.9 Fix Bricklet auto-update crash Allow to choose other versions than the latest when flashing firmwares Allow to write hex bytes in hex mode in RS485 Bricklet plugin Allow to specify coil/register values when writing multiple coils/registers in RS485 Bricklet plugin Delete key works correct in RED Brick plugin console tab Downloads: Windows, Linux, macOS

Brick Viewer 2.4.9 Bricklet Auto-Update Crash repariet Es können auch ältere Firmwares zum Flashen ausgewählt werden Im RS485 Bricklet Plugin können im Hex Modus auch Bytes geschrieben werden Mehrere Coil/Register Werte können beim Schreiben im RS485 Bricklet Plugin angegeben werden Entfernen-Taste funktioniert in der Konsole des RED Brick Plugins Downloads: Windows, Linux, macOS

Wir können das Problem nachstellen. Es ist ein Sampling Problem in Brick Viewer.

Siehst du diesen Effekt auch, wenn du das Bricklet mit einem eigenen Programm und nicht mit Brick Viewer abfragst? Brick Viewer fragt die Daten per Getter mit 10 Hz ab. Ich denke nicht, dass da Daten fehlen. Abgesehen vom zeitlichen Versatz bzw verdoppelten Messwerten fehlt da ja nichts.

Brick Viewer 2.4.8 Fix firmware download on newer macOS versions Downloads: Windows, Linux, macOS

Brick Viewer 2.4.8 Firmware-Download auf neueren macOS Versionen repariert Downloads: Windows, Linux, macOS

Teste mal bitte diese Version: https://download.tinkerforge.com/_stuff/brickv_macos_2_4_7_snapshot_268f03d.dmg

Das hat nichts mit der Python version tun, denke ich. Wir nutzen PyInstaller um brickv in eine App einzupacken. Die App beinhaltet dann auch Python und die SSL Zertifikate. Wir sind schon öfter darüber gestolpert, dass sich Python, wenn es durch PyInstaller gegangen ist subtil anders verhält. Das hier ist wohl wieder so ein Fall. Es mag hier einfach daran liegen, dass PyInstaller nicht den ganzen oder einen anderen CA Store einpackt und Python dann das SSL Zertifikat unseres Download Servers nicht verifizieren kann, da die passende Chain of Trust nicht mit eingepackt wurde.

Brick Logger 2.1.1 Add support for Color 2.0, Compass, Distance US 2.0, Energy Monitor, Multi Touch 2.0 and Rotary Poti 2.0 Bricklet Downloads: Windows, Linux, macOS, RED Brick

Brick Logger 2.1.1 Support für Color 2.0, Compass, Distance US 2.0, Energy Monitor, Multi Touch 2.0 und Rotary Poti 2.0 Bricklet hinzugefügt Downloads: Windows, Linux, macOS, RED Brick

Wir konnten das Problem nachstellen auf einer neueren macOS Version. Es scheint was mit den SSL Zertifikaten zu tun zu haben. Python beschwert sich https://download.tinkerforge.com nicht verifizieren zu können. Lösung ist in Arbeit.

Kommt diese Fehlermeldung jedes mal wenn du auf dem Update/Flashing Dialog auf den Search for Updates Knopf klickst?

Hast recht, ich habe das Changelog mal angepasst. Hier ging es darum die Verwendung von Object Pointern für das Übergeben/Speichern von Function Pointern abzustellen. Da in C den korrekten Type für alle möglichen Callbacks zu erwarten ist nicht möglich, da C keine Überladung kann. Das könnte man nur in reinen C++ Bindings lösen.

Wir konnten das Problem eben einmal nachstellen, jetzt aber nicht mehr. Tritt es bei dir jetzt noch auf?

Es wirkt so als ob Brick Daemon zu früh gestartet wird. Dienste können untereinander Abhängigkeiten haben, aber ich kann nicht so richtig rausbekommen, was hier die richtige Abhängigkeit ist. Teste mal bitte die folgenden drei Abhängigkeiten durch. Starte eine Eingabeaufforderung als Administrator und gib dort einen der Befehle ein und starte dann den Rechner neu. sc config "Brick Daemon" depend=tcpip sc config "Brick Daemon" depend=netman sc config "Brick Daemon" depend=lanmanserver