photron
Administrators
-
Benutzer seit
-
Letzter Besuch
Alle erstellten Inhalte von photron
-
Okay, du solltest libegl1-mesa und libegl1-mesa-dev ohne Probleme einfach deinstallieren können. Für die aktuelle Debian Version sagt die Beschreibung des libegl1-mesa Paketes: Dieses Übergangspaket kann gefahrlos entfernt werden. Nur hast du gerade apt in die Ecke gedrängt und es lässt dich jetzt wahrscheinlich libegl1-mesa nicht deinstallieren, weil du mit den Qt Paketen da so halb hängst. Hast du das auf einem frischen Image veruscht und kannst einfach von vorne anfangen, oder musst du das jetzt retten? Ansonsten ist es villeicht das einfachste du fängst mit eibnem frischen Image an und deinistallierst zu erst libegl1-mesa.
-
Da stehen sich die Pakete libegl1 und libegl1-mesa auf den Füssen. Beide beinhalten /usr/lib/arm-linux-gnueabihf/libEGL.so.1, dadurch müssen die beiden Pakete eigentlich also Conflicting/Replacing markiert sein, dass scheint aber nicht der Fall zu ein. Daher klappt es nicht das apt/dpkg das selbst auflösen. Qt hängt hier von libegl1 ab. Aus irgendeinem Grund ist aber bereits libegl1-mesa installiert. Versuch mal über "sudo apt remove libegl1-mesa" das paKet zu deinstallieren, damit dir apt anzeigt wer von libegl1-mesa abhängt und dann mit deinstalliert würde.
-
I think I found out the problem. According to my tests the problem should be fixed in Brick Viewer 2.4.21.
-
-
Das Problem ist jetzt auch endlich mit Brick Viewer 2.4.21 offiziell behoben.
-
Brick Viewer 2.4.21 Fix serial port listing on Apple M1 Macs Truncate RED Brick log file view to 10MB Improve hex input mode for RS232 Bricklet 2.0 Improve compatibility with Python 3.10 Fix OpenGL problems on macOS 12 Downloads: Windows, Linux, macOS
-
Brick Viewer 2.4.21 Auflistung serieller Schnittstellen auf Apple M1 Macs repariert Ansicht von BED Brick Logdateien auf 10MB beschränkt Hex-Eingabemodus für RS232 Bricklet 2.0 Kompatibilität mit Python 3.10 verbessert OpenGL Probleme auf macOS 12 repariert Downloads: Windows, Linux, macOS
-
Ich nehme an du meinst Brick Viewer. Brick Daemon spielt hier gar nicht mit. Danke, das hört man gerne.
-
Das funktioniert hier nicht, da du zwischen zwei Firmware-Typen wechselst. Du musst in diesem Fall einmal den ESP32 Ethernet Brick per USB an einen PC mit Brick Viewer 2.4.20 oder neuer abschließen. Es ist nicht nötig den Brick händisch in den Bootloader zu bringen, dass passiert hier automatisch. Dann über den Brick Viewer Updates / Flashing Dialog den ESP32 Ethernet Brick auswählen, als Firmware "Custom..." wählen und die angehängte Firmware Datei auswählen und flashen. Zukünftige Firmware Updates können dann wieder über das Webinterface erfolgen. Edit: Veraltete Firmware entfernt.
-
Das ist schon alles möglich, nur noch nicht alles vollständig im Endausbau fertig und dokumentiert. Ich nehme an du hast den "ESP32 Ethernet Brick mit WARP2 Firmware" aus der Gruppe der WARP2 Ersatzeile gekauft? Dort ist die Firmware für den WARP2 Charger vorinstalliert. Für eine Nuttzung des ESP32 Ethernet Bricks als Master Brick + WIFI Extension Ersatz ist es am einfachsten du kompilierst dir die ESP32 Ethernet Brick Firmware aus diesem Git: https://github.com/Tinkerforge/esp32-firmware Alternativ kann ich dir auf eine Vorabversion hier bereitstellen. Mit dem aktuellen Stand https://github.com/Tinkerforge/esp32-firmware/commit/1d8a78d26322f29859ac77748f3dba1f3697f227 kannst du dann über das Webinterface der ESP32 Ethernet Bricks WLAN und Ethernet konfigurieren (genauso wie bei der Wallbox) und über WLAN und Ethernet die angeschlossenen Bricklets erreichen. Der ESP32 Ethernet Brick selbst tauch noch nicht in Brick Viewer auf und hat auch noch keine API zu Konfigurartion. Das kommt auf Dauer aber noch.
-
Es ist sogar noch mehr kaputt. Bedingt durch andere Fehler ist dieser Fehler gestern nicht aufgefallen. Danke für's Aufpassen. Jetzt sollte es wirklich heile sein.
-
Anstelle von scss/*.scss kannst du in jedem Frontend Module jetzt pre.scss und post.scss ablegen und diese werden dann automatisch in der main.scss am Anfang bzw. am Ende der Datei importiert. Das sollte in den meisten Fällen erstmal reichen. https://github.com/Tinkerforge/esp32-firmware/commit/3b100bff1612bb81f148e8b0041e73bc5e0d1ab7
-
Firmware: WIFI Extension 2.0 2.1.6 Avoid crash when using mesh functions in non-mesh mode Download: WIFI Extension 2.0
-
Firmware: WIFI Extension 2.0 2.1.6 Crash behoben, wenn Mesh Funktionen aufgerufen werden ohne im Mesh Modus zu sein Download: WIFI Extension 2.0
-
-
Firmware: WIFI Extension 2.0 2.1.5 Workaround LED staying off in client mode after enabling the LED again Download: WIFI Extension 2.0
-
Firmware: WIFI Extension 2.0 2.1.5 Problem umgangen, dass die LED im Client Modus aus bleibt nachdem die LED wieder aktiviert wurde Download: WIFI Extension 2.0
-
Yes. There are two versions of the Ethernet Master Extension, with and without PoE (Power over Ethernet). The Ethernet Master Extension with PoE allows you to power the stack over the Ethernet cable using a PoE ready switch or a dedicated PoE injector. Resulting in a single cable connecting to the stack. For the Ethernet Master Extension without PoE, you have to power the stack separately for example with a USB power supply connected to the Master Brick. Resulting in two cables running to the stack.
-
The IMU Brick 2.0 cannot use an Ethernet Extension directly. You'd need to build a stack (bottom to top) of Master Brick, IMU Brick 2.0 and Ethernet Extension. Then you can connect to this stack over Ethernet.
-
Okay, so it can work. But we still don't know if it is because of the packaging or the different PyQt5 version. You could try building the Brick Viewer .dmg file. For that you need to run "build_pkg.py --no-sign" in the virtualenv. The --no-sign option tells it to not sign the binaries, as you cannot do that on our behalf. Afterwards try the resulting .dmg file that is created in the same directory as the build_pkg.py file. If Brick Viewer from that .dmg has the same OpenGL problem, then it is triggered by the packaging.
-
Brick Viewer is always optional. It is not necessary for using the different API bindings. The different API bindings use a TCP/IP network connection to talk to the Tinkerforge hardware. If the hardware is connected to USB then Brick Daemon is required for the TCP/IP to USB translation. You can replace the USB connection with a Ethernet or WIFI connection by adding a Ethernet or WIFI Master Extension to the stack. Then the API bindings can connect directly to the hardware over Ethernet or WIFI without the need for Brick Daemon. What does you current hardware setup look like?
-
Don't worry, the problem is just that MSVC2010 is quite old and has some quirks that you run into now. The C/C++ bindings don't handles those correctly right now. Please add these 3 lines in ip_connection.c at line 55: #if defined _MSC_VER && _MSC_VER < 1900 #define snprintf _snprintf #endif
-
The PyQt5_sip dependency problem might be related to this line in requirements.txt PyQt5 == 5.11.3 Try changing that to PyQt5 == 5.15.6 or just to PyQt5
-
No, the problem is with PyQt5_sip, but the version numbers confuse me.
-
Sorry, I didn't think this through. You're compiling the code as C++. The problem is including stdbool.h there. It should not be included at all for C++ because its a C header. Please remove the stdbool.h file again and change line 24 in ip_connection.h from this #if (!defined __cplusplus && defined __GNUC__) || (defined _MSC_VER && _MSC_VER >= 1600) to this #if !defined __cplusplus && (defined __GNUC__ || (defined _MSC_VER && _MSC_VER >= 1600)) then try again.
