Skip to content

NX Live Control Architecture

Source files: D:\02_Code\47_NXconnection\README.md, D:\02_Code\47_NXconnection\NATIVE_CPP_HOST_ARCHITECTURE.md, current Techstack operational tracking
Last synthesized: April 2026 Purpose: Explain how RapidDraft controls a real NX session for drawing review and generation, and how that runtime layer relates to the broader CAD SDK stack.

Why This Exists

TextCAD has two different CAD infrastructure problems that look similar from a distance but are not the same in implementation.

The first problem is headless geometry and translation: load STEP or other CAD data, analyze it, heal it, simplify it, and run deterministic geometry workflows. That is where OCCT, FreeCAD, and commercial translator SDKs matter most.

The second problem is live CAD-session control: drive the exact NX window an engineer is looking at, create or update drawing sheets, and inspect the result visually while the CAD session remains open. That is where NX Open matters.

This page documents the second layer.

Architectural Role

The NX live-control layer is not a replacement for the existing geometry stack.

Instead, the stack now has two complementary layers:

  1. Headless geometry layer
  2. OCCT / FreeCAD / translator SDKs
  3. neutral-format ingestion

  4. geometry reasoning, feature extraction, DFM, and preprocessing

  5. In-session CAD control layer

  6. NX Open host loaded into the real NX session
  7. live commands for opening parts, managing sheets, and creating review drawings
  8. Rapid Shot used as the visual verification gate after each mutating step

The important design choice is to stop pretending that all NX-driven work can be reduced to file translation. Some product workflows need the real CAD application in the loop.

Current Control Paths

The current D:\02_Code\47_NXconnection repo carries three NX control paths:

  1. Filesystem bridge
  2. oldest fallback path

  3. useful for compatibility and debugging

  4. Managed live host

  5. loaded once into NX
  6. targets the exact visible NX session
  7. currently the most complete review-loop path

  8. already supports sheet lifecycle commands, review-sheet creation, layout updates, section-view attempts, and PDF export

  9. Native NX Open C++ host

  10. current migration target
  11. uses a localhost named pipe instead of .NET remoting
  12. currently kernel-stage rather than review-loop complete
  13. already supports ping, session_info, bridge_status, listing_message, and open_part

Why the Long-Term Target Is Native C++

The managed host solved the transport question. It proved that the agent can target the exact visible NX session instead of a detached helper flow.

The remaining hard problems are deeper NX problems, especially drafting associativity and section-view creation. Those are the places where the native NX Open C++ surface is more attractive because:

  • it is the deepest supported NX Open surface for this use case
  • it sits naturally beside Open C / UFUNC, which can be used when the higher-level drafting builders become too restrictive
  • it gives a stronger long-term path for treating NX as a real runtime boundary rather than a plugin-specific workaround

So the operating stance is:

  • use the managed host as the working path today
  • converge the architecture on the native C++ host as the long-term control surface

Relationship to the CAD SDK Decision

This architecture does not change the current recommendation that OCCT remains the right default headless geometry layer for TextCAD.

The better way to think about the stack is:

  • OCCT / FreeCAD / translators answer: “How do we process CAD data without the CAD app?”
  • NX Open live control answers: “How do we control the real NX session when the workflow must stay inside NX?”

That distinction matters because RapidDraft drawing review and generation for NX pilots is no longer purely a neutral-file problem.

Current Open Gaps

The native host is not yet the default path because several pieces still need to migrate:

  1. the full review drawing loop
  2. robust section-view creation
  3. the hardest associativity edge cases in NX drafting

The key remaining technical problem is section-view associativity. Live session control now works; the open question is how to express section definitions in the way NX drafting actually requires.

Practical Implication for Product Planning

This work moves NX from “one more CAD file source” to “a live runtime surface with its own control plane.” That is important for RapidDraft because some pilot workflows depend on interacting with the actual drafting environment, not only on parsing geometry offline.

In product terms, that means the CAD infrastructure story now has two bets:

  • neutral geometry infrastructure for broad CAD reasoning
  • native NX control for workflows that must stay inside NX

Sources

  • D:\02_Code\47_NXconnection\README.md
  • D:\02_Code\47_NXconnection\NATIVE_CPP_HOST_ARCHITECTURE.md
  • D:\02_Code\47_NXconnection\native\NxLiveHostCpp.cpp
  • C:\Users\adeel\OneDrive\100_Knowledge\203_TextCAD\01_Product_Project_Management\00_Project_Management_n_skills\01_tracks\techstack\TRACKING.md
  • C:\Users\adeel\OneDrive\100_Knowledge\203_TextCAD\01_Product_Project_Management\00_Project_Management_n_skills\03_decision_log\DL-006_nx-live-control-should-converge-on-native-cpp-host.md