1. Übersicht

Die Absicht von QtVCP ist es, eine Infrastruktur zur Unterstützung von Bildschirmen und VCP-Panels für LinuxCNC bereitzustellen.

Durch die Bereitstellung eines vielfältigen Widgetsatzes und die Unterstützung von custom coding hofft QtVCP, dass die Entwicklungsenergie in einem Toolkit verbraucht wird und nicht in ständiger Neuerfindung.

Durch die Verwendung desselben Toolkits für viele Bildschirme/Panels sollte es für die Benutzer einfacher sein, diese anzupassen/zu erstellen, und für die Entwickler sollte es einfacher sein, bei der Fehlersuche mit weniger Aufwand zu helfen.

QtVCP verwendet eine von Qt Designer erstellte .ui-Datei und eine Python-Handler-Datei

  • zum Laden und Steuern eines Bildschirms/Panels, das Qt-Widgets anzeigt und

  • zur Steuerung von LinuxCNC’s Motion Controller oder HAL Pins.

Es gibt vorgefertigte Bildschirme und Paneele, die leicht von einem Benutzer geladen werden können, oder Benutzer können ihre eigenen erstellen/ändern.

QtVCP verwendet Bibliotheken und benutzerdefinierte Widgets, um einen Teil der Komplexität der Schnittstelle zu LinuxCNC zu verbergen. Durch die Verwendung der QtVCP-Bibliothek anstelle der LinuxCNC-Bibliothek können wir kleinere Änderungen am LinuxCNC-Code abmildern.

2. Integrierte Suchpfade

Integrierte Bildschirme und Bedienfelder werden in separaten Ordnern gespeichert:

  • Bildschirme in share/qtvcp/screens

  • Panels in share/qtvcp/panels

  • Stock Bilder in `share/qtvcp/images `

Bildschirme und Bedienfelder werden nach ihrem Ordnernamen sortiert, der auch der Name ist, der zum Laden verwendet wird.

Im Ordner wäre:

  • die .ui Datei,

  • die Handler-Datei, und

  • möglicherweise die .qss Themen-Datei.

3. QtVCP vom Startup bis zum Herunterfahren

QtVCP source befindet sich im Ordner src/emc/usr_intf/qtvcp des LinuxCNC-Quellcode Verzeichnisbaums.

3.1. QtVCP Startup

Beim ersten Start von QtVCP:

  1. Es muss entscheiden, ob dieses Objekt ein Bildschirm oder ein Bedienelement (engl. panel) ist.

  2. Es sucht und sammelt Informationen über Pfade von benötigten Dateien und nützlichen Ordnern.

  3. Dann wird es:

    1. Erstellt die HAL-Komponente,

    2. Die Fenster-Instanz laden,

    3. Fügt Handler-Erweiterungen hinzu,

    4. einen Ereignisfilter installieren.

Jetzt werden die Fenster/Widgets instanziiert, die HAL-Pins werden aufgebaut. Dies initiiert auch die +_init_hal()+ Funktion der Widgets. . Die Handler-Funktion +initialized__()+ wird aufgerufen . Die STATUS-Bibliothek wird zur Aktualisierung gezwungen. . HAL Komponente ist zu diesem Zeitpunkt bereit. . Es werden eine Reihe von optionalen Schalterargumenten gesetzt, einschließlich des Aufrufs einer POSTGUI-HAL-Datei (falls es ein Bildschirm ist). . Terminate-Signale werden abgefangen und QtVCP fragt jetzt nach Ereignissen.

3.2. QtVCP Herunterfahren (engl. shutdown)

Wenn QtVCP schließlich zum Herunterfahren aufgefordert wird:

  1. Sie ruft die Abschaltfunktionen in der Handler-Datei auf,

  2. Die ‚STATUS‘-Überwachung wird abgeschaltet

  3. HAL-Komponenten wird terminiert (engl. killed)

4. Pfad-Informationen

Wenn QtVCP geladen wird, sammelt es Pfadinformationen.

Dieser ist in der Funktion +__init__()+ der Handler-Datei als path (engl. für Pfad) verfügbar:

IMAGEDIR

Pfad zu mitgelieferten Bildern

SCREENDIR

Pfad der integrierten Motion-Controller-Bildschirme

PANELDIR

Pfad der eingebauten Zubehörtafeln

WORKINGDIR

Pfad, von dem aus QtVCP gestartet wurde

CONFIGPATH

Pfad der gestarteten Konfiguration

BASEDIR

Allgemeiner Pfad, der zur Ableitung aller Pfade verwendet wird

BASENAME

Generischer Name, der zur Ableitung aller Pfade verwendet wird

LIBDIR

Pfad der Python-Bibliothek von QtVCP

HANDLER

Pfad der Handler-Datei

XML

Pfad der .ui-Datei

DOMAIN

Pfad der Übersetzung

IS_SCREEN

Bildschirm-/Bedienfeldschalter

5. Eigenheiten

Diese versuchen, nicht offensichtliche Situationen abzudecken.

5.1. Sammlung von Fehlern

Die Fehlercodeerfassung von LinuxCNC kann nur von einem Ort aus gelesen werden.

Wenn es gelesen wird, ist es konsumiert, d.h. kein anderes Objekt kann es lesen.

In QtVCP-Bildschirmen wird empfohlen, das _Widget ScreenOptions zu verwenden, um das Lesen von Fehlern einzurichten.

Fehler werden dann über STATUS Signale an andere Objekte gesendet.

5.2. Jogging-Rate

LinuxCNC hat keine interne Aufzeichnung der Jogging-Geschwindigkeit: Sie müssen sie bei Beginn des Joggens festlegen.

QtVCP verwendet die STATUS-Bibliothek, um die neuesten linearen und winkligen Jog-Raten zu verfolgen.

Sie wird immer in Maschineneinheiten pro Minute angegeben und muss umgerechnet werden, wenn Sie sich im Modus für Nicht-Maschineneinheiten befinden.
Wenn Ihre Maschine also auf dem zölligen System basiert, Sie sich aber im metrischen Modus befinden, müssen Änderungen der Schrittgeschwindigkeit, die an die Funktionen "AKTION" gesendet werden, in zöllige Einheiten umgewandelt werden.
Wenn die Maschine auf metrischen Einheiten basiert und Sie sich im imperialen Modus befinden, müssen Änderungen der Tippgeschwindigkeit an die "AKTION"-Funktionen in metrischen Einheiten gesendet werden.
Für die Winkelgeschwindigkeit ändern sich die Einheiten im metrischen/imperialen Modus nicht, so dass Sie sie ohne Umrechnung an die Funktionen "AKTION" senden können.

Während es Ihnen freisteht, diesen Jogging-Datensatz beim Erstellen von Bildschirmen zu ignorieren, würde jeder, der Ihren Bildschirm modifiziert und die eingebauten Jog-Rate-Widgets verwendet, nicht die gewünschten Ergebnisse erhalten, da die DO_JOG-Funktion der ACTION-Bibliothek ihre Jog-Rate von der STATUS-Bibliothek erhält.

5.3. Tastenbelegung

Warnung
 Die Zuordnung (engl. binding) von Tasten ist immer eine schwierige Angelegenheit, die man nicht in allen Fällen richtig hinbekommt.

Benutzerdefinierte Tastenbindungsfunktionen müssen in der Handler-Datei definiert werden.

Vor allem Widgets, die eine reguläre Tasteneingabe und kein Rütteln erfordern, sollten in der Funktion processed_key_event__ überprüft werden.

5.4. Einstellungsdatei

Einige QtVCP Widgets verwenden die Präferenzdatei, um wichtige Informationen aufzunehmen.

Dies erfordert, dass diese Einstellungsdatei früh im Initialisierungsprozess des Widgets eingerichtet wird.
Der einfachste Weg, dies zu tun, ist die Verwendung des ScreenOptions-Widgets.

5.5. Spezielle Widget-Einrichtungsfunktionen

QtVCP sucht und ruft die Funktion +_hal_init()+ auf, wenn das Widget zum ersten Mal geladen wird.

Diese wird nicht aufgerufen, wenn der Qt Designer Editor verwendet wird.

Nachdem diese Funktion aufgerufen wurde, hat das Widget Zugriff auf einige spezielle Variablen:

self.HAL_GCOMP

Die HAL-Komponenten-Instanz

self.HAL_NAME

Der Name dieses Widgets als String

self.QT_OBJECT_

dieses Widgets PyQt-Objekt als Instanz

self.QTVCP_INSTANCE_

Die übergeordnete Ebene des Bildschirms

self.PATHS_

Die _Instanz der Pfadbibliothek von QtVCP

self.PREFS_

Die Instanz einer optionalen Präferenzdatei

self.SETTINGS_

Das Qsettings Objekt

Wenn Sie ein benutzerdefiniertes Widget erstellen, _importieren Sie die Klasse +_HalWidgetBase+ und spezialisieren Sie sie für dieses Verhalten durch Anlegen einer Unterklasse.

5.6. Dialoge

Dialoge (auch bekannt als "Pop-up-Fenster") werden am besten mit dem ScreenOptions _widget geladen, aber sie können auch im Qt Designer auf dem Bildschirm platziert werden.

Es spielt keine Rolle, wo auf dem Layout, aber um sie auszublenden, schalten Sie die Eigenschaft state auf true und dann auf false.

Wenn eine Einstellungsdatei vorhanden ist, merken sich die Dialoge standardmäßig ihre letzte Größe/Position.
Es ist möglich, dies außer Kraft zu setzen, so dass sie jedes Mal an der gleichen Stelle geöffnet werden.

5.7. Stile (Designs, engl. themes)

Es ist zwar möglich, Stile im Qt Designer zu setzen, aber es ist bequemer, sie später zu ändern, wenn sie alle in einer separaten .qss Datei gesetzt werden. Diese Datei sollte am gleichen Ort wie die Handler-Datei abgelegt werden.