Jump to content
photron

Betaversion Brick Viewer mit PyQt5 und Python 3

Recommended Posts

Wir haben die Grundlagen von Brick Viewer modernisiert. Brick Viewer Version 2.4.0 basiert jetzt auf PyQt5 und Python 3, statt auf PyQt4 und Python 2.

 

Die aktuelle Betaversion für Linux, Windows und macOS gibt es hier:

 

http://download.tinkerforge.com/tools/brickv_pyqt5/beta2/linux/brickv-2.4.0_all.deb

http://download.tinkerforge.com/tools/brickv_pyqt5/beta2/windows/brickv_windows_2_4_0.exe

http://download.tinkerforge.com/tools/brickv_pyqt5/beta2/macos/brickv_macos_2_4_0.dmg

 

Bitte testet die neue Version und meldet uns Probleme, wenn ihr welche findet.

 

Update (26.02.2019):

 

Beta2 ist jetzt verfügbar mit folgenden Änderungen:

 

  • Dialoge wurden fälschlicherweise als Toplevel-Fenster angezeigt, dies ist korrigiert.
  • Checkbox hinzugefügt um den Fusion GUI Style zu (de-)aktivieren. Auf macOS ist dieser standardmäßig aktive um scrollbare Tableisten und ein insgesamt kompakteres GUI Layout zu erhalten.
  • RED Brick Server Room Monitoring: PTC Bricklet Wire Mode Einstellung und Nagios E-Mail Konfiguration werden korrekt ausgelesen.

Share this post


Link to post
Share on other sites

Hallo photron,

 

ein Problem, dass schon der bisherige Brick Viewer hatte, ist der einreihige Tabreiter. Bei vielen Bricklets kann man nichts mehr erkennen (siehe Anhang).

 

Die NFC/RFID Bricklet View fängt das "flackern" an sobald ich mein Typ 2 Tag auflege und Scan drücke. Die Load steigt auf 100% CPU.

 

Sonst sieht es gut aus.

 

Gruß,

Theo

BrickvTabs.thumb.png.348842b119e75ecc13e59f78f54d7da7.png

Share this post


Link to post
Share on other sites

theo, das Problem mit der Tableiste ist das Qt da den macOS Style nachbildet und da keine scrollen einer Tableiste vorgesehen ist. Solange wir da eine Tableiste haben wird das unter macOS leider so sein. Du kannst mal brickv mit einem anderen Style starten, der eine scrollbare Tableiste hat. Das geht über einen Terminal:

 

/Applications/Brickv.app/Contents/MacOS/brickv -style fusion

 

Wenn du die Brickv.app nicht im Applications Folder hast dann muss du den Pfad entsprechend anpassen.

 

Das NFC/RFID Problem schauen wir uns an.

 

Loetkolben, das ist einfach eine neue Version des brickv Package, das ersetzt dein bisher installiertes brickv Package. Das ist kein anderer brickv, sondern einfach die nächste Version 2.4.0. Brick Viewer auf Basis von PyQt4 und Python 2 wird nicht weiterentwickelt.

Share this post


Link to post
Share on other sites

Das mit dem Fusion Style ist schon mal viel besser, das sollte der Default sein. Optimal wären gestaffelte Tabs.

Share this post


Link to post
Share on other sites

Och.  ;D

 

Sieht Chick aus. Das Update hat auch problemlos unter Debian 9.8 funktioniert.

 

Zuerst das Paket von Hand mit "dpkg -i" installiert.

Dann wird gemeckert, dass einige Abhaengigkeiten fehlen. Ein "apt --fix-broken install" behebt das Problem zuverlaessig. Ein anschliessendes "apt-get --purge autoremove" entfernt evtl. nicht mehr benoetigte Pakete der alten Version.

 

Aufrufen und es sieht wirklich gut aus.  :D  Tolle Arbeit!

 

Funktionen nicht im Detail getestet, aber aus meiner Sicht fehlt da nichts.

 

Nachtrag: Die Verschachtelte Darstellung (auch schon in der alten Version) der Masterbricks mag ja der internen Logik des Stacks folgen, aber mich irrtiert das jedesmal wenn ich am Stack ein Brick suche. Die Anzeige am Bildschirm sollte dem physischen Aufbau des Stacks folgen.  ;)

 

 

Der Loetkolben

Share this post


Link to post
Share on other sites

Das Update der Firmware hat jetzt funktioniert, aber das Air Quality Bricklet wird noch immer an Position "Z" angezeigt.

 

Der Bug dort liegt im Bootloader des Air Quality Bricklets, da kann der Brick Viewer leider nichts gegen machen.

Share this post


Link to post
Share on other sites

Hallo,

 

Das Update der Firmware hat jetzt funktioniert, aber das Air Quality Bricklet wird noch immer an Position "Z" angezeigt.

Der Bug dort liegt im Bootloader des Air Quality Bricklets, da kann der Brick Viewer leider nichts gegen machen.

Auch in der Firmware 2.0.3?

Nach ein paar Connects/Disconnects habe ich festgestellt, dass es manchmal auch korrekt angezeigt wird. Meistens aber an Position "Z".

Share this post


Link to post
Share on other sites

Nach ein paar Connects/Disconnects habe ich festgestellt, dass es manchmal auch korrekt angezeigt wird. Meistens aber an Position "Z".

Ja, da ist ein Stück uninitalisierter Speicher im Bootloader. Wenn dort an einer bestimmten Stelle zufällig 90 drin steht ('Z'), dann wird das beim Enumerate mit zum Master übertragen. Normalerweise setzt der Master Brick den Port in der Nachricht (Das Bricklet weiß gar nicht an welchem Port es angeschlossen ist). Aber bei 'Z' geht er davon aus dass das Air Quality Bricklet an einem Isolator Bricklet angeschlossen ist, da der Port des Isolator Bricklet ist immer 'Z' ist.

 

Hier ist der Fix im Bootloader dafür: https://github.com/Tinkerforge/brickletboot_xmc/commit/bedbb6a29dbd9d4189506aaa4e45238d37a11285

 

Und hier ist der Code im Master Brick der das Problem verursacht: https://github.com/Tinkerforge/bricklib/blob/master/bricklet/bricklet_co_mcu.c#L244

 

Der Bootloader wird allerdings nicht aktualisiert wenn du die Firmware aktualisierst. Der wird nur einmal von uns ganz am Anfang geschrieben.

 

Da die Bootphase deterministisch ist, passiert das beim Air Quality Bricklet zumindest am Anfang jedes mal, auch wenn die Chance dass das überhaupt passieren kann eigentlich nur 1 zu 256 ist :o.

 

Edit: Ha! Jetzt wo ich mir das nochmal in Ruhe angeschaut hab ist die Lösung eigentlich ganz einfach. Die "connected uid" wird von den Bricklets immer als "\0" initialisiert, von einem Isolator Bricklet aber entsprechend auf die UID des Isolator Bricklets gesetzt. D.h. der Check muss einfach

if(gir->position != 'Z' || gir->connected_uid[0] == '\0')

sein. Dann ist das Stück uninitialisierter Speicher wieder kein Problem mehr :). Muss ich mir morgen nochmal genau ansehen, aber ich denke das ist die Lösung.

Share this post


Link to post
Share on other sites

Hi Theo,

Hast du noch ein anderes Programm parallel laufen, dass mit dem NFC-RFID-Bricklet kommuniziert? Im Log kommen über das state-changed-Callback Antworten auf Anfragen, die der Brick Viewer nicht abgesetzt haben kann. Das Flackern wird dann dadurch ausgelöst, dass das Bricklet in kurzer Zeit (~10ms) zwei Mal nach der Tag-ID sucht und erst die richtige ID findet und danach einen Fehler zurückgibt.

 

Hattest du das Problem schon mit dem alten Brick Viewer?

Share this post


Link to post
Share on other sites

Hi Erik,

 

Ok, das war es. Ich hatte auch schon sowas vermutet und auf meinem Rechner nach laufenden Programmen (openHAB) gesucht und da lief nichts. Jetzt hab ich mit lsof noch nach offenen Verbindungen zum brickd gesucht und gefunden. Da war noch eine openHAB Testinstallation auf einem Pi, die remote am brickd hing :-((

Jetzt funktioniert alles wie es soll.

 

Sorry für die Umstände.

 

Gruß,

Theo

 

Share this post


Link to post
Share on other sites

Das Starten auf meinem vServer dauert ein wenig. Ca. 15 Sekunden. Mal abgesehen von kraftvollen Desktop PC wird es wohl auch auf Raspberrys recht lang dauern.

 

Damit man das Programm nicht aus versehen in der Zeit ein zweites mal startet waere ein sofort erscheinendes Splash Logo evtl. gut?!

 

Es muss ja nicht gross sein und darf auch per default fehlen. Die Frage ist nur, wie schnell koennte es erscheinen, wenn eben der Rechner recht langsam ist.

 

 

Der Loetkolben

Share this post


Link to post
Share on other sites

Loetkolben, ist das jetzt neu mit Brick Viewer 2.4.0 oder war das schon immer so?

 

Ich würde da eher die Ladezeit verbessern wollen anstatt das mit einem Splash Screen zu kaschieren.

 

Ich vermute das steckt im Laden der Plugins. Test mal bitte wie es die Startzeit beeinflusst, wenn du das Laden der Plugins deaktivierst. Dazu in dieser Datei:

 

/usr/share/brickv/plugin_system/plugin_manager.py

 

Zeile 27 von:

 

from brickv.plugin_system.plugins import device_classes

 

auf

 

device_classes = []

 

ändern.

 

Share this post


Link to post
Share on other sites

Hallo photron,

 

das liegt nicht wirklich an euch.  :D

Das war bisher auch schon so, aber es war nicht wichtig extra einen Thread dafuer aufzumachen, aber da ihr gerade am Brickviewer am arbeiten seit, dachte ich, dass ich das mal einwerfen koennte.

 

Es liegt am virtuellem System (vServer). Alle Zeiten von Hand zwei mal gestoppt. Das laden der plugins benoetigt also rund 1/3 Zeit mehr. Da nur das laden vom IO System (Wer weiss was die dahinter haben) so lange dauert, ist das eigentlich keine Baustelle von euch das zu optimieren.

 

Wenn aber mehrere User und/oder ihr der Meinung seit, da muesste man was aendern, dann faende ich das prima. Wegen mir alleine muss das nicht sein.  ;)

 

Meine Ergebnisse: vServer, Debian 9, 2 GB Ram

 

# Mit "from brickv.plugin_system.plugins import device_classes"
echo 1 > /proc/sys/vm/drop_caches # Memory Cache leeren
brickv
=> 21 Sekunden
# Beenden und dann neu starten (Kommt wohl aus dem Memory Cache)
brickv
=> 2 Sekunden

 

 

# Mit "device_classes = []"
echo 1 > /proc/sys/vm/drop_caches # Memory Cache leeren
brickv
=> 13 Sekunden
# Beenden und dann neu starten (Kommt wohl aus dem Memory Cache)
brickv
=> 1,5 Sekunden

 

 

Der Loetkolben

Share this post


Link to post
Share on other sites

Hallo photron,

 

habe die Spezialversion installiert, einen Vorteil hat sie nicht gebracht.

 

Dreimal mit leeren Cache (echo 1 > drop_caches) gestartet:

19, 19, 27 Sekunden Startzeit. Woher die 27 Sekunden kommen weiss ich nicht.

 

Danach aus dem Cache gestartet: 1,5 Sekunden. Zeitmessung erfolgte durch Blick auf die Uhr.

 

Auch die mitgelieferten *.pyc Dateien haben keinen Vorteil gebracht, da ich davon ausgehe, dass weder die Rechenleistung (python precompile) noch das RAM (Start from Cache) das Problem darstellen. Das IO Subsystem kenne ich bei dem vServer nicht, wird aber hoechstwahrscheinlich ein HDD Raid mit gemeinsamen Zugriff sein.

 

Habt ihr den Brickviewer mal von einem NAS mit HDD oder einer lokalen HDD (jeweils mit leerem Memory Cache) gestartet, also ohne SSD? Bei den heutigen SSD als C: bzw. root Laufwerk ist IO Latenz ja kaum noch vorhanden.

 


 

BTW, meine Meinung/Erfahrung: Ich habe zwei gleiche Rechner (Dell Dualcore ca. 5 Jahre alt) einmal mit einer einfachen SSD und einmal mit einer HDD am laufen. Das starten von Windows ist alles noch halbwegs vergleichbar, aber bei Updates mit vielen kleinen Dateien (VLC, Sicherungspunkt setzen, Datentraegerbereinigung) hat man gerne die 4 bis 10 fache Zeit. Seit dem aufkommen der SSDs hat niemand mehr beim File IO etwas optimiert. :(

Fuer Heim PC und Laptops mit SSD ist das Problem gegessen, fuer Rechenzentrumsrechner die per SAN/NAS/iSCSI und/oder als Raid angebunden sind ist das Bumerang, bzw. wird durch caching minimiert. :o

Noch ein Beispiel vom vServer: Softmaker Textmaker: 10 zu 1 Sekunde.

 

 

Der Loetkolben

Share this post


Link to post
Share on other sites

Hallo photron,

bin knapp in der Zeit. Tut nicht, da Import fehlt schlaegt. Siehe unten.

Fehler bei mir?

 

# dpkg -i brickv-2.4.0_all_loetkolben_2.deb
(Lese Datenbank ... 92974 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von brickv-2.4.0_all_loetkolben_2.deb ...
Entpacken von brickv (2.4.0) über (2.4.0) ...
brickv (2.4.0) wird eingerichtet ...
Trigger für gnome-menus (3.13.3-9) werden verarbeitet ...
Trigger für desktop-file-utils (0.23-1) werden verarbeitet ...
Trigger für mime-support (3.60) werden verarbeitet ...

## Alles ok, keine Fehler.

 

 

# brickv
Traceback (most recent call last):
  File "/usr/share/brickv/main.py", line 75, in <module>
    from PyQt5 import QtWebEngineWidgets
ImportError: cannot import name 'QtWebEngineWidgets'

## Tut nicht. Google "hochfahren"

 

# apt-get install python-pyqt5
[...]
The following additional packages will be installed:
  python-sip
Vorgeschlagene Pakete:
  python-pyqt5-dbg
Die folgenden NEUEN Pakete werden installiert:
  python-pyqt5 python-sip
[...}
python-sip (4.18.1+dfsg-2) wird eingerichtet ...
python-pyqt5 (5.7+dfsg-5) wird eingerichtet ...

## Passendes? Paket installiert?

 

# brickv
Traceback (most recent call last):
  File "/usr/share/brickv/main.py", line 75, in <module>
    from PyQt5 import QtWebEngineWidgets
ImportError: cannot import name 'QtWebEngineWidgets'

## Tut trotzdem nicht.

 

 

BTW: Bin heute in Nuernberg unterwegs. Evtl. dauern meine Rueckmeldungen.

 

 

Der Loetkolben

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...