photron

All unsere API Bindings für die verschiedenen Programmiersprachen nutzen intern unser TCP/IP Protokoll. Daher kannst du dir irgendeins unserer API Bindings ansehen als Beispiel dafür wie das TCP/IP Protokoll zu nutzen ist. Aber kannst du auf dem cRIO nicht einfach unsere .NET basierten LabVIEW Bindings einsetzen? Oder unterstützt der cRIO .NET nicht?

Es sollte prinzipiell jeder LTE USB Stick funktionieren. Wenn du einen zur Hand hast, dann probier das einfach mal aus. In dem Sinne unterscheidet sich ein UMTS USB Stick und ein LTE USB Stick aus der Sicht des RED Bricks nicht.

Okay, wenn du also schon weißt, dass es vor dem Hinzufügen von SQLite und dem Solid State Relay besser war, dann sollte es nicht so schwer sein das Problem zu finden. Hast du deinen Code unter Versionskontrolle (git, svn, hg ...)? Sprich hast du noch eine alte Version deines Programs, bevor das Problem aufgetreten ist? Dann teste diese alte Version jetzt noch mal, nur um sicher zu gehen, dass das Problem durch Änderungen an deinem Programm entstanden ist und nicht durch irgendetwas anderes was sich in der Zwischenzeit geändert hat. Wenn das Problem in deinem Programm ist, dann sollte die alte Version jetzt auch noch gut laufen. Wenn eine alte Version des Programm besser läuft, dann muss es an etwas liegen, dass du in deinem Programm geändert hast. Es mag an SQLite liegen, auch wenn dein Betreuer das für unwahrscheinlich hält. Solange du nicht beweisen kannst, dass SQLite nicht das Problem ist, solltest du das nicht einfach so ausschließen. Es man nicht SQLite im allgemeinen sein, aber vielleicht verwendest du SQLite in einer ungünstigen Weise. Das kannst du testen in dem du in deinem Programm den SQLite Teil mal totlegst, bzw. den Solid State Relay Teil. Damit solltest du herausfinden können wo das Problem entsteht. Du baust im Prinzip eine alte schnelle Version des Programms Schritt für Schritt auf die aktuelle langsame Version um und testet nach jedem Schritt. Auf dem Weg solltest du das Problem finden.

Okay, dann kannst du dein Programm mit einem Profiler betrachten, um zu sehen wo das Programm seine Zeit verbringt: https://docs.python.org/3.7/library/profile.html Das erste wo nach ich im Code schauen würde, ist ob du Schleifen hast, die irgendetwas viel häufiger tun als sie müssten: Nach diesem Muster z.B.: while True: ptc_bricklet.get_temperature() Der Code fragt mit voller Geschwindigkeit die Temperatur ab, mehrere tausende male pro Sekunde. So schnell ändert sich die Temperatur aber nicht. Es würde auch vollständig reichen die Temperatur nur jede Sekunden anzufragen: while True: ptc_bricklet.get_temperature() time.sleep(1) Das spart enorm CPU Last.

So ins Blaue antworten ist schwer. Zeig doch mal dein Python Programm vor.

Zu 1: Der Chip Type sollte eigentlich immer von Verkäufer der LED Strips angegeben sein. Unsere LED Strips sind z.B. WS2812B. Beim Channel Mapping ist das etwas komplizierter, denn das ist im Zweifelsfall auch zwischen gleichen Chip Typen nicht identisch. So ein WS2812B hat 3 Kanäle an denen jeweils eine LED angeschlossen ist. Es muss nicht immer der erste Channel Rot sein. Das kann zwischen Herstellern unterschiedlich sein. Daher sagt die Doku "typischerweise". Da kommst du um ausprobieren nicht herum. Das einfachste ist RGB als Channel Mapping zu wählen, dann z.B. (255, 0, 0) auf die erste LED zu setzen. Wenn dann die LED blau leuchtet, dann weißt du, dass das richtige Channel Mapping auf der ersten Stelle Blau hat. So kannst mit 2-3 Teste das richtige Channel Mapping finden. Zu 2: Muss ich mir anschauen, hört sich aber komisch an, da ist potentiell was nicht richtig.

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