Posts (en) | Ingenieurbuero Jan Boettcher

Debug NX Open in VS Code

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

Background

In another article, I showed how NX Open programs can be created and compiled with the source code editor VS Code (Visual Studio Code)¹.

A debugger is an important tool for program development and troubleshooting. VS Code and the C# extension primarily target .NET Core and not the .NET Framework required for NX Open development. Nevertheless, .NET Framework applications can also be debugged².

Requirements

The procedure described here is only suitable for debugging compiled NX Open applications. Debugging journals³ is not possible with VS Code.

Setting up the development environment is described in ¹.

Configure the NX Open Project

First, the project file *.csproj must be adapted. PlatformTarget must be x64 and the DebugType must be 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>
...

Create Start Configuration

To create a debug configuration, a corresponding entry must be added to the launch.json file. If this file does not yet exist, it must be created in the .vscode directory (see e.g. ⁴).

Debug Configuration in launch.json.

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

Debuggen

First, NX must be started. Then the debug session can be launched in VS Code with F5 and the NX process can be selected.

Start Debug Session

When executing the NX Open application, the program stops at a breakpoint.

Breakpoint in C# Code.

NX Open und VS Code: https://www.ib-boettcher.de/en/post/nxopen-vscode/ ↩︎ ↩︎
Desktop .NET Framework: https://github.com/OmniSharp/omnisharp-vscode/wiki/Desktop-.NET-Framework ↩︎
The term journal is often used in a broader sense for NX Open programs in general. Here, however, it is used only for programs implemented in VB.NET or C # that are executed directly from source code. ↩︎
stackoverflow, feO2x: https://stackoverflow.com/a/53271098 ↩︎

Slow Journals?

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

Whether I rely on a Journal ¹ or a compiled solution when implementing an NX add-on program depends on many different factors. If a certain programming language is intended for the implementation, there may not be a choice. C/C++ and Java must always be compiled. Python programs are always executed as scripts.

The .NET languages C# and VB.NET can be used in NX both compiled and uncompiled. The responsiveness and the processing speed can be important factors for the selection of one or the other variant. It is obvious that compiled .NET programs have a speed advantage. But how big is this difference actually? What is its effect in practice?

Background

Uncompiled .NET NX Open Journals are not interpreted at runtime. Each time the journal is called, the source code is compiled with the standard compiler in the .NET Framework, loaded and then regularly executed. During the program run you can find the corresponding assembly under the name journal.dll in the temporary directory used by NX. After completion of the program run, this dll is deleted each time by NX.

Interestingly, this means for the execution speed of the actual program content that compiled programs cannot have any advantage over uncompiled Journals. In the overall balance, however, the overhead for internal compilation is added. This overhead increases the response time of the application after the start.

Another aspect must also be taken into account. In the case of compiled programs, the unload option for the assembly can be specified (Immediately, At Termination, Explicitly). In the case of Journals, this option is ignored in the source code. The assemblies of journals are always unloaded after the end of the program (Immediately). If necessary, compiled programs can benefit from the fact that NX holds the assemblies in memory for re-execution.

Test Setup

Since, as shown, only the overhead for compiling and the unloading behavior matter, a very simple test program can be used. It only writes a marker to the NX log file.

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);
    }


}

To determine the influence of the size of the source code, another program was created that corresponds to the first program in terms of its content. In addition, the source code of a medium-sized real project was added in such a way that it is compiled but not executed. The result is a source code file with around 2700 lines.

A variant of both programs was created, compiled, and signed with the authoring license with the unloading option Immediately (directly after the end of the program) and At Termination (when exiting NX). The source codes of the short and long programs can also be executed directly as journals. This results in a total of 6 variants to be tested:

SUI: Short Program, compiled, unload immediately
SUAT: Short Program, compiled, unload at NX termination
SUIJ: Short Program, run as Journal
BUI: Long Programm, compiled, unload immediately
BUAT: Long Programm, compiled, unload at NX termination
BUIJ: Long Programm, run as Journal

To determine the execution time of those programs, there is also a small program that only writes a timestamp in the NX log file. In addition, a MenuScript file (.men) was written that creates an action button with a consecutive sequence of actions in NX for each of the 6 variants mentioned.

...
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
...

In this way, the individual programs are executed immediately one after the other by NX at the push of a button. The timestamps and markers of the actual programs can be read from the log file for evaluation. The actual execution time of the variant to be tested can be determined from the distance between two timestamps enclosing a marker minus the distance between two directly consecutive timestamps. The first tests showed that outliers repeatedly occurred during the runtime of the time stamp program. This is why the timestamp program is called several times in succession and the median is used to calculate the execution times of the actual programs.

For each of the 6 program variants, 9 runs were carried out with a newly started NX. The execution times for the first and the second program call result from the median of these 9 runs. The values determined are a measure of the response behavior of the various variants.

The tests were carried out under NX1953 on an older workstation with a Xeon CPU. The results can only be transferred qualitatively to other systems.

Results

Execution times of short program variants.
SUI: compiled, unload immediately.
SUAT: compiled, unload at termination of NX.
SUIJ: run as Journal.
(1): first run, (2): second run.

The figure shows the results for the short program variants. The full execution time for the compiled variants is just under 0.6 seconds when started for the first time (SUI (1), SUAT (1)). At the second start, the execution time is reduced to around 0.2 seconds if the dll was not unloaded beforehand (SUAT (2)). If the dll was unloaded (SUI (2)), the execution time corresponds to that of the initial start. The journal variants (SUIJ (1), SUIJ (2)) have a significantly longer execution time of around 1.2 seconds. The second run is slightly faster than the first.

Execution times of short program variants.
BUI: compiled, unload immediately.
BUAT: compiled, unload at termination of NX.
BUIJ: run as Journal.
(1): first run, (2): second run.

The figure shows the results for the long program variant. Here, too, the execution time for the compiled variants is just under 0.6 seconds at the first start (BUI (1), BUAT (1)) and 0.2 seconds at the second start if the dll has not been unloaded beforehand (BUAT (2 )). The uncompiled journal (BUIJ) has a slightly longer execution time of 1.4 seconds than the short version.

Conclusion

Overall, the measurements show no surprises. Uncompiled journals take significantly longer to start and stop than their compiled counterparts. Ideally, the response time to user interaction is less than a second (see e.g. ² or ³). The compiled programs are all well below this mark. Journals show poorer response behavior. However, the values are not so high that the workflow is interrupted.

The influence of the source code size on the start time of the programs is small, compiled, and uncompiled.

Concerning the speed at which the actual program content runs, there is no difference between compiled and uncompiled applications.

If responsiveness plays a very important role, then compiled NX Open .NET applications are preferable. In all other cases, Journals can also be used.

The term journal is often used in a broader sense for NX Open programs in general. Here, however, it is used only for programs implemented in VB.NET or C # that are executed directly from source code. ↩︎
Michael Herczeg, Software-Ergonomie, Addison-Wessley 1994, S.203 ↩︎
https://developer.gnome.org/hig-book/unstable/feedback-response-times.html.en ↩︎

Create QR Code Annotations (Example)

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

Background

QR codes are often used to attach information that is fault-tolerant and machine-readable. NX (currently) only offers the option of generating one-dimensional barcodes as annotations using a special character set. This post aims to show how QR codes can be easily inserted using an NX Open Journal in Python.

Requirements

The python package qrcode¹ is required to encode the content. The system font Courier New must also be available.

Implementation

If a non-proportional font is selected for generating the annotation, the text can be composed of spaces and a square symbol (here Courier New, Geometric Shapes, Black Square) line by line. The point matrix for this can be determined from the content to be coded using the get_matrix method of the qrcode.QRCode class.

"""
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 and VS Code

Thu, 09 Jul 2020 08:46:18 +0200

Background

NX Open applications written in C# are usually created with Microsoft’s Visual Studio. NX has wizards to easily set up the corresponding projects. However, if you can’t or don’t want to use that development environment, the open-source program VS Code (Visual Studio Code) is a good alternative. Apart from the name and the manufacturer, those two tools have only a few things in common. VS Code is primarily a source code editor¹.
For small and medium-sized NX Open projects, all necessary features are there. In particular, IntelliSense, which is indispensable for working productively with the numerous classes and methods of the NX Open API, corresponds to that of Visual Studio.

Requirements

In addition to the actual program, other components are required to use VS Code as a development environment for NX Open applications. The required version of these components depends on the NX target version. In the example presented here, the target version is NX 1899. All components necessary in addition to NX are available online for free.

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

If not only uncompiled journals are to be created, the compiler must be installed separately:

.NET Desktop-Buildtools (part of the der Buildtools for Visual Studio 2019⁴). From the optional components at least the .NET Framework 4.6.2 development tools should be installed.

Details on the use of VS Code can be found here⁵. The C# extension for vs code can be installed from within the program.

Install C# extension.

VS Code with the C # extension is primarily aimed at .NET Core and not .NET Framework, which is required for NX Open development. Accordingly, a message may appear indicating that the .NET Core SDK is missing. This message can be ignored or suppressed.

The message on the .NET Core SDK can be ignored.

Furthermore, the environment variable UGII_BASE_DIR should be set when using VS Code for NX Open development. This can be done by using a small start script. The path to the build tools can also be added to the PATH variable here if not only uncompiled journals are to be created.

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

Set up NX Open Projects

First, a new directory must be created for the project and must be opened in VS Code. This can be done in one step by File/Open Folder… and the corresponding context menu.

Create and open project directory.

The project file required for a working IntelliSense and compilation must be created by hand. The template file of the wizard from the NX installation can serve as a template (<UGII_BASE_DIR>\UGOPEN\vs_files\VC#\VC#Wizards\ NXOpen_VCS\Templates\1033\default_dll.csproj). The extension of the new file must be csproj.

<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>

Project directory with project file.

Now one or more source code files can be added to the project. All files must be entered into the project file.

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

Now all features for source code highlighting and automatic completion are available.

Source code highlighting and autocomplete.

Compiling

Before compiling, the build tools must be installed and the PATH environment variable must be adjusted accordingly. Press Ctrl + Shift + b to compile. If the necessary build task is not yet available, the generation is offered.

Create build task.

Create JSON configuration file.

Select task template.

The tasks.json file can now be found in the .vscode subfolder of the project directory. It can be modified according to the following example.

{
    // 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"
        }

    ]
}

After pressing Ctrl + Shift + b again you can choose between a debug and a release build.

Conclusion

VSCode can be set up with relatively little effort and used for the development of NX Open applications in C# as an alternative to Visual Studio, especially for uncompiled journals and smaller projects.

VS Code on Wikipedia ↩︎
.NET Framework 4.6.2 Developer Pack: https://dotnet.microsoft.com/download/dotnet-framework/net462 ↩︎
Visual Studio Code: https://code.visualstudio.com ↩︎
Buildtools for Visual Studio: https://visualstudio.microsoft.com/downloads ↩︎
Visual Studio Code Documentation: https://code.visualstudio.com/docs ↩︎

Debug .NET NX Journals

Thu, 14 May 2020 09:46:18 +0200

Background

Journals¹ are a popular means of automating and customizing processes in NX. No compiling and no additional licenses are required for execution. But there are also several disadvantages. One that is mentioned sometimes, is that debugging is not possible. However, this is not true. With a small detour, C # and VB.NET journals can be debugged with Visual Studio or WinDbg. This effort can be worthwhile for larger journals or persistent bugs.

Approach

The way NX .NET runs journals is critical to solving the problem. The journal to be executed is first copied into a temporary directory under a generic name. This copy is compiled at runtime and then deleted. Now NX loads the resulting .NET assembly like a regular NX Open program. After executing the program, NX deletes the temporary directory and its contents. During the execution of the program, almost everything necessary for debugging is available in the temporary directory with the assembly and the associated symbol file (pdb file). Only the source code referred to in the symbol file is no longer available at runtime.
Assuming that the original journal from NX is copied unchanged into the temporary directory, the source code can be restored from the original file. The name of the source code file must match the name of the assembly. Additionally, the copy may only be made when the program is already being processed. Now the source code file can be opened in Visual Studio or another debugger and the debugger can be connected to the NX process.
A quick test shows that this approach works if the original journal has line breaks in Unix format (LF). With line breaks in Windows format (CR LF), copying and renaming the journal is not sufficient. In this case, the MD5 hash that is stored for the source code in the assembly does not match that of the copied file. Adjusting the line breaks in the copied file is necessary.

Implementation

Some steps necessary for debugging can be done by the journal itself. These are summarized here in a small method that can be called immediately after the start of the journal.

/// <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));
}

The method copies the original journal provides it with the correct line breaks and renames it. Then the program execution is stopped using a dialog. The source code file displayed in the dialog can be opened by the user in Visual Studio and provided with breakpoints as required. Finally, the debugger must be attached to the NX process (ugraf.exe), and the program continued by confirming the dialog.

A minimal journal could look like this:

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);
    }
}

NX Dialog showing the path to the source code.

Attach the debugger.

Conclusion

It is possible to use a debugger to analyze errors in uncompiled journals. It’s a little cumbersome, but it expands the possible uses of these journals since it enables advanced troubleshooting in more complex programs.

The term journal is often used in a broader sense for NX Open programs in general. Here, however, it is used only for programs implemented in VB.NET or C # that are executed directly from source code. ↩︎

Posts (en) | Ingenieurbuero Jan Boettcher

Debug NX Open in VS Code

Table of Contents

Background

Requirements

Configure the NX Open Project

Create Start Configuration

Debuggen

Slow Journals?

Table of Contents

Background

Test Setup

Results

Conclusion

Create QR Code Annotations (Example)

Table of Contents

Background

Requirements

Implementation

NX Open and VS Code

Table of Contents

Background

Requirements

Set up NX Open Projects

Compiling

Conclusion

Debug .NET NX Journals

Table of Contents

Background

Approach

Implementation

Conclusion