Posts (de) | Ingenieurbüro Jan Böttcher

Der Prompt, den ich mir hätte sparen können

Fri, 26 Jun 2026 00:00:00 +0200

Ich befinde mich, wie wohl viele, gerade in einer Ausprobierphase: Was kann KI? Wo liegen ihre Grenzen? Und wie lässt sich diese Technologie sinnvoll nutzen? Im Spannungsfeld zwischen erstaunlichen Ergebnissen und kaum weniger erstaunlichen Halluzinationen, zwischen Token-Kosten und dem möglichen Abfluss sensibler Informationen, ist es notwendig, eine eigene Strategie für den Umgang mit LLMs und Agenten zu entwickeln.

Ein weiterer kleiner Punkt auf meiner Lessons-Learned-Liste kam letzte Woche dazu.

Die Aufgabe

Für eines meiner Programme musste ich die Testdokumentation für die manuellen Systemtests erstellen. Das Programm sammelt Passungsinformationen aus einer CAD-Zeichnung und erzeugt daraus eine Tabelle der Abmaße als Information für Fertigung und Qualitätskontrolle. Meine Testzeichnung enthält fünf Maße mit den Passungen 20 H7, 40 k6, 60 G7, 80 H8 und 80 f7. Für diese Maße sollten die zu erwartenden Programmergebnisse in der Testdokumentation tabelliert werden. Diese Fleißarbeit habe ich dann an die KI abgegeben.

Erzeuge mir eine Tabelle im Markdown-Format, die die oberen und unteren Abmaße für die Nennmaße und Toleranzen 20 H7, 40 k6, 60 G7, 80 h8 [sic!] und 80 f7 auflistet.

GPT-5.4 mini lieferte das Ergebnis schnell, schön formatiert und leider falsch.

Hier ist eine Markdown-Tabelle mit den oberen und unteren Abmaßen für die genannten Nennmaße und Toleranzen:

Nennmaß Toleranzlage Toleranzgrad Untermaß [mm] Obermaß [mm]

20 H 7 0,000 +0,021

40 k 6 +0,010 +0,026

60 G 7 -0,015 +0,006

80 H 8 0,000 +0,046

80 f 7 -0,071 -0,030

Wenn du möchtest, kann ich dir auch noch die zugehörigen Grenzmaße (oberes/unteres Grenzmaß) berechnen und ergänzen.

Nennmaß	Toleranzlage	Toleranzgrad	Untermaß [mm]	Obermaß [mm]
20	H	7	0,000	+0,021
40	k	6	+0,010	+0,026
60	G	7	-0,015	+0,006
80	H	8	0,000	+0,046
80	f	7	-0,071	-0,030

Die richtigen Werte für diese Passungen habe ich dann doch noch einmal selbst ganz konventionell ermittelt:

Nennmaß Toleranzlage Toleranzgrad Unteres Abmaß Oberes Abmaß

20 H 7 0,000 mm +0,021 mm

40 k 6 +0,002 mm +0,018 mm

60 G 7 0,010 mm 0,040 mm

80 H 8 0,000 mm +0,046 mm

80 f 7 -0,060 mm -0,030 mm

Nennmaß	Toleranzlage	Toleranzgrad	Unteres Abmaß	Oberes Abmaß
20	H	7	0,000 mm	+0,021 mm
40	k	6	+0,002 mm	+0,018 mm
60	G	7	0,010 mm	0,040 mm
80	H	8	0,000 mm	+0,046 mm
80	f	7	-0,060 mm	-0,030 mm

Fairerweise muss man zugeben, dass diese Aufgabe nicht trivial ist. Die korrekten Werte sind nicht fix, sondern werden mittels Tabellen nach einem in einer Norm festgelegten Schema bestimmt ¹. Mit GPT-5.4 mini hatte ich außerdem ein Modell gewählt, das auf Größe und Geschwindigkeit optimiert ist.

Ein Modellvergleich

Ist ein leistungsfähigeres Modell die Lösung? In einem kleinen Ad-Hoc-Test habe ich die Aufgabe anderen Modellen ² in der Cloud und lokal gestellt.

Zwei Modelle haben dabei in meinen Augen auf ganz unterschiedliche Weise alles richtig gemacht. Das kleine Claude Haiku hat mir mitgeteilt, dass es die Aufgabe nicht direkt lösen, mir aber den Lösungsweg aufzeigen könne. Claude Sonnet 4.6 hat viele Tokens verbraucht und mir dann eine korrekte Tabelle inklusive vollständigem Lösungsweg zur Ermittlung aus den Norm-Tabellen präsentiert.

Llama 3 hat unterhalb der generierten (falschen) Tabelle immerhin in einem Nachsatz erwähnt, dass es sich nur um Beispielwerte handelt.

Alle anderen Modelle lieferten mir, mit mehr oder weniger Zusatztext, schlicht ein falsches Ergebnis.

Nachtrag: In einem kleinen Folgetest ein paar Tage später habe ich dem Überflieger der ersten Runde, Claude Sonnet 4.6, noch einmal den gleichen Auftrag gegeben. Diesmal war das Ergebnis allerdings komplett falsch.

Sometimes you are the windshield, sometimes you are the bug

Die Erkenntnis

Zurück zu meiner Testdokumentation. Ein falscher Zahlenwert dort führt spätestens beim ersten Systemtest zu zusätzlichem Aufwand für die Suche nach einem Programmfehler, den es gar nicht gibt. Die KI-Ergebnisse können also nicht ohne eine sorgfältige Prüfung verwendet werden. Diese Prüfung erfordert aber wiederum exakt die Arbeit, die eigentlich gespart werden sollte.

Die für mich interessante Erkenntnis ist: Bei dieser Aufgabe lohnt es sich grundsätzlich nicht, sie an ein Sprachmodell zu delegieren. KI spart an dieser Stelle keine Zeit und verbessert auch die Qualität nicht. Selbst die Leistungsfähigkeit des Modells spielt dabei keine entscheidende Rolle. Der Aufwand zur Kontrolle der Ergebnisse ist immer der gleiche.

Eine Faustregel

Die gute Nachricht ist, dass sich solche Aufgaben vorab mit zwei Fragen identifizieren lassen:

Ist es kritisch, wenn das Ergebnis falsch oder ungenau ist?
Liegt der Aufwand zur Prüfung in der gleichen Größenordnung wie der Aufwand zur konventionellen Ermittlung des Ergebnisses?

Wenn beide Antworten ja lauten, besteht eine gute Chance, dass ein generalistisches Sprachmodell nicht das Werkzeug der Wahl ist.

Meinen Ursprungsprompt hätte ich jedenfalls nach kurzem Nachdenken gar nicht absetzen müssen.

https://de.wikipedia.org/wiki/Passung ↩︎
GPT-5.4 mini, GPT-5.4, Claude Haiku 4.5, Claude Sonnet 4.5, Claude Sonnet 4.6, Llama 3 8B (lokal), Gemma 4 E4B (lokal). ↩︎

NX Open in VS Code debuggen

Wed, 06 Apr 2022 10:13:00 +0200

Inhaltsverzeichnis

Hintergrund

In einem anderen Artikel hatte ich gezeigt, wie NX Open Programme mit dem Quellcodeeditor VS Code (Visual Studio Code) erstellt und kompiliert werden können¹.

Ein wichtiges Werkzeug bei der Programmentwicklung und Fehlersuche ist der Debugger. VS Code und die C# Erweiterung zielen in erster Linie auf .NET Core und nicht das .NET Framework, das für die NX Open Entwicklung benötigt wird. Dennoch lassen sich auch .NET Framework Applikationen debuggen².

Voraussetzungen

Das hier beschrieben Vorgehen ist nur zum Debuggen von kompilierten NX Open Applikationen geeignet. Ein Debuggen von Journalen³ ist unter VS Code nicht möglich.

Das Aufsetzen der Entwicklungsumgebung wird in ¹ beschrieben.

Anpassen des NX Open Projektes

Zunächst muss das Projektfile *.csproj angepasst werden. Es ist wichtig, dass als PlatformTarget x64 angegeben ist und als DebugType portable.

...
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">
    <DebugSymbols>true</DebugSymbols>
    <Optimize>false</Optimize>
    <OutputPath>bin\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <Prefer32Bit>false</Prefer32Bit>
    <PlatformTarget>x64</PlatformTarget><!-- To enable debugging with vs code-->
    <DebugType>portable</DebugType><!-- To enable debugging with vs code-->
 </PropertyGroup>
...

Erstellen einer Startkonfiguration

Zum Erstellen einer Debug-Konfiguration muss die Datei launch.json um einen entsprechenden Eintrag erweitert werden. Falls diese Datei noch nicht existiert, muss sie im Verzeichnis .vscode neu angelegt werden (siehe z.B. ⁴).

Debugkonfiguration in launch.json.

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Attach to process",
            "type": "clr",
            "request": "attach",
            "processId" : "${command:pickProcess}"
        }
    ],
    "compounds": []
}

Debuggen

Zunächst wird NX regulär gestartet. Danach kann mit F5 die Debug-Sitzung in VS Code gestartet und der NX Prozess ausgewählt werden.

Debug-Sitzung starten

Beim Ausführen der NX Open Applikation werden jetzt Break-Points angesprungen.

Breakpoint im Code.

NX Open und VS Code: https://www.ib-boettcher.de/de/post/nxopen-vscode/ ↩︎ ↩︎
Desktop .NET Framework: https://github.com/OmniSharp/omnisharp-vscode/wiki/Desktop-.NET-Framework ↩︎
Der Begriff Journal wird im erweiterten Sinn häufig auch für NX Open-Programme allgemein verwendet. Hier sind aber ausschließlich in VB.NET oder C# realisierte Programme gemeint, die direkt als Quellcode ausgeführt werden. ↩︎
stackoverflow, feO2x: https://stackoverflow.com/a/53271098 ↩︎

Langsame Journale?

Fri, 14 May 2021 09:46:18 +0200

Inhaltsverzeichnis

Ob ich bei der Umsetzung eines NX Zusatzprogramms auf ein Journal¹ oder eine compilierte Lösung setze, hängt von vielen verschiedenen Faktoren ab. Falls eine bestimmte Programmiersprache für die Realisierung vorgesehen ist, besteht unter Umständen keine Wahl. C/C++ und Java müssen immer compiliert werden. Pythonprogramme liegen immer als Skript vor.

Die .NET Sprachen C# und VB.NET können in NX sowohl compiliert als auch uncompiliert zum Einsatz kommen. Hier kann das Antwortverhalten und die Ablaufgeschwindigkeit ein wichtiger Faktor für die Auswahl der einen oder anderen Variante sein. Es ist naheliegend, dass compilierte .NET Programme einen Geschwindigkeitsvorteil besitzen. Wie groß ist dieser Unterschied jedoch tatsächlich? Welchen Auswirkung hat er in der Praxis?

Hintergrund

Uncompilierte .NET NX Open Journale werden nicht zur Laufzeit interpretiert. Der Quellcode wird bei jedem Aufruf des Journals mit dem im .NET Framework standardmäßig vorhandenen Compiler übersetzt, geladen und dann regulär ausgeführt. Während des Programmlaufes kann man das entsprechende Assembly unter dem Namen journal.dll im von NX verwendeten temporären Verzeichnis finden. Nach Abschluss des Programmlaufes wird diese dll jedesmal durch NX gelöscht.

Für die Ausführungsgeschwindigkeit des eigentlichen Programminhaltes bedeutet das interessanterweise, dass compilierte Programme keinen Vorteil gegenüber uncompiliert vorliegenden Journalen haben können. In der Gesamtbilanz kommt jedoch bei den Journalen der Overhead zur internen Compilierung hinzu. Dieser Overhead vergrößert die Antwortzeit der Applikation nach dem Start.

Ein weiterer Aspekt muss bei der Betrachtung zusätzlich berücksichtigt werden. Bei compilierten Programmen kann die Entladeoption für das Assembly festgelegt werden (Immediately, At Termination, Explicitly). Bei Journalen wird diese Option im Quelltext ignoriert. Die Assemblys von Journalen werden nach dem Programmende immer entladen (Immediately). Compilierte Programme können also bei Bedarf davon profitieren, dass NX die Assemblys für eine erneute Ausführung im Speicher vorhält.

Testaufbau

Da, wie gezeigt, für die Fragestellung nur der Overhead zum Compilieren und das Entladeverhalten relevant sind, kann ein sehr einfaches Testprogramm verwendet werden. Es enthält lediglich die Ausgabe eines Markers in die NX-Logdatei.

using NXOpen;
using System;

public class SmallUi
{
    public static int Main(string[] args)
    {
        int retValue = 0;

        Session.GetSession().LogFile.WriteLine("%%%SUI");

        return retValue;
    }

    public static int GetUnloadOption(string arg)
    {
        return System.Convert.ToInt32(Session.LibraryUnloadOption.Immediately);
    }


}

Um den Einfluss der Quelltextgröße festzustellen wurde ein weiteres Programm erstellt, das vom ausgeführten Inhalt her dem ersten entspricht. Zusätzlich wurde der Quellcode eines mittelgroßen realen Projektes so hinzugefügt, dass er zwar mitcompiliert, aber nicht ausgeführt wird. Entstanden ist dabei eine Quellcodedatei mit rund 2700 Zeilen.

Von beiden Programmen wurde je eine Variante mit der Entladeoption Immediately (direkt nach Programmende) und At Termination (beim Beenden von NX) erstellt, compiliert und mit der Authoring-Lizenz signiert. Die Quellcodes des kurzen und des langen Programmes können zudem direkt als Journale ausgeführt werden. Damit ergeben sich insgesamt 6 zu testende Varianten:

SUI: Kurzes Programm, compiliert, Entladen direkt nach Programmende
SUAT: Kurzes Programm, compiliert, Entladen beim Beenden von NX
SUIJ: Kurzes Programm, Ausführung als Journal
BUI: Langes Programm, compiliert, Entladen direkt nach Programmende
BUAT: Langes Programm, compiliert, Entladen beim Beenden von NX
BUIJ: Langes Programm, Ausführung als Journal

Um die Laufzeit der verschiedenen Programme zu ermitteln, dient zusätzlich ein kleines Programm das lediglich einen Zeitstempel in die NX Log-Datei schreibt. Weiterhin wurde eine MenuScript-Datei (.men) erstellt, die für jede der genannten 6 Varianten einen Action Button mit einer aufeinderfolgenden Folge von Aktionen in NX erzeugt.

...
BUTTON SMALLUI
LABEL Small UI
ACTIONS ${mypath}time\application\time.dll
ACTIONS ${mypath}time\application\time.dll
ACTIONS ${mypath}time\application\time.dll
ACTIONS ${mypath}time\application\time.dll
ACTIONS ${mypath}time\application\small_ui.dll
ACTIONS ${mypath}time\application\time.dll
ACTIONS ${mypath}time\application\time.dll
ACTIONS ${mypath}time\application\time.dll
ACTIONS ${mypath}time\application\time.dll
ACTIONS ${mypath}time\application\time.dll
ACTIONS ${mypath}time\application\small_ui.dll
ACTIONS ${mypath}time\application\time.dll
...

Auf diese Weise werden die einzelnen Programme auf einen Kopfdruck unmittelbar hintereinander durch NX ausgeführt. Zur Auswertung können die Zeitstempel und die Marker der eigentlichen Programme aus der Logdatei ausgelesen werden. Aus dem Abstand zweier einen Marker umschließender Zeitstempel abzüglich des Abstands zweier direkt aufeinander folgender Zeitstempel kann die tatsächliche Laufzeit der zu testenden Variante ermittelt werden. In ersten Versuchen zeigte sich, dass immer wieder Ausreißer bei der Laufzeit des Zeitstempelprogrammes auftraten. Deshalb wird das Zeitstempel-Programm mehrfach hintereinander aufgerufen und zur Berechnung der Laufzeiten der eigentlichen Programme der Median verwendet.

Für jede der 6 Programmvarianten wurden 9 Läufe mit einem jeweils neu gestartetem NX durchgeführt. Die Laufzeiten für den ersten und den zweiten Programmaufruf ergeben sich wiederum aus dem Median dieser 9 Läufe. Die ermittelten Werte sind ein Maß für das Antwortverhalten der verschiedenen Varianten.

Die Tests wurden unter NX1953 auf einer älteren Workstation mit Xeon CPU durchgeführt. Die Ergebnisse sind nur qualitativ auf andere Systeme übertragbar.

Ergebnisse

Laufzeiten der kurzen Programmvarianten.
SUI: compiliert, Entladen direkt nach Programmende.
SUAT: compiliert, Entladen beim Beenden von NX.
SUIJ: Ausführung als Journal.
(1): erster Programmlauf, (2): zweiter Programmlauf.

Die Abbildung zeigt die Ergebnisse für die kurze Programmvarianten. Die vollständige Laufzeit beträgt für die compilierten Varianten knapp 0,6 Sekunden beim ersten Start (SUI (1), SUAT (1)). Beim zweiten Start ist die Laufzeit auf rund 0,2 Sekunden reduziert, wenn die dll vorher nicht entladen wurde (SUAT (2)). Wurde die dll entladen (SUI (2)), entspricht die Laufzeit der des Erststarts. Die Journal-Varianten (SUIJ (1), SUIJ (2)) haben eine deutlich längere Laufzeit von rund 1,2 Sekunden. Der zweite Lauf ist geringfügig schneller als der erste.

Laufzeiten der langen Programmvarianten.
BUI: compiliert, Entladen direkt nach Programmende.
BUAT: compiliert, Entladen beim Beenden von NX.
BUIJ: Ausführung als Journal.
(1): erster Programmlauf, (2): zweiter Programmlauf.

Die Abbildung zeigt die Ergebnisse für die lange Programmvariante. Auch hier beträgt die Laufzeit für die compilierten Varianten knapp 0,6 Sekunden beim ersten Start (BUI (1), BUAT (1)) und 0,2 Sekunden beim zweiten Start, wenn die dll vorher nicht entladen wurde (BUAT (2)). Das uncompilierte Journal (BUIJ) hat mit 1,4 Sekunden eine etwas längere Laufzeit als die kurze Version.

Fazit

Insgesamt zeigen die Messungen kein Überraschungen. Uncompilierte Journale benötigen für den Start und das Beenden deutlich mehr Zeit als ihre compilierten Gegenstücke. Idealerweise beträgt die Antwortzeit auf eine Benutzerinteraktion weniger als eine Sekunde (siehe z.B. ² oder ³). Die compilierten Programme liegen alle deutlich unter dieser Marke. Journale zeigen ein schlechteres Antwortverhalten. Die Werte sind allerdings nicht so hoch, dass der Arbeitsfluss unterbrochen wird.

Der Einfluss der Quellcodegröße auf die Startdauer der Programme ist compiliert wie uncompiliert gering.

Hinsichtlich der Ablaufgeschwindigkeit des eigentlichen Programminhaltes gibt es keinen Unterschied zwischen compilierten und uncompilierten Applikationen.

Wenn die Responsivität eine sehr große Rolle spielt, dann sind compilierte NX Open .NET Applikationen vorzuziehen. In allen anderen Fällen können durchaus auch Journale verwendet werden.

Der Begriff Journal wird im erweiterten Sinn häufig auch für NX Open-Programme allgemein verwendet. Hier sind aber ausschließlich in VB.NET oder C# realisierte Programme gemeint, die direkt als Quellcode ausgeführt werden. ↩︎
Michael Herczeg, Software-Ergonomie, Addison-Wessley 1994, S.203 ↩︎
https://developer.gnome.org/hig-book/unstable/feedback-response-times.html.en ↩︎

QR-Code Annotations erzeugen (Beispiel)

Fri, 21 Aug 2020 08:46:18 +0200

Inhaltsverzeichnis

Hintergrund

QR-Codes werden häufig eingesetzt um Informationen fehlertolerant maschinenlesbar anzubringen. NX bietet (derzeit) nur die Möglichkeit über einen speziellen Zeichensatz eindimensionale Strichcodes als Hinweise (Annotations) zu erzeugen. Hier soll nun gezeigt werden, wie mittels eines NX Open Journals in Python QR-Codes auf einfache Weise eingefügt werden können.

Voraussetzungen

Für die Kodierung des Inhaltes wird das Pythonpaket qrcode¹ benötigt. Außerdem muß die Systemschriftart Courier New vorhanden sein.

Implementierung

Wird für die Erzeugung der Annotation eine nichtproportionale Schriftart gewählt, dann kann der Text zeilenweise aus Leerzeichen und einem quadratischen Symbol (hier Courier New, Geometric Shapes, Black Square) zusammengesetzt werden. Die Punktmatrix dafür kann mittels der Methode get_matrix der Klasse qrcode.QRCode aus dem zu codierenden Inhalt ermittelt werden.

"""
Create QR Code Annotations in NX Example
Author: Jan Boettcher, www.ib-boettcher.de, 2020
"""
import qrcode
import NXOpen
import NXOpen.Annotations
import NXOpen.Drawings
import NXOpen.UF

def main():
    """
    Main task.
    """
    session: NXOpen.Session = NXOpen.Session.GetSession()
    work_part: NXOpen.Part = session.Parts.Work

    do_continue = True
    if work_part is None:
        NXOpen.UI.GetUI().NXMessageBox.Show(
            "nxqr", NXOpen.NXMessageBox.DialogType.Error, "No work part."
            )
        do_continue = False
    if do_continue:
        do_continue, text = get_text()   
    if do_continue:
        do_continue, position = pick_position()
    if do_continue:
        matrix = create_qr_matrix(text)
        text_array = create_nx_text(matrix)
        font_index = add_font(work_part)
        qr_prefs = {
            "GeneralTextFont": font_index,
            "GeneralTextLineSpacFactor": 0.00001,
            "GeneralTextSize": 1.0,
            "GeneralTextAspectRatio": 1.0,
        }
        old_prefs = switch_prefs(work_part, qr_prefs)
        create_annotation(work_part, position, text_array)
        switch_prefs(work_part, old_prefs)

def create_annotation(part, position, text_array):
    """
    Create the annotation.
    """
    drafting_note_builder = part.Annotations.CreateDraftingNoteBuilder(
        NXOpen.Annotations.SimpleDraftingAid.Null
        )
    drafting_note_builder.Origin.Origin.SetValue(
        NXOpen.TaggedObject.Null, NXOpen.View.Null, position
        ) 
    drafting_note_builder.Origin.SetInferRelativeToGeometry(False)
    drafting_note_builder.Text.TextBlock.SetText(text_array)
    drafting_note_builder.Commit()
    drafting_note_builder.Destroy()


def add_font(part: NXOpen.Part):
    """
    Add font for annotation.
    """
    courier_index = part.Fonts.AddFont(
        "Courier New", NXOpen.FontCollection.Type.Standard
        )
    return courier_index


def switch_prefs(part, prefs):
    """
    Store current annotation preferences and set some new.
    """
    pref_builder = part.SettingsManager.CreatePreferencesBuilder()

    annotation_style = pref_builder.AnnotationStyle
    lettering_style = annotation_style.LetteringStyle
    old_prefs = {
        "GeneralTextFont": lettering_style.GeneralTextFont,
        "GeneralTextLineSpacFactor": lettering_style.GeneralTextLineSpaceFactor,
        "GeneralTextSize": lettering_style.GeneralTextSize,
        "GeneralTextAspectRatio": lettering_style.GeneralTextAspectRatio,
    }
    lettering_style.GeneralTextFont  = prefs["GeneralTextFont"]
    lettering_style.GeneralTextLineSpaceFactor = prefs["GeneralTextLineSpacFactor"]
    lettering_style.GeneralTextSize = prefs["GeneralTextSize"]
    lettering_style.GeneralTextAspectRatio = prefs["GeneralTextAspectRatio"]
    pref_builder.Commit()
    pref_builder.Destroy()

    return old_prefs


def pick_position():
    """
    Ask user to pick a position.
    """
    response, view, point = NXOpen.UI.GetUI().SelectionManager.SelectScreenPosition(
        "Pick QR Position"
        )
    do_continue = response == NXOpen.Selection.DialogResponse.Pick
    return do_continue, point

def get_text():
    """
    Ask user for QR content.
    """
    message = "Enter Text"
    text = "Some Text"
    uf_session = NXOpen.UF.UFSession.GetUFSession()
    uf_session.Ui.LockUgAccess(NXOpen.UF.UFConstants.UF_UI_FROM_CUSTOM)
    text, length, response = uf_session.Ui.AskStringInput(message, text)
    uf_session.Ui.UnlockUgAccess(NXOpen.UF.UFConstants.UF_UI_FROM_CUSTOM)
    do_continue = response == 5 or response == 3
    return do_continue, text
   
def create_qr_matrix(text):
    """
    Create the QR Code matrix.
    """
    qr = qrcode.QRCode(
        version=None
    )
    qr.add_data(text)
    qr.make(fit=True)
    matrix = qr.get_matrix()
    return matrix

def create_nx_text(matrix):
    """
    Create annotation text from matrix.
    """
    text_array = []
    for row in matrix:
        text = ""
        for dot in row:
            if dot == True:
                text = text + "\u25A0"
            else :
                text = text + " "
        
        text_array.append(text)
    return text_array

if __name__ == '__main__':
    main()

qrcode on pypi.org ( https://pypi.org/project/qrcode/) ↩︎

NX Open und VS Code

Fri, 03 Jul 2020 08:46:18 +0200

Inhaltsverzeichnis

Hintergrund

Üblicherweise werden NX Open-Applikationen in C# mit Microsofts Visual Studio erstellt. NX bringt Wizards zum bequemen Aufsetzen von entsprechenden Projekten mit. Wer jedoch nicht auf diese Entwicklungsumgebung zurückgreifen kann oder will, der hat mit dem quelloffenen VS Code (Visual Studio Code) eine gute Alternative.
Abgesehen vom Namen und vom Hersteller haben diese beiden Tools nur begrenzte Gemeinsamkeiten. VS Code ist in erster Linie ein Quellcodeeditor¹.
Für kleine und mittlere NX Open Projekte ist jedoch das Wesentliche dabei. Insbesondere die IntelliSense-Funktionalität, die für ein produktives Arbeiten mit den zahlreichen Klassen und Methoden der NX Open-API unentbehrlich ist, entspricht der von Visual Studio.

Voraussetzungen

Neben dem eigentlichen Programm sind für die Verwendung von VS Code als Entwicklungsumgebung für NX Open-Applikationen noch zusätzliche Komponenten notwendig. Die jeweils benötigte Version dieser Komponenten hängt wesentlich von der NX-Zielversion ab. Im hier vorgestellten Beispiel ist die Zielversion NX 1899. Alle neben NX notwendigen Bestandteile sind kostenfrei verfügbar.

NX 1899 inkl. Programming Tools Feature
.NET Framework 4.6.2 Developer Pack²
Visual Studio Code³
C# for Visual Studio Code (VS Code Erweiterung)

Wenn nicht nur unkompilierte Journale erstellt werden sollen, dann muss zusätzlich der Compiler installiert werden:

.NET Desktop-Buildtools (Bestandteil der Buildtools für Visual Studio 2019⁴). Von den optionalen Komponenten sollten mindesten die .NET Framework 4.6.2-Enwicklungstools installiert werden.

Details zur Verwendung von VS Code finden sich z.B. hier⁵. Die C# Erweiterung für VS Code kann aus dem Programm heraus installiert werden.

C# Erweiterung installieren.

VS Code und die C# Erweiterung zielen in erster Linie auf .NET Core und nicht das .NET Framework, das hier für die NX Open Entwicklung benötigt wird. Entsprechend erscheint unter Umständen eine Meldung, die auf das Fehlen des .NET Core SDKs hinweist. Diese Meldung kann ignoriert oder unterdrückt werden.

Die Meldung zum .NET Core SDK kann ignoriert werden.

Weiterhin sollte bei der Verwendung von VS Code für die NX Open Entwicklung die Umgebungsvariable UGII_BASE_DIR gesetzt sein. Dies kann über ein kleines Startskript geschehen. Hier kann auch gleich der Pfad zu den Buildtools zur PATH Variable hinzugefügt werden, falls nicht nur unkompilierte Journale erstellt werden sollen.

rem Set NX base path
set "UGII_BASE_DIR=c:\nx\NX 1899"
rem Add compiler path
set "PATH=C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin;%PATH%"
rem Run VS Code
code

NX Open Projekte aufsetzen

Zunächst muss für das Projekt ein neues Verzeichnis an beliebiger Stelle erzeugt und dieses Verzeichnis in VS Code geöffnet werden. Das kann in einem Schritt über File/Open Folder… und das entsprechende Kontextmenü geschehen.

Projektverzeichnis anlegen und öffnen.

Das für ein funktionierendes IntelliSense und ein mögliches Kompilieren notwendige Projektfile muss per Hand angelegt werden. Als Vorlage kann die Template-Datei des Wizards aus der NX-Installation dienen (<UGII_BASE_DIR>\UGOPEN\vs_files\VC#\VC#Wizards\ NXOpen_VCS\Templates\1033\default_dll.csproj). Die Erweiterung der neuen Datei muss csproj lauten.

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">x64</Platform>
    <ProductVersion>8.0.50727</ProductVersion>
    <SchemaVersion>2.0</SchemaVersion>
    <!-- You may want to make this GUID unique -->
    <ProjectGuid>{ECAB86B8-89C2-4806-B397-C2B07638CFXX}</ProjectGuid>
    <!-- Use 'library' for internal NX Open program and 'exe' for external -->
    <OutputType>library</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace></RootNamespace>
    <!-- Enter name of the compiled dll/exe -->
    <AssemblyName>nx_project</AssemblyName>
    <!-- Enter target framework -->
    <TargetFrameworkVersion>v4.6.2</TargetFrameworkVersion>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <Prefer32Bit>false</Prefer32Bit>
	<PlatformTarget>x64</PlatformTarget>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x64' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>bin\Release\</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <Prefer32Bit>false</Prefer32Bit>
	<PlatformTarget>x64</PlatformTarget>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="NXOpen, Culture=neutral, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>$(UGII_BASE_DIR)\nxbin\managed\NXOpen.dll</HintPath>
	  <Private>False</Private>
    </Reference>
    <Reference Include="NXOpen.UF, Culture=neutral, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>$(UGII_BASE_DIR)\nxbin\managed\NXOpen.UF.dll</HintPath>
	  <Private>False</Private>
    </Reference>
    <Reference Include="NXOpen.Utilities, Culture=neutral, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>$(UGII_BASE_DIR)\nxbin\managed\NXOpen.Utilities.dll</HintPath>
	  <Private>False</Private>
    </Reference>
    <Reference Include="NXOpenUI, Culture=neutral, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>$(UGII_BASE_DIR)\nxbin\managed\NXOpenUI.dll</HintPath>
	  <Private>False</Private>
    </Reference>
    <Reference Include="System" />
    <Reference Include="System.Data" />
    <Reference Include="System.Xml" />
  </ItemGroup>
  <ItemGroup>
    <!-- Add sourcefiles to include -->
    <!-- 
    <Compile Include="<source>.cs" />
    -->
  </ItemGroup>
  <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets"/>
</Project>

Projektverzeichnis mit Projektdatei.

Nun können eine oder mehrere Quellcodedateien zum Projekt hinzugefügt werden. Alle Dateien müssen in der Projektdatei eingetragen werden.

...
  <ItemGroup>
    <!-- Add sourcefiles to include -->
    <Compile Include="program.cs" />
  </ItemGroup>
...

Nun stehen alle Features zur Quellcodehervorhebung und zur automatischen Vervollständigung zur Verfügung.

Quellcodehervorhebung und Vervollständigung.

Kompilieren

Vor dem Kompilieren müssen die Buildtools installiert und die PATH-Umgebungsvariable entsprechend angepasst sein.

Zum Kompilieren Strg + Shift + b drücken. Falls der notwendige Build-Task noch nicht vorhanden ist, wird die Erzeugung angeboten.

Build-Task erzeugen.

JSON Konfigurationsdatei erzeugen.

Vorlage auswählen.

Im Unterordner .vscode des Projektverzeichnisses ist nun die Datei tasks.json zu finden. Diese kann nun noch nach dem folgenden Beispiel modifiziert werden.

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "msbuild debug",
            "type": "shell",
            "command": "msbuild",
            "args": [
                // Ask msbuild to generate full paths for file names.
                "/property:GenerateFullPaths=true",
                "/t:build",
                "/p:Configuration=Debug",
                // Do not generate summary otherwise it leads to duplicate errors in Problems panel
                "/consoleloggerparameters:NoSummary"
            ],
            "group": "build",
            "presentation": {
                // Reveal the output only if unrecognized errors occur.
                "reveal": "silent"
            },
            // Use the standard MS compiler pattern to detect errors, warnings and infos
            "problemMatcher": "$msCompile"
        },
        {
            "label": "msbuild release",
            "type": "shell",
            "command": "msbuild",
            "args": [
                // Ask msbuild to generate full paths for file names.
                "/property:GenerateFullPaths=true",
                "/p:Configuration=Release",
                "/t:build",
                // Do not generate summary otherwise it leads to duplicate errors in Problems panel
                "/consoleloggerparameters:NoSummary"
            ],
            "group": "build",
            "presentation": {
                // Reveal the output only if unrecognized errors occur.
                "reveal": "silent"
            },
            // Use the standard MS compiler pattern to detect errors, warnings and infos
            "problemMatcher": "$msCompile"
        }

    ]
}

Nach erneutem Drücken von Strg + Shift + b kann nun zwischen einem Debug- und einem Release-Build ausgewählt werden.

Fazit

VSCode kann mit verhältnismäßig geringem Aufwand eingerichtet und für die Entwicklung von NX Open Applikationen in C# verwendet werden. Insbesondere für unkompilierte Journale und kleinere Projekte ist es eine Alternative zu Visual Studio.

VS Code auf Wikipedia ↩︎
.NET Framework 4.6.2 Developer Pack: https://dotnet.microsoft.com/download/dotnet-framework/net462 ↩︎
Visual Studio Code: https://code.visualstudio.com ↩︎
Buildtools für Visual Studio: https://visualstudio.microsoft.com/downloads ↩︎
Visual Studio Code Dokumentation: https://code.visualstudio.com/docs ↩︎

.NET NX Journale debuggen

Wed, 06 May 2020 09:46:18 +0200

Inhaltsverzeichnis

Hintergrund

Journale¹ sind ein beliebtes Mittel um Abläufe in NX zu automatisieren oder individuelle Erweiterungen zu realisieren. Zur Ausführung ist keine Compilierung und keine zusätzliche Lizenz notwendig. Es gibt jedoch auch verschiedene Nachteile. Gelegentlich wird als Nachteil genannt, dass die Fehlersuche mit einem Debugger nicht möglich sei. Das stimmt jedoch so nicht. Über einen kleinen Umweg können auch C# und VB.NET Journale mit Visual Studio oder auch WinDbg debuggt werden. Für umfangreichere Journale oder bei hartnäckigen Fehlern kann sich dieser Aufwand lohnen.

Lösungsansatz

Entscheidend für die Lösung des Problems ist, wie NX .NET Journale ausführt. Das auszuführende Journal wird dabei zunächst unter einem generischen Namen in ein temporäres Verzeichnis kopiert. Diese Kopie wird zur Laufzeit compiliert und anschließend gelöscht. Jetzt lädt NX das entstandene .NET Assembly wie ein reguläres NX Open-Programm. Nach Abarbeitung des Programmes löscht NX das temporäre Verzeichnis samt Inhalt.
Während des Programmlaufs ist mit dem Assembly und der zugehörigen Symboldatei (pdb-Datei) im temporären Verzeichnis fast alles Notwendige für das Debuggen vorhanden. Lediglich der Quellcode, auf den in der Symboldatei verwiesen wird, liegt zur Laufzeit nicht mehr vor.
Unter der Annahme, dass das ursprüngliche Journal von NX tatsächlich unverändert in das temporäre Verzeichnis kopiert wird, kann der Quellcode aus der Originaldatei wieder hergestellt werden. Der Name der Quellcodedatei muss dabei dem Namen des Assemblies entsprechen. Außerdem darf die Kopie erst erstellt werden, wenn das Programm bereits abgearbeitet wird. Nun kann die Quellcodedatei in Visual Studio oder in einem anderen Debugger geöffnet und der Debugger mit dem NX-Prozess verbunden werden.
Ein kurzer Versuch zeigt, dass dieser Ansatz funktioniert, wenn das ursprüngliche Journal Zeilenumbrüche im Unix-Format besitzt (LF). Bei Zeilenumbrüchen im Windows-Format (CR LF) reicht das Kopieren und Umbenennen des Journals nicht aus. Hier stimmt der MD5-Hash, der für den Quellcode im Assembly hinterlegt ist, nicht mit dem der kopierten Datei überein. Ein Anpassen der Zeilenumbrüche in der kopierten Datei führt zum Erfolg.

Umsetzung

Einige für das Debuggen notwendige Schritte können durch das Journal selbst erledigt werden. Diese sind hier in einer kleinen Methode zusammengefasst, die direkt nach dem Start des Journals aufgerufen werden kann.

/// <summary>
/// Prepare debugging of uncompiled journals.
/// </summary>
public static void InitJournalDebug()
{
    string journalPath = Session.GetSession().ExecutingJournal;
    string extension = Path.GetExtension(journalPath);
    Uri uri = new Uri(Assembly.GetExecutingAssembly().GetName().CodeBase);
    string tmpSourcePath = Path.ChangeExtension(uri.LocalPath, extension);
    using (StreamWriter sw = File.CreateText(tmpSourcePath))
    {
        sw.NewLine = "\n";
        foreach (string line in File.ReadLines(journalPath))
        {
            sw.WriteLine(line);
        }
    }
    UI.GetUI().NXMessageBox.Show("Source File", NXMessageBox.DialogType.Information, string.Format("Source file for debugging:\n{0}", tmpSourcePath));
}

Die Methode kopiert das ursprüngliche Journal, versieht es mit den richtigen Zeilenumbrüchen und benennt es um. Danach wird die Programmausführung mittels eines Dialoges angehalten. Die im Dialog angezeigte Quellcodedatei kann vom Anwender in Visual Studio geöffnet und nach Bedarf mit Breakpoints versehen werden. Abschließend muss der Debugger an den NX-Prozess (ugraf.exe) angehängt und das Programm durch Bestätigen des Dialoges fortgesetzt werden.

Ein minimales Journal könnte also so aussehen:

using NXOpen;
using System;
using System.IO;
using System.Reflection;

public class Journal
{
    /// <summary>
    /// Journal entry point.
    /// </summary>
    /// <param name="args"></param>
    /// <returns></returns>
    public static int Main(string[] args)
    {
        int retValue = 0;
        try
        {
            InitJournalDebug();//Only for debugging, remove in production

            //Do something.
            double result = Foobar(Math.PI, Math.E);
        }
        catch (NXOpen.NXException e)
        {
            UI.GetUI().NXMessageBox.Show("Message", NXMessageBox.DialogType.Error, e.Message);
        }
        return retValue;
    }

    /// <summary>
    /// Prepare debugging of uncompiled journals.
    /// </summary>
    public static void InitJournalDebug()
    {
        string journalPath = Session.GetSession().ExecutingJournal;
        string extension = Path.GetExtension(journalPath);
        Uri uri = new Uri(Assembly.GetExecutingAssembly().GetName().CodeBase);
        string tmpSourcePath = Path.ChangeExtension(uri.LocalPath, extension);
        using (StreamWriter sw = File.CreateText(tmpSourcePath))
        {
            sw.NewLine = "\n";
            foreach (string line in File.ReadLines(journalPath))
            {
                sw.WriteLine(line);
            }
        }
        UI.GetUI().NXMessageBox.Show("Source File", NXMessageBox.DialogType.Information, string.Format("Source file for debugging:\n{0}", tmpSourcePath));
    }

    /// <summary>
    /// Do something.
    /// </summary>
    /// <param name="foo"></param>
    /// <param name="bar"></param>
    /// <returns></returns>
    public static double Foobar(double foo, double bar)
    {
        double res = foo * bar;
        return res;
    }

    /// <summary>
    /// Unload option.
    /// Without effect for uncompiled journals
    /// </summary>
    /// <param name="arg"></param>
    /// <returns></returns>
    public static int GetUnloadOption(string arg)
    {
        return System.Convert.ToInt32(Session.LibraryUnloadOption.Immediately);
    }
}

Meldungsfenster in NX mit Pfad zum Quelltext.

Anfügen des Debuggers.

Fazit

Es ist möglich, zur Fehleranalyse von uncompilierten Journalen einen Debugger zu verwenden. Das Vorgehen ist ein wenig umständlich, erweitert aber die Einsatzmöglichkeiten dieser Journale, da so auch umfangreichere Fehlersuchen in komplexeren Programmen möglich sind.

Der Begriff Journal wird im erweiterten Sinn häufig auch für NX Open-Programme allgemein verwendet. Hier sind aber ausschließlich in VB.NET oder C# realisierte Programme gemeint, die direkt als Quellcode ausgeführt werden. ↩︎