photron

Die ersten 10 Byte sind kein vollständiges Paket, das ist erwartet, da ich einfach die letzten 1000 Bytes ausgeben, ohne auf Paketgrenzen zu achten. Wenn ich die ersten 10 Byte weglasse, dann dekodieren die restlichen Daten sauber zu 44 Callbacks, jeweils abwechselnd der Accelerometer Bricklet 2.0 Acceleration Callback und der Air Quality Bricklet All Values Callback. Die ersten weggelassenen 10 Byte sehen aus wie die letzten 10 Bytes eines der All Values Callbacks. Sprich, ich sehen aus den Daten nicht warum der Fehler auftritt. Wenn ich die ersten 11 Byte weglasse, dann tritt der Fehler im dritten Paket auf. Das ergibt aber wenig Sinn, denn damit das wirklich so aufgetreten sein könnte, müssen die restlichen Daten, die 42 Pakete ergeben, bei der IP Connection in einem Socket Receive Aufruf angekommen sein. Das ist nicht unmöglich, aber doch sehr unwahrscheinlich. Ich kann aus den Daten leider so nicht sehen was da wirklich los ist, sorry. Hier eine IP Connection die beim Auftreten des Problems alles ausgibt was an Daten da ist. Damit bitte nochmal das Problem erzeugen. Die Ausgabe ist deutlich umfangreicher und sieht in etwa so aus: --------- BEGIN --------- timestamp: 106665.961430398 exception: Traceback (most recent call last): File "/home/matthias/tf/dev/brickv/src/brickv/bindings/ip_connection.py", line 992, in receive_loop raise Exception('a') Exception: a data_counter: 19 data_history: [ (0, 106663.574052653, 68, b' %\xf6\xc8"\xfd\x08\x0068WcDS\x00\x000\x00\x00\x00\x00\x00\x00\x000\x02\x01\x00\x02\x04\x04\r\x00\x00\x90>J\xbd"\xfd\x08\x005QCAEd\x00\x0068WcDS\x00\x00a\x01\x01\x00\x02\x00\x02\x1b\x00\x00'), (1, 106663.574205742, 68, b'\xd6z\x00\x00"\xfd\x08\x00amb\x00\x00\x00\x00\x0068WcDS\x00\x00b\x01\x01\x00\x02\x00\x03\x15\x00\x00\xe2\x90\x01\x00"\xfd\x08\x00wvq\x00\x00\x00\x00\x0068WcDS\x00\x00c\x01\x00\x00\x02\x00\x02\xdd\x00\x00'), (2, 106663.574246151, 34, b'i\xe1&""\xfd\x08\x00SCD32\x00\x00\x0068WcDS\x00\x00d\x01\x02\x00\x02\x00\x06\xd4\x00\x00'), (3, 106663.579172704, 9, b' %\xf6\xc8\t\x058\x00\x00'), (4, 106663.580263621, 9, b' %\xf6\xc8\t\x12H\x00\x00'), (5, 106663.580755935, 9, b' %\xf6\xc8\t\x1aX\x00\x00'), (6, 106663.581016582, 9, b' %\xf6\xc8\tAh\x00\x00'), (7, 106663.581347659, 9, b' %\xf6\xc8\tNx\x00\x00'), (8, 106663.581620615, 9, b' %\xf6\xc8\tM\x88\x00\x01'), (9, 106663.604665966, 16, b'i\xe1&"\x10\x0c\x98\x00\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa'), (10, 106665.059943865, 10, b'\x90>J\xbd\n\x01\xa8\x00e\x01'), (11, 106665.160133984, 10, b'\x90>J\xbd\n\x01\xb8\x00d\x01'), (12, 106665.260356932, 10, b'\x90>J\xbd\n\x01\xc8\x00d\x01'), (13, 106665.360479232, 10, b'\x90>J\xbd\n\x01\xd8\x00e\x01'), (14, 106665.460632221, 10, b'\x90>J\xbd\n\x01\xe8\x00e\x01'), (15, 106665.56087381, 10, b'\x90>J\xbd\n\x01\xf8\x00e\x01'), (16, 106665.661021859, 10, b'\x90>J\xbd\n\x01\x18\x00d\x01'), (17, 106665.76111894, 10, b'\x90>J\xbd\n\x01(\x00e\x01'), (18, 106665.861319748, 10, b'\x90>J\xbd\n\x018\x00e\x01'), (19, 106665.961430398, 10, b'\x90>J\xbd\n\x01H\x00e\x01'), ] packet_history: [ (0, 0, 106663.574052653, 34, 34, b' %\xf6\xc8"\xfd\x08\x0068WcDS\x00\x000\x00\x00\x00\x00\x00\x00\x000\x02\x01\x00\x02\x04\x04\r\x00\x00', b'\x90>J\xbd"\xfd\x08\x005QCAEd\x00\x0068WcDS\x00\x00a\x01\x01\x00\x02\x00\x02\x1b\x00\x00'), (0, 1, 106663.574052653, 34, 34, b'\x90>J\xbd"\xfd\x08\x005QCAEd\x00\x0068WcDS\x00\x00a\x01\x01\x00\x02\x00\x02\x1b\x00\x00', b''), (1, 2, 106663.574205742, 34, 34, b'\xd6z\x00\x00"\xfd\x08\x00amb\x00\x00\x00\x00\x0068WcDS\x00\x00b\x01\x01\x00\x02\x00\x03\x15\x00\x00', b'\xe2\x90\x01\x00"\xfd\x08\x00wvq\x00\x00\x00\x00\x0068WcDS\x00\x00c\x01\x00\x00\x02\x00\x02\xdd\x00\x00'), (1, 3, 106663.574205742, 34, 34, b'\xe2\x90\x01\x00"\xfd\x08\x00wvq\x00\x00\x00\x00\x0068WcDS\x00\x00c\x01\x00\x00\x02\x00\x02\xdd\x00\x00', b''), (2, 4, 106663.574246151, 34, 34, b'i\xe1&""\xfd\x08\x00SCD32\x00\x00\x0068WcDS\x00\x00d\x01\x02\x00\x02\x00\x06\xd4\x00\x00', b''), (3, 5, 106663.579172704, 9, 9, b' %\xf6\xc8\t\x058\x00\x00', b''), (4, 6, 106663.580263621, 9, 9, b' %\xf6\xc8\t\x12H\x00\x00', b''), (5, 7, 106663.580755935, 9, 9, b' %\xf6\xc8\t\x1aX\x00\x00', b''), (6, 8, 106663.581016582, 9, 9, b' %\xf6\xc8\tAh\x00\x00', b''), (7, 9, 106663.581347659, 9, 9, b' %\xf6\xc8\tNx\x00\x00', b''), (8, 10, 106663.581620615, 9, 9, b' %\xf6\xc8\tM\x88\x00\x01', b''), (9, 11, 106663.604665966, 16, 16, b'i\xe1&"\x10\x0c\x98\x00\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa', b''), (10, 12, 106665.059943865, 10, 10, b'\x90>J\xbd\n\x01\xa8\x00e\x01', b''), (11, 13, 106665.160133984, 10, 10, b'\x90>J\xbd\n\x01\xb8\x00d\x01', b''), (12, 14, 106665.260356932, 10, 10, b'\x90>J\xbd\n\x01\xc8\x00d\x01', b''), (13, 15, 106665.360479232, 10, 10, b'\x90>J\xbd\n\x01\xd8\x00e\x01', b''), (14, 16, 106665.460632221, 10, 10, b'\x90>J\xbd\n\x01\xe8\x00e\x01', b''), (15, 17, 106665.56087381, 10, 10, b'\x90>J\xbd\n\x01\xf8\x00e\x01', b''), (16, 18, 106665.661021859, 10, 10, b'\x90>J\xbd\n\x01\x18\x00d\x01', b''), (17, 19, 106665.76111894, 10, 10, b'\x90>J\xbd\n\x01(\x00e\x01', b''), (18, 20, 106665.861319748, 10, 10, b'\x90>J\xbd\n\x018\x00e\x01', b''), ] packet_counter: 21 packet: 10 10 b'\x90>J\xbd\n\x01H\x00e\x01' pending_data: 0 b'' ---------- END ---------- ip_connection.py

Python API bindings version 2.1.24 is now available.

Bindings: C/C++ 2.1.27, C# 2.1.25, Delphi/Lazarus 2.1.26, Go 2.0.5, Java 2.1.25, JavaScript 2.1.25, LabVIEW 2.1.24, Mathematica 2.1.24, MATLAB/Octave 2.0.25, MQTT 2.0.8, Perl 2.1.25, PHP 2.1.24, Python 2.1.24, Ruby 2.1.24, Rust 2.0.13, Shell 2.1.24, Visual Basic .NET 2.1.24 Add set/get-voltages-callback_configuration functions and voltages callback to HAT Brick API [all] Add set/get-usb-voltage-callback-configuration functions and usb-voltage callback to HAT Zero Brick API [all] Add set/get-statistics-callback-configuration functions and statistics callback to Isolator Bricklet API [all] Report error if authentication secret contains non-ASCII chars [all] Don't silently ignore stream-out-of-sync errors in callbacks [Go] Replace BrickletError with DeviceError [Go] Don't use deprecated Buffer constructor if possible [JavaScript] Log Brick Daemon (dis)connects under --debug [MQTT] Use stable order for init-file lines [MQTT] Fix symbol translation of IP Connection callbacks [MQTT] Report all errors when reading init-file [MQTT] Add pre/post_connect init-file format [MQTT] Add get_connection_state to IP Connection [MQTT] Add last will (sent if the API bindings crash) and shutdown messages [MQTT] Correctly reset registered callbacks [MQTT] Handle SIGTERM/SIGQUIT [MQTT] Fix handling of character arrays [MQTT] Fix names of high-level-callback members [MQTT] Fix some error format strings in IPConnection class [Python] Fix Python 3 compatibility [Shell] Download: C/C++, C#, Delphi/Lazarus, Go, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, MQTT, Perl, PHP, Python, Ruby, Rust, Shell, Visual Basic .NET

Sobald du einmal über Brick Viewer die WLAN Verbindung konfiguriert hast sollte sich RED Brick danach von selbst wieder mit dem WLAN verbinden, ohne das du etwas dafür tun musst. Aus deiner Beschreibung geht nicht hervor, ob das der Fall ist. Musst du nach jedem Boot des RED Bricks wieder über den Network Tab im Brick Viewer die Verbindung händisch herstellen, oder funktioniert das doch automatisch?

Bindings: C/C++ 2.1.27, C# 2.1.25, Delphi/Lazarus 2.1.26, Go 2.0.5, Java 2.1.25, JavaScript 2.1.25, LabVIEW 2.1.24, Mathematica 2.1.24, MATLAB/Octave 2.0.25, MQTT 2.0.8, Perl 2.1.25, PHP 2.1.24, Python 2.1.24, Ruby 2.1.24, Rust 2.0.13, Shell 2.1.24, Visual Basic .NET 2.1.24 set/get-voltages-callback_configuration Funktions und voltages Callback zu HAT Brick API hinzugefügt [alle] set/get-usb-voltage-callback-configuration Funktions und usb-voltage Callback zu HAT Zero Brick API hinzugefügt [alle] set/get-statistics-callback-configuration Funktions und statistics Callback zu Isolator Bricklet API hinzugefügt [alle] Authentication Secret darf nur ASCII Zeichen enthalten [alle] Stream-Out-Of-Sync Fehler werden in Callbacks nicht mehr still ignoriert [Go] BrickletError durch DeviceError ersetzt [Go] Wenn möglich wird kein veralteter Buffer Konstruktor verwendet [JavaScript] Brick Daemon Verbindungen werden ins Log geschrieben, wenn --debug aktiviert ist [MQTT] Init-File Zeilen werden in stabiler Reihenfolge eingelesen [MQTT] Symbol-Abbildung für IP Connection Callbacks korrigiert [MQTT] Alle Fehler beim Lesen des Init-Files werden auch gemeldet [MQTT] pre/post_connect Einträge zum Init-File-Format hinzugefügt [MQTT] get_connection_state zur IP Connection hinzugefügt [MQTT] Last-Will (wird gesendet falls die API Bindings abstürzen) und Shutdown Nachrichten hinzugefügt [MQTT] Registrierte Callbacks werden korrekt zurückgesetzt [MQTT] SIGTERM/SIGQUIT Signals werden behandelt [MQTT] Behandlung von Character Arrays korrigiert [MQTT] Namen von High-Level-Callback Feldern korrigiert [MQTT] Einige Error-Format-Strings in der IPConnection Klasse korrigiert [Python] Python 3 Kompatibilität repariert [Shell] Download: C/C++, C#, Delphi/Lazarus, Go, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, MQTT, Perl, PHP, Python, Ruby, Rust, Shell, Visual Basic .NET

Did you start you test with the IMU Brick in green calibration state, see: https://www.tinkerforge.com/en/doc/Hardware/Bricks/IMU_V2_Brick.html#calibration Do you have anything near to the IMU Brick that produces a (changing) magnetic field? For example, try to stay away from monitors even modern TFT ones. Try moving the IMU Brick near to a running monitor without rotating it and see that the orientation will rotate due to the magnetic fields of the monitor.

Hast du am Monitor beide HDMI Eingänge getestet? Hast du versucht die Bildquelle am Monitor händisch auszuwählen? Hast du irgend einen anderen Monitor mit dem du testen könntest?

Sorry, I didn't manage to finish the release today. It'll be released on Monday.

Der Fehler kommt von einem kaputten Paket. Die IP Connection versucht da ein Paket zu dekodieren, das einen falschen Wert im Längenfeld stehen hat. Das sollte eigentlich nicht passieren können. Ich habe dir eine modifizierte IP Connection angehängt. Diese speichert die letzten 1000 byte empfangene Daten zwischen und gibt diese auf die Standardausgabe aus, wenn der Fehler auftritt. Nutze bitte diese IP Connection in deinem Programm, erzeuge das Problem nochmal und poste die Ausgabe hier. Das wird dann etwa so aussehen, nur länger: EXCEPTION 1574431120.7630146 b'1p\xb6\xc0"\xfd\x08\x005VGUhR\x00\x000\x00\x00\x00\x00\x00\x00\x000\x02\x01\x00\x02\x04\n\r\x00\x00' Daraus sollte ich dann genauer ableiten könne was das Problem erzeugt. ip_connection.py

Was ist das denn für ein Monitor (Marke und Modell)? Stell bitte sicher das der Monitor eingeschaltet ist bevor du dem RED Brick Strom gibst. Einen Monitor an einen laufenden RED Brick anzuschließen kappt nicht immer. Verwendest du unser HMDI Kabel für den RED Brick? Leuchten die LEDs am RED Brick? Nach dem du Strom angeschlossen hast sollte sollte die blaue dauerhaft leuchten. Die rote sollte kurz aufleuchten und dann wieder ausgehen. Die grüne sollte kurz darauf angehen und etwas später anfangen zu blinken. Wenn dies nicht der Fall ist, dann bootet der RED Brick nicht richtig.

Was für Bricks und Bricklets verwendest du?

Firmware: LED Strip Bricklet 2.0 2.0.3 Fix set-led-values length check to allow setting the last (6143th) LED as well Fix streaming logic of get-led-values for length above 60 LEDs Download: LED Strip 2.0

Firmware: LED Strip Bricklet 2.0 2.0.3 set-led-values Längenprüfung korrigiert, um das Setzen der letzen (6143te) Einzel-LED zu erlauben Streaming-Logik in get-led-values für Längen über 60 Einzel-LEDs repariert Download: LED Strip 2.0

Nach 5 Minuten google würde ich da so heran gehen: Es gibt Open Source CANopen Stacks, zum Beispiel https://github.com/CANopenNode CANOpenNode hat ein Driver Model für die CAN Hardwareeinheiten verschiedener Mikrocontroller und kann mit CANopenSocket auch auf Linux laufen. Dem würde ich versuchen, das CAN Bricklet als CAN Hardwareeinheiten hinzuzufügen.

Über die Planung ist es bisher nicht hinausgekommen. Vielleicht können andere von ihren Erfahrungen berichten. Frage am Rande: Willst du ein existierendes CANopen Gerät abfragen/steuern, oder selbst ein neues CANopen Gerät bauen?

The set_voltages_callback_configuration function is new and not part of Python API bindings version 2.1.23. It will be part of version 2.1.24 that will be released this week.

Es gibt zwei Varianten von Base58: https://en.wikipedia.org/wiki/Base58 Wir verwenden die Flickr Variante, die meisten Online Tools scheinen aber die Bitcoin Variante zu verwenden. 6DbKt8 dekodiert zu 0x31 0x10 0xb1 0xdc Ich kann auf Anhieb kein Online Tool finden, dass die Flickr Variante nutzt. Ich habe gerade ein kleines Python Script zusammenkopiert, dass die Flickr Variante dekodiert: $ python3 base58decode.py 6DbKt8 base58: 6DbKt8 decimal: 3702591537 hexadecimal: 0xdcb11031 bytes (little endian): 0x31 0x10 0xb1 0xdc $ python3 base58decode.py b1Q base58: b1Q decimal: 33688 hexadecimal: 0x8398 bytes (little endian): 0x98 0x83 0x0 0x0 base58decode.py

Nach meinem Wissen ist das eine reine Geschmacksfrage.

Problem wurde per Email geklärt. Bricklets waren vollständig ungeflasht und wurden durch neue geflashte Bricklets ausgetauscht.

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.