📅 Project Plan

Blade Generation System Development Timeline

📊 Project Summary

Metric Value
Total Phases 16 (Core + Advanced Features + Robotics)
Completed 3 phases (19%)
In Progress 3 phases
Pending 10 phases
Estimated Completion Q2-Q3 2026

🆕 New in this version (Jan 5, 2026)

  • ✅ Double Envelope Blade Profile (WORKING) - 2 second performance, production ready
  • 🔍 Post-Fixture Raycast Analysis - Hybrid validation concept (contact, clearance, weld access, stability)
  • 🔀 Sheet-Based Blade Profile - Return sheets instead of kurves, skip unnecessary conversions
  • Weight Calculation System
  • Center of Gravity (CoG) Calculation
  • Robot Reach Study (Kinematic-free accessibility analysis)
  • 3-Tier Architecture (Full Local / Thin Client / Web SaaS)
  • Enhanced Weld Detection and Export
  • Modular Blade Assembly ("Lego Block" with T-Wedge/Spring Clip)
  • Blade Profile Dual-Mode Architecture - Precise (section) + Fast (projection)

📚 Macro Reference

Last Updated: 09 January 2026 | Full Reference Documentation →

🎯 Primary Entry Points

Macro Type Purpose
fxCreateBladeFromIntersect PRODUCTION PRIMARY - Creates complete blade solid from part body
fxBladeProfileVector PRODUCTION Generates blade profile kurve(s) using vector-based positioning
fxReadBladeJSON PRODUCTION Parses blade parameters from JSON config file
fxMakeWatertight PRODUCTION Heals holes in solid bodies using sld fac rem

🧪 Test Harness Macros

Macro Location Purpose
fxTestBladeFromIntersect modeling\blade\testing\ PRIMARY TEST - Tests 5 blade orientations (modes 0-4)
fxIntegrationTest io\json\testing\ JSON → Profile → Blade Solid (with progress)
fxTestBladeProfileVectorFull modeling\blade\testing\ Tests profile generation on multiple parts
fxTestJSONParsing io\json\ Validates JSON parsing against example files
fxTestGravityOffset modeling\blade\testing\ Tests gravity-aware offset in multiple directions

🔧 Quick Usage Guide

'*** PRODUCTION: Create blade from part
call fxCreateBladeFromIntersect i_partBody w_centerX w_centerY w_centerZ \
                                 w_normX w_normY w_normZ w_thickness w_stockMargin
i_bladeBody = i_return

'*** TEST: Run 5-orientation blade test
call fxTestBladeFromIntersect 0 0 80   ' Mode 0 (X-normal), no win control, body 80
call fxTestBladeFromIntersect 1 0 80   ' Mode 1 (Y-normal)
call fxTestBladeFromIntersect 2 0 80   ' Mode 2 (Z-normal)
call fxTestBladeFromIntersect 3 0 80   ' Mode 3 (45° XY compound)
call fxTestBladeFromIntersect 4 0 80   ' Mode 4 (3D diagonal)

'*** JSON WORKFLOW: Load config and create blade
call fxIntegrationTest 0 80  ' Full test with progress visualization

Visualization Tools

🌐 NucleoSphere Progress Indicator

Progress visualization macro fxNucleoSphere creates a multi-layer sphere with rotational progress quadrant.

  • Up to 8 concentric, semi-transparent spherical shells
  • Date-based event colors (Pride Month, Halloween, etc.) or default grayscale
  • Auto-sized radius based on model extents (~5% of largest dimension)
  • Progress representation via Z-axis rotation
  • 5 configurable position modes for overlay display

🎨 Event-Based Color System

The NucleoSphere automatically changes colors based on the current date. Events are defined in language-specific configuration files.

INI Setting Value Behavior
fxNucleoEventColors 1 (default) Auto - use event colors when current date matches an event window
fxNucleoEventColors 0 Disabled - always use default grayscale
fxNucleoEventColors -1 Demo mode - cycle through ALL events sequentially (for testing)
Configuration Files
File Language
fxNucleoEvents.034 Spanish
fxNucleoEvents.044 English (default/fallback)
fxNucleoEvents.049 German
fxNucleoEvents.055 Portuguese
Config File Format
# Comment lines start with # # Format: START_MMDD,END_MMDD,EVENT_NAME,R1,G1,B1,R2,G2,B2[,R3,G3,B3...] # Dates in MM-DD format (year-independent, events repeat annually) # Colors cycle to fill all 8 shells (2 colors = alternating pattern) 06-01,06-30,Pride Month,255,0,0,255,127,0,255,255,0,0,255,0,0,0,255,139,0,255 10-24,11-07,Halloween,255,117,24,25,25,25
Pre-Configured Events (2026)
  • Pride Month (Jun 1-30) - 6-color rainbow
  • Lunar New Year (Feb 10-24) - Red/Gold
  • St. Patrick's Day (Mar 10-24) - Emerald/White
  • Earth Day (Apr 15-29) - Azure/Green
  • Independence Day (Jun 27-Jul 11) - Red/Blue (English only)
  • Halloween (Oct 24-Nov 7) - Orange/Black
  • Diwali (Nov 1-15) - Saffron/Purple
  • Remembrance/Veterans Day (Nov 4-18) - Poppy Red/Black

📍 Position Modes

The sphere can be positioned at 5 different locations relative to the model bounding box. All positions are at the top of the model (maxZ + offset) to stay visible and out of the way.

Mode Name X Position Y Position Z Position
0 Centre Model centre X Model centre Y Top (maxZ + offset)
1 Top-Left (default) Left (minX - offset) Front (minY - offset) Top (maxZ + offset)
2 Top-Right Right (maxX + offset) Front (minY - offset) Top (maxZ + offset)
3 Back-Left Left (minX - offset) Back (maxY + offset) Top (maxZ + offset)
4 Back-Right Right (maxX + offset) Back (maxY + offset) Top (maxZ + offset)
POSITION MODE LAYOUT (Top-Down View, looking at -Z) FRONT (minY) ┌─────────┬─────────┐ │ 1 │ 2 │ ← Front corners (modes 1, 2) │ Top-Left│Top-Right│ ├─────────┼─────────┤ │ │ │ │ ┌────┴────┐ │ │ │ MODEL │ │ │ │ 0 │ │ ← Centre (mode 0) - directly above │ │ Centre │ │ │ └────┬────┘ │ │ │ │ ├─────────┼─────────┤ │ 3 │ 4 │ ← Back corners (modes 3, 4) │Back-Left│Back-Rght│ └─────────┴─────────┘ BACK (maxY) All positions at same Z height (above model top)

📝 Syntax

call fxNucleoSphere w_progress w_radius i_shellCount w_lastRotation [i_displayMode] [i_positionMode]

Parameters:
  w_progress     - Progress 0-100, -1=initialize, i_NOT_SET=cleanup
  w_radius       - Sphere radius (auto-calculated in overlay mode)
  i_shellCount   - Number of shells (default 8)
  w_lastRotation - Previous rotation angle (for incremental updates)
  i_displayMode  - 0=overlay (default), 1=isolated at origin
  i_positionMode - 0-4 position mode (see table above)

Returns:
  i_return - Shell count
  w_return - Current progress value

Color Control:
  Colors are automatically determined by fxNucleoEventColors based on:
  - Current date (matches event windows in fxNucleoEvents.XXX files)
  - INI setting: fxNucleoEventColors = 1 (auto), 0 (disabled), -1 (demo)

💡 Usage Example

'*** Initialize sphere at top-right corner (mode 2)
call fxNucleoSphere -1 i_NOT_SET 5 i_FALSE i_FALSE 2
i_shellCount = i_return

'*** Update progress in a loop
for i_step = 1 to 100
   call fxNucleoSphere i_step i_NOT_SET i_shellCount w_return i_FALSE 2
   '*** ... do work ...
next i_step

'*** Cleanup when done
call fxNucleoSphere i_NOT_SET i_NOT_SET i_shellCount w_return i_FALSE 2

📦 Deliverables

fxNucleoSphere.ovm - Main progress indicator macro

fxNucleoEventColors.ovm - Date-based event color loader

fxNucleoEvents.044 - English event configuration

fxNucleoEvents.034, .049, .055 - Localized event configs

fxProgressUpdate.ovm - Wrapper with GUI control flags

fxTestProgressHandler.ovm - Test harness for all position modes

🏗️ 3-Tier Architecture Options

The fixture system supports three deployment architectures to match different customer needs and infrastructure constraints.

Tier 1: Full Local (Air-Gapped)

Complete standalone installation. All processing happens on customer's machine. No network required.

┌─────────────────────────────────────────────────────┐ │ CUSTOMER'S WORKSTATION │ │ │ │ ┌─────────────┐ ┌─────────────┐ │ │ │ PEPS/ │◀──▶│ Fixture │ │ │ │ SolidCut │ │ Macro Suite │ │ │ └─────────────┘ └─────────────┘ │ │ │ │ │ │ └────────┬─────────┘ │ │ ▼ │ │ ┌─────────────┐ │ │ │ Local UI │ │ │ │ (Electron) │ │ │ └─────────────┘ │ └─────────────────────────────────────────────────────┘ PROS: Complete data isolation, no latency, works offline CONS: No AI assistance, manual updates required

Tier 2: Thin Client (Hybrid)

Local CAD/CAM with web-based UI and optional cloud AI. Geometry stays local, only abstracted data transmitted.

┌─────────────────────────────────────────────────────┐ │ CUSTOMER'S WORKSTATION │ │ ┌─────────────┐ ┌─────────────┐ │ │ │ PEPS/ │◀──▶│ Fixture │ │ │ │ SolidCut │ │ Macro Suite │ │ │ └─────────────┘ └──────┬──────┘ │ │ │ Local API │ │ ▼ │ │ ┌─────────────┐ │ │ │ Thin Client │ │ │ │ (Browser) │ │ │ └──────┬──────┘ │ └──────────────────────────┼──────────────────────────┘ │ HTTPS (abstracted data only) ▼ ┌──────────────────────────────────────────────────────┐ │ YOUR SERVER (Cloud or On-Prem) │ │ ┌────────────┐ ┌────────────┐ ┌────────────────┐ │ │ │ Web UI │ │ AI Engine │ │ Blade Generator│ │ │ │ (React) │ │ (Claude) │ │ (Python/OVM) │ │ │ └────────────┘ └────────────┘ └────────────────┘ │ └──────────────────────────────────────────────────────┘ PROS: AI assistance, easy updates, light client footprint CONS: Requires network, abstraction limits AI context

Tier 3: Web SaaS (Full Cloud)

Browser-based CAD viewer with all processing in cloud. Customer uploads models, receives fixture designs.

┌─────────────────────────────────────────────────────┐ │ CUSTOMER'S BROWSER │ │ ┌─────────────────────────────────┐ │ │ │ Web Application │ │ │ │ - 3D Viewer (Three.js) │ │ │ │ - Parameter Forms │ │ │ │ - Result Download │ │ │ └───────────────┬─────────────────┘ │ └──────────────────┼──────────────────────────────────┘ │ HTTPS (full geometry upload) ▼ ┌──────────────────────────────────────────────────────┐ │ CLOUD INFRASTRUCTURE │ │ ┌────────────┐ ┌────────────┐ ┌────────────────┐ │ │ │ Model │ │ Fixture │ │ AI Decision │ │ │ │ Storage │ │ Engine │ │ Engine │ │ │ │ (S3/Blob) │ │ (Parasolid)│ │ (Claude API) │ │ │ └────────────┘ └────────────┘ └────────────────┘ │ └──────────────────────────────────────────────────────┘ PROS: No local install, full AI context, scalable CONS: Requires geometry upload, subscription model
  • ○ Define API contracts between tiers
  • ○ Implement local-to-thin client bridge
  • ○ Build abstraction layer for privacy-first AI
  • ○ Develop web-based 3D viewer for Tier 3
  • ○ Create tier detection/selection UI

⚖️ Weight & Center of Gravity Calculation

Critical for fixture stability analysis, forklift handling, and positioner load verification.

Part Weight Calculation

Calculate weight from solid body volume and material density. Essential for fixture design decisions.

WEIGHT CALCULATION FLOW ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Solid Body │────▶│ sld ask bod │────▶│ Volume (m³) │ │ │ │ vol │ │ │ └─────────────┘ └─────────────┘ └──────┬──────┘ │ ┌─────────────┐ │ │ Material DB │◀────────────┤ │ - Steel: 7850 kg/m³ │ │ - Aluminum: 2700 kg/m³ │ │ - Stainless: 8000 kg/m³ │ └──────┬──────┘ │ │ │ ▼ ▼ ┌─────────────────────────────┐ │ Weight = Volume × Density │ └─────────────────────────────┘
  • ○ Implement volume query via sld ask bod vol
  • ○ Create material database (JSON or VDM)
  • ○ Support custom material density input
  • ○ Handle assemblies (sum of individual bodies)
  • ○ Output weight in kg and lbs

Center of Gravity (CoG) Calculation

Locate the mass centroid for balance analysis and positioner mounting.

CENTER OF GRAVITY OUTPUT ┌───────────────────────────┐ │ PART │ │ │ │ ⊕ CoG │ ◀── X, Y, Z coordinates │ (x, y, z) │ │ │ └───────────────────────────┘ USE CASES: - Verify fixture is balanced on positioner axis - Calculate moment arms for clamp force requirements - Determine forklift pickup points for safe handling - Check fixture won't tip during rotation
  • ○ Query CoG via sld ask bod cog or Parasolid API
  • ○ Compute combined CoG for multi-body assemblies
  • ○ Visualize CoG marker in 3D view
  • ○ Compare CoG to positioner rotation axis
  • ○ Generate stability report (tip-over risk)

Combined Fixture + Part Weight Analysis

Total weight including fixture components for crane/positioner capacity verification.

  • ○ Sum all blade weights (from flat pattern area × thickness × density)
  • ○ Add baseplate weight
  • ○ Add estimated hardware weight (bolts, clamps)
  • ○ Compare total to positioner max load
  • ○ Generate load capacity warning if exceeded

📦 Deliverables

fxCalcWeight.ovm - part weight calculation

fxCalcCoG.ovm - center of gravity calculation

fxFixtureWeightReport.ovm - combined weight analysis

material_database.json - material density lookup

🤖 Robot Reach Study

Mathematical accessibility analysis for robotic welding without full kinematic simulation. Uses arm segment lengths to determine if welds are reachable.

💡 Design Philosophy

This is NOT a full kinematic simulation. We're doing a simplified "can the torch tip physically reach this point?" check based on maximum arm extension. Real robots have joint limits, singularities, and collision constraints we're ignoring. This is a quick feasibility filter, not a motion planning tool.

Input Parameters

ROBOT ARM SEGMENT MODEL (Generic 6-Axis) ┌─────────────────────────────────────────────────────┐ │ ROBOT BASE (mounted position) │ │ - X, Y, Z position relative to fixture origin │ │ - Rotation about Z (base orientation) │ └───────────────────────┬─────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────┐ │ SEGMENT LENGTHS (from robot datasheet) │ │ - L1: Base to J2 axis (vertical reach) │ │ - L2: J2 to J3 (upper arm) │ │ - L3: J3 to J5 (forearm/wrist center) │ │ - L4: J5 to torch tip (tool length) │ └─────────────────────────────────────────────────────┘ TOTAL MAX REACH = L1 + L2 + L3 + L4 (fully extended) INNER DEAD ZONE = typically ~300-500mm (can't reach too close)
  • ○ Robot base position input (X, Y, Z, Rz)
  • ○ Segment length inputs (L1, L2, L3, L4)
  • ○ Inner dead zone radius (min reach)
  • ○ Optional: multiple robot positions for cell layout

Reach Envelope Calculation

REACH ENVELOPE (Top View) Max Reach Sphere ╱ ╲ ╱ REACHABLE ╲ ╱ ZONE ╲ │ ┌───────────┐ │ │ │ INNER │ │ │ │ DEAD ZONE │ │ │ │ (can't │ │ │ │ reach) │ │ │ └───────────┘ │ ╲ ╱ ╲ ╱ ╲ ╱ ───────────── ⊕ Robot Base For each weld point P: distance = sqrt((Px-Rx)² + (Py-Ry)² + (Pz-Rz)²) IF distance > MAX_REACH: UNREACHABLE (too far) IF distance < MIN_REACH: UNREACHABLE (too close) ELSE: POTENTIALLY REACHABLE

Weld Accessibility Analysis

For each weld bead, check if the torch can reach the start, end, and key intermediate points.

ACCESSIBILITY OUTPUT (CSV/JSON) Weld_ID | Start_X | Start_Y | Start_Z | End_X | End_Y | End_Z | Reachable | Distance | Notes --------|---------|---------|---------|-------|-------|-------|-----------|----------|-------- W001 | 150.0 | 200.0 | 50.0 | 150.0 | 350.0 | 50.0 | YES | 890mm | W002 | 850.0 | 100.0 | 25.0 | 850.0 | 250.0 | 25.0 | MARGINAL | 1180mm | Near max reach W003 | 1200.0 | 400.0 | 75.0 | 1350.0| 400.0 | 75.0 | NO | 1450mm | Exceeds 1200mm max W004 | 50.0 | 50.0 | 200.0 | 50.0 | 150.0 | 200.0 | NO | 280mm | Inside dead zone
  • ○ Iterate all weld beads in model
  • ○ Calculate distance from robot base to each weld point
  • ○ Classify: REACHABLE / MARGINAL (90-100% of max) / UNREACHABLE
  • ○ Generate reach study report (CSV/JSON/HTML)
  • ○ Visualize reach envelope as transparent sphere in 3D

Optional Enhancements (Future)

  • ○ Torch angle feasibility (can torch approach at required angle?)
  • ○ Fixture collision check (is torch path blocked by blades?)
  • ○ Positioner rotation optimization (find best index angle)
  • ○ Multi-robot coverage analysis (which robot welds which beads)

⚠️ Limitations

This reach study does NOT account for:

  • Joint angle limits (J1-J6 min/max)
  • Singularity zones
  • Cable dress interference
  • Actual motion planning / collision avoidance

Use offline programming software (e.g., RoboDK, DELMIA) for full simulation.

📦 Deliverables

fxRobotReachStudy.ovm - main reach analysis macro

fxReachEnvelope.ovm - generate visual reach sphere

fxWeldAccessibilityReport.ovm - CSV/JSON export

robot_params.json - robot segment length database

🔥 Weld Detection & Offline Programming System

🎯 Vision: Smart Weld Data Generator

Build a "smart weld data generator" that does 70% of the intellectual work - finding welds, calculating vectors, sequencing, exporting - and let dedicated robot simulation tools (RoboDK, OEMs' software) handle the kinematics. This is a HIGH PRIORITY initiative.

What We Can Build (Achievable 3-6 months)

  • ✓ Identify weld seams automatically from part intersections
  • ✓ Calculate torch approach vectors with accessibility scoring
  • ✓ Sequence welds logically (minimize travel, thermal considerations)
  • ✓ Export to neutral format (CSV/JSON/XML) that feeds robot simulation

What's Hard (Not in scope for v1)

  • Full robot kinematics - every brand has different joint limits, reach envelopes, singularity zones
  • True collision-free motion planning through the workspace
  • Multi-pass welds, weave patterns
  • Real-world calibration and TCP management

Leave this to dedicated OLP tools like OCTOPUZ or DELMIA - we provide the smart data.

Identify weld beads in the model and export for robotic welding systems.

Weld Bead Detection

Identify weld bead solids based on geometry characteristics or layer/attribute markers.

  • ✓ Detection by solid body name/attribute
  • ○ Detection by geometric signature (linear sweep, triangular cross-section)
  • ○ Union touching/overlapping beads (sld int proximity test)
  • ○ Extract weld path centerline
  • ○ Calculate torch approach vector (default Z+, or face normal)

Export Formats

WELD EXPORT DATA STRUCTURE { "welds": [ { "id": "W001", "type": "fillet", "path": [ {"x": 100.0, "y": 200.0, "z": 50.0}, {"x": 100.0, "y": 350.0, "z": 50.0} ], "torch_vector": {"x": 0.707, "y": 0.0, "z": 0.707}, "parameters": { "leg_size": 6.0, "wire_speed": 300, "travel_speed": 400 } } ] }
  • ○ CSV export (simple point list)
  • ○ JSON export (structured with metadata)
  • ○ XML export (for legacy systems)
  • ○ STL export - individual beads
  • ○ STL export - combined/unioned beads

Robot Format Research

  • ○ Research Nachi robot weld format
  • ○ Research OTC Daihen format
  • ○ Research Fanuc RJ3iC weld format
  • ○ Create format conversion templates

📦 Deliverables

fxDetectWelds.ovm - weld bead identification

fxWeldUnion.ovm - merge touching beads

fxTorchVector.ovm - calculate approach vectors

fxWeldExportCSV.ovm, fxWeldExportJSON.ovm, fxWeldExportSTL.ovm

🗓️ Development Timeline

Phase 1: Foundation Complete

📅 December 2025 ⏱️ ~1 week

Established core infrastructure for VDM management, face extraction, and wire body processing.

  • ✓ VDM management patterns (allocVDM, freeVDM, data passing)
  • ✓ Face extraction from solid bodies
  • ✓ Wire body creation and manipulation
  • ✓ Wire to kurve conversion
  • ✓ Basic solid extrusion and boolean operations

📦 Deliverables

fxGetFreeKurve.ovm, fxRotateWireToXYPlane.ovm, VDM utilities

Phase 2: Rotation Technique Discovery Complete

📅 December 24-25, 2025 ⏱️ 1 day

Analyzed working 2019 codebase to identify the proven rotation technique for blade positioning.

  • ✓ Studied _4fxComputeBladeEdge2019.ovm
  • ✓ Identified rotation axis = blade line endpoints
  • ✓ Documented the 90°/-90° rotation technique
  • ✓ Understood sculpting zone workflow (work while flat)

📦 Key Insight

Rotation axis is simply (xStart, yStart, 0) to (xEnd, yEnd, 0) - not face normals!

Phase 2b: SLD Command Mastery Complete

📅 December 26-27, 2025 ⏱️ 1 day

Discovered and documented critical SLD commands for blade slice extraction and taper application.

  • ✓ SLD SEC (Section) - blade slice extraction with double-cut technique
  • ✓ SLD TAP (Taper) - draft angle application to pocket faces
  • ✓ SLD PUT FAC - programmatic face set building
  • ✓ Face normal filtering for correct face selection
  • ✓ Created comprehensive SLD_COMMAND_REFERENCE_FULL.html

📦 Deliverables

fxTestTaperVisual.ovm - working blade slice + taper test

SLD_COMMAND_REFERENCE_FULL.html - 73 commands documented

Phase 3: Simple Blade Generation In Progress

📅 December 2025 ⏱️ ~3 days remaining

Implement single-segment blade generation using the proven rotation technique.

  • ✓ fxCreateBladeSegment.ovm created
  • ◐ Fix transformation in fxBladeFromSection.ovm
  • ○ Test with rectangular part
  • ○ Verify blade wraps part correctly
  • ○ Edge modification integration

📦 Deliverables

fxBladeFromSection.ovm (fixed), fxCreateBladeSegment.ovm

Phase 4: Zigzag Blade System In Progress

📅 December 2025 - January 2026 ⏱️ ~1 week remaining

Multi-segment blade paths with corner handling for formed sheet metal parts.

  • ✓ fxZigzagBlade.ovm - main orchestrator
  • ✓ fxCornerHandling.ovm - three corner modes
  • ✓ fxTestZigzagBlade.ovm - test harness
  • ○ Test Mode 0: Overlap + Union
  • ○ Test Mode 1: Miter cut
  • ○ Test Mode 2: Radius blend
  • ○ Bend compensation calculation

📦 Deliverables

fxZigzagBlade.ovm, fxCreateBladeSegment.ovm, fxCornerHandling.ovm

Phase 5: Flat Pattern & DXF Output Pending

📅 January 2026 ⏱️ ~1 week estimated

Generate flat patterns with bend allowances for manufacturing output.

  • ○ Calculate flat pattern from 3D zigzag
  • ○ Apply bend allowance formulas
  • ○ Generate outline kurve for cutting
  • ○ Mark bend lines on separate layer
  • ○ Clean unused layers before DXF export - Quick utility to purge empty/unused layers
  • ○ DXF export with proper scaling

📦 Deliverables

fxCalcFlatPattern.ovm, fxExportBladeDXF.ovm, fxCleanUnusedLayers.ovm

Phase 5b: Laser Cut Optimization Features Pending

📅 January 2026 ⏱️ ~3-5 days estimated

Add laser-specific features to blade DXF output for optimal cutting and material handling.

🔺 Laser Pickup Points (Pierce Points)

Small V-notch or semicircle on non-mating edges to provide a consistent laser pierce/start location.

🔗 Micro-Joints / Tabs

Small uncut segments that keep blade pieces attached to the sheet skeleton during laser cutting.

📦 Deliverables

fxPiercePoint.ovm, fxMicroJoints.ovm, fxNonContactEdgeDetect.ovm

Phase 6: Test Mode Framework Pending

📅 January 2026 ⏱️ ~3 days estimated

Standardized test harness for validating macro functionality.

TEST MODE ARCHITECTURE ┌─────────────────────────────────────────────────────────┐ │ fxTestRunner.ovm │ │ ┌─────────────────────────────────────────────────┐ │ │ │ Mode 0-98: Individual unit tests │ │ │ │ Mode 99: Run ALL tests │ │ │ │ Mode 100: Visual grid test │ │ │ │ Mode 101: Performance benchmark │ │ │ └─────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────┐ │ Test Output Format │ │ - PASS/FAIL status per test │ │ - Expected vs Actual values │ │ - Execution time │ │ - Error messages with line numbers │ └─────────────────────────────────────────────────────────┘
  • ○ Define test mode number conventions
  • ○ Create test output formatting utilities
  • ○ Implement "run all tests" mode (99)
  • ○ Add visual grid test mode (100) for geometric tests
  • ○ Create test result logging to file

📦 Deliverables

fxTestRunner.ovm - main test orchestrator

fxTestUtils.ovm - assertion and logging utilities

test_results.log - output file format

Phase 7: Blade Orphan Detection Pending

📅 January 2026 ⏱️ ~2 days estimated

Identify blades that are not connected to the baseplate or other blades.

ORPHAN DETECTION SCENARIOS VALID: ORPHAN (Bad): ┌───┐ ┌───┐ ┌───┐ ┌───┐ │ │ │ │ │ │ │ │ ◀── Not slotted │ │ │ │ │ │ │ │ into base ├───┴───┴───┤ │ │ │ │ │ BASEPLATE │ ├───┴───┤ └───────────┘ │ BASE │ └───────┘ All blades connected Rightmost blade floating
  • ○ Query all blade bodies by attribute/layer
  • ○ Check each blade has slot connection to base OR another blade
  • ○ Use sld int to test body intersection
  • ○ Flag orphans with warning color/attribute
  • ○ Generate orphan report

📦 Deliverables

fxDetectOrphans.ovm - orphan detection

fxValidateFixture.ovm - full fixture validation suite

Phase 8: Blade Identity & Numbering Pending

📅 January 2026 ⏱️ ~3 days estimated

Handle the "one blade vs multiple blades" decision for connected segments.

  • ○ Design blade group data model
  • ○ Segment-to-blade relationship tracking
  • ○ Automatic "can bend as one" detection
  • ○ Manufacturing ID assignment system
  • ○ Blade label generation for DXF

📦 Deliverables

fxBladeIdentity.ovm, fxBladeGroupManager.ovm

Phase 9: Advanced Features Pending

📅 February 2026 ⏱️ ~2 weeks estimated

Edge treatments, weight reduction, and curved path support.

  • ○ Taper angle on blade edges
  • ○ Gripper features
  • ○ Weight reduction cutouts
  • ○ Arc segment support (curved paths)
  • ○ Collision detection between blades

📦 Deliverables

fxBladeEdgeMods.ovm (enhanced), fxArcSegment.ovm

Phase 10: Gravity Offset System In Progress

📅 December 2025 - January 2026 ⏱️ ~70% complete

Variable pocket offset based on gravity direction for optimal part support.

  • ✓ Core construction geometry approach
  • ✓ Line-to-line gravity offset
  • ✓ Line-to-arc gravity offset
  • ✓ Arc-to-line gravity offset
  • ◐ Arc-to-arc gravity offset (fallback to uniform)
  • ○ Multi-direction grid test (Mode 100)
  • ○ 'NONE' skip mode (no gravity processing)
  • ○ Auto-gravity detection from part orientation

📦 Deliverables

fxGravityOffsetConstruction.ovm, fxTestGravityOffset.ovm

Phase 11: Part Topology Categorization Pending

📅 Q1 2026 ⏱️ ~1 week estimated

Automatic detection and classification of part types to drive fixture strategy.

  • ○ TUBE/PIPE detection (cylindrical bodies)
  • ○ PLATE detection (flat, single thickness)
  • ○ SHEET_METAL detection (bent, needs welding consideration)
  • ○ STRUCTURAL detection (beams, angles, channels)
  • ○ OTHER classification for complex shapes
  • ○ Feed classification into fixture strategy selection

📦 Deliverables

fxPartTopology.ovm, fxFixtureStrategy.ovm

Phase 12: Weld Export System Pending

📅 February 2026 ⏱️ ~2 weeks estimated

Export weld bead geometry for robotic welding systems. See dedicated section above for details.

📦 Deliverables

fxWeldExport.ovm, fxWeldUnion.ovm, fxTorchVector.ovm

Phase 13: Part Alignment System Pending

📅 Q1 2026 ⏱️ ~1 week estimated

3-point origin matching for modified CAD imports. When customers re-export parts with different origins, realign to original fixture.

  • ○ Store original part origin reference points
  • ○ Detect origin shift in re-imported parts
  • ○ Calculate transformation matrix from 3-point match
  • ○ Apply alignment to re-imported geometry
  • ○ Verify alignment with visual feedback

📦 Deliverables

fxPartAlignment.ovm - 3-point alignment utility

fxStoreOriginRef.ovm - save reference points

Phase 14: Integration & Testing Pending

📅 Q2 2026 ⏱️ ~2 weeks estimated

Full system integration with existing fixture workflow and comprehensive testing.

  • ○ Integration with fixture plate generation
  • ○ Full workflow testing with real parts
  • ○ Performance optimization
  • ○ Error handling improvements
  • ○ User documentation & training materials

📦 Deliverables

Complete integrated system, user manual, training guide

🔧 Blade Edge Detail Systems

📎 3D Printed Clip-In Offset Inserts

Replaceable nylon/PETG clips that snap into holes along blade edges. Provides variable standoff distances without re-cutting blades.

📦 Deliverables

fxClipHolePattern.ovm - generate snap hole positions

offset-insert-15mm.stl through offset-insert-60mm.stl - printable insert models

🔗 Laminated Blade Connections - Offset Plug Weld

For laminated blades (multiple layers stacked), use staggered hole patterns to enable sequential plug welding from top only.

📦 Deliverables

fxLaminatedHolePattern.ovm - generate offset hole positions per layer

fxPlugWeldSequence.ovm - assembly instruction generator

🔥 Weld Cell Configuration

Fixture design must account for customer's welding equipment capabilities.

📋 Equipment Type Questionnaire

Configuration Fixture Impact
Stationary Table All welds must be accessible from above or sides. May need repositioning.
Single-Axis Positioner Can rotate fixture 360° around one axis. Design apertures for underside access.
Trunnion / 2-Axis Indexer Full orientation control. Can weld from any angle. Maximum flexibility in fixture design.

📦 Deliverables

fxWeldCellConfig.ovm - equipment type configuration

fxApertureGenerator.ovm - create torch access openings

fxRotationClearance.ovm - check for index collisions

🏗️ Base Plate Stiffening Options

For large or heavy-duty fixtures, the base plate may need additional stiffening to prevent deflection.

Option A: Tubular Sections with Forklift Skids

Rectangular or square tube sections welded to the underside of the base plate. Serves dual purpose as stiffeners and forklift skid positions.

Option B: Laminated Blades on -Z Side with Feet

Blades protruding downward from the base plate (negative Z direction) with feet connecting to a secondary base blade.

📦 Deliverables

fxBasePlateStiffening.ovm - main stiffening generator

fxTubularSkids.ovm - Option A implementation

fxLaminatedStiffeners.ovm - Option B implementation

🖥️ Cross-Platform UI Architecture

Language-independent parameter dialogs using JSON Schema with universal renderers.

Architecture Overview

┌─────────────────────────────────────────────────────┐ │ JSON Schema (fixture_blade_params.schema.json) │ │ - Defines all fields, types, validation │ │ - Localizable labels via i18n keys │ └─────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────┐ │ React + RJSF (Web UI) │ │ - Runs in browser OR Electron │ │ - Single codebase for web + desktop │ └─────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────┐ │ Output: fixture_params.json │ │ - PEPS macro reads this via PAC/file I/O │ └─────────────────────────────────────────────────────┘

📦 Deliverables

fixture_params.schema.json - master schema definition

i18n/*.json - translation files

web-ui/ - React + RJSF application

fxReadJsonParams.ovm - PEPS JSON parser

🛠️ Blade Profile Dual-Mode Architecture

Two complementary approaches for blade profile generation, preserving existing work while adding a faster alternative.

Mode A: Precise Section (Current - 2026)

Input: Part solid + blade plane at compound angle │ └─▶ sld sec (solid/plane intersection) │ └─▶ Extract intersection curves │ └─▶ Validate + build kurves │ └─▶ Output: Exact contact profile Pros: Accurate contact points, compound angle support Cons: Slower (~64s for 6 tests), requires watertight prep Use: Complex parts, angled blades, precision fixtures

Mode B: Fast Projection (Legacy - 2019)

Input: Part solid + blade line position │ └─▶ Create full-height blade solid │ └─▶ For each face: extrude in Z direction │ └─▶ Subtract extruded faces from blade │ └─▶ Rotate flat, convert to kurves │ └─▶ Output: Projected silhouette profile Pros: Much faster, handles overhangs naturally Cons: Z-only direction, less precise on curves Use: Simple parts, quick prototyping, bulk processing

Hybrid Strategy (Planned)

BLADE_PROFILE = UNION( sld_sec_intersection, ← Accurate contact (Mode A) projected_bbox_silhouette ← Full coverage (Mode B concept) ) Ensures blades extend to support overhanging geometry while maintaining precise contact point accuracy.

⚠️ Implementation Note

Do NOT modify existing Mode A (fxBladeProfileVector, fxProfileToKurve3D, compound macros). Mode B will be a separate code path selected via parameter. Both modes output compatible kurve formats.

📦 Files

Mode A (Preserve): fxBladeProfileVector.ovm, fxProfileToKurve3D.ovm, fxxProfileToKurve3D_Compound.ovm

Mode B (Resurrect): fxComputeBladeEdge2019.ovm, fxExtrudeSolidForBladeEdge.ovm

Reference: session-results-2026-01-02.html - performance metrics

🧱 Modular Blade Assembly System ("Lego Block" Design)

🔗 Concept Overview

A modular approach to blade construction where blades are built from segmented pieces that connect together using T-wedges or spring clips. Blades stand vertically on a baseplate with pre-cut slots. This enables incremental assembly, easy rework, and reusable components without welding.

📐 Reference CAD Model

4-view layout showing the modular assembly concept:

Modular Blade CAD Screenshot
📊 SVG Diagram

View Full SVG Diagram →

🔧 Key Components

Component Color (CAD) Description
Blade Segments White/Gray Steel plate sections that form the blade body
Overlap Zones Gray (2× thick) Where segments overlap by 2× material thickness
T-Wedge Connectors Cyan Drop-in from ±Z to lock overlapping segments
Spring Clips Cyan Snap-in from side as alternative to T-wedge
Feet Gray Optional blade extensions that drop into baseplate slots (not required on every segment)
Baseplate Brown/Copper Base with pre-cut slots at blade foot locations

📏 Assembly Rules

  • Segments overlap by 2× material thickness at joints
  • T-Wedge drops in from above/below (±Z) to lock segments together
  • Spring Clip snaps in from side as alternative locking method
  • Cross-blades can ONLY slot through single-layer zones (not overlap zones)
  • Blades connect to baseplate via T-slots + T-wedges (feet optional per segment)
  • Supports compound angles between segments

✅ Benefits

  • ✓ Incrementally buildable
  • ✓ Easily removable for rework
  • ✓ No welding required for assembly
  • ✓ Reusable components
  • ✓ Compound angle support
  • ✓ Modular like Lego blocks

📦 TODO - Implementation

  • ○ Define standard T-wedge and spring clip dimensions
  • ○ Implement overlap zone detection at segment joints
  • ○ Auto-place connection holes in overlap zones
  • ○ Cross-blade intersection validation (single-layer only)
  • ○ Baseplate T-slot generation for blade mounting
  • ○ BOM generation for connectors (T-wedge/clip counts)
  • ○ sma 2417 - Simplify topology after boolean operations

Files:

fxModularBladeAssembly.ovm - segment connection logic

fxTWedgeGenerator.ovm - T-wedge slot cutting

fxSpringClipSlot.ovm - spring clip aperture generation

🎯 Double Envelope Blade Profile (WORKING)

✅ Completed January 3, 2026 - 2 Second Performance

The double envelope approach is now production ready. This method generates complete blade profiles by sectioning at two positions (front/back of blade thickness) and mosaicing the results.

Workflow Overview

DOUBLE ENVELOPE BLADE PROFILE WORKFLOW ┌─────────────────────────────────────────────────────────┐ │ PART (at compound angle) │ │ │ │ Step 1: fxBladeEnvelopeSection │ │ → Section at centerline → Outer boundary kurve(s) │ │ │ │ Step 2: fxBladeProfileVector (double-section) │ │ → Section at center - thickness/2 (back face) │ │ → Section at center + thickness/2 (front face) │ │ → Mosaic both envelopes together │ │ │ │ Step 3: fxValidateBladeProfile │ │ → Extrude kurves to blade thickness │ │ → Transform bodies to compound angle position │ │ → Visualize as blue solids inside part │ └─────────────────────────────────────────────────────────┘ Performance: ~2 seconds for complete workflow Output: Multiple kurves (outer + inner boundaries)

Test Results (Jan 3, 2026)

Body 80 extents: Min: (-10.51, -6.62, 4.98) Max: (8.28, -0.04, 21.35) Blade center: (-1.12, -3.33, 13.16) Normal: (1, 0, 0) — vertical blade Envelope 1 (back): 2 kurves Envelope 2 (front): 2 kurves Mosaic output: 10 kurves Extruded: 6 bodies (4 kurves skipped - no area or too small) All 6 bodies transformed to correct positions inside part. Time: 2 seconds

Key Transform Matrix (for normal = (1,0,0))

1. translate x-centerX y-centerY z0 (move from (cx,cy,0) to origin) 2. rotate y90 (rotate XY plane to YZ plane) 3. translate xcenterX ycenterY zcenterZ (move to final position)
  • ✓ Core double envelope generation
  • ✓ Kurve filtering (skip if no spans, area < 1mm)
  • ✓ Body transformation to compound angle
  • ✓ Visual validation with blue solid bodies
  • ○ Delete input kurves after extrusion (cleanup)
  • ○ Optional union of touching bodies
  • ○ Test with 10°, 30° compound angles
  • ○ Add gravity offset to final profile

📦 Deliverables

fxBladeEnvelopeSection.ovm - Outer boundary from centerline slice

fxBladeMosaic.ovm - Combine envelope and clearance kurves

fxValidateBladeProfile.ovm - Extrude and transform validation solids

fxTestValidateBlade.ovm - Full workflow test

blade-profile-workflow.md - Comprehensive documentation

🔍 Post-Fixture Raycast Analysis (PLANNED)

💡 Hybrid Approach Concept

After a fixture is built using solid geometry (booleans, sections), raycast scanning provides point-by-point verification that booleans cannot easily provide. This is validation AFTER construction, not during.

1. Contact Validation

Verify part actually contacts blades where intended.

Ray origin: Part contact face centroid Ray direction: Face normal (toward blade) Expected: Hit blade within tolerance Checks: - Confirm contact points match design intent - Detect gaps or unexpected clearances - Verify part is seated correctly

2. Clearance Verification

Confirm non-contact faces don't interfere with blades.

Ray origin: Non-contact face sample points Ray direction: Toward nearest blade Expected: Distance > minimum clearance Checks: - Verify adequate gap at non-support areas - Detect unexpected interference - Confirm part can be loaded/unloaded

3. Weld Accessibility

Verify torch can reach all weld locations.

Ray origin: Weld bead endpoints Ray directions: Multiple angles (approach vectors) Expected: At least one clear path per weld Checks: - Clear line-of-sight for torch approach - Verify approach angle is feasible - Flag obstructed welds for review

4. Clamp Load Paths

Verify clamping forces transfer to support blades.

Ray origin: Clamp contact points Ray direction: Through part toward blade contacts Expected: Continuous load path exists Checks: - Part won't flex or pivot under clamp force - Load distributes to multiple blades - No unsupported cantilever regions

5. Gravity Stability

Confirm part is stable under gravity (3+ non-collinear contacts).

Ray origin: Part CoG region sample points Ray direction: -Z (gravity) Expected: 3+ contacts forming stable triangle Checks: - Part won't tip when released - Identify minimum stable contact set - Flag marginal stability conditions

6. Visual/Inspection Access

Verify critical features visible for QC inspection.

Ray origin: Inspection station position Ray direction: Toward critical feature Expected: Unobstructed line of sight Checks: - Can QC see critical features? - Weld inspection visibility - Dimension measurement access

7. Chip/Coolant Drainage

Verify chips and coolant drain clear during machining.

Ray origin: Pocket floor sample points Ray direction: -Z (gravity drain) Expected: Clear path to fixture base or drain Checks: - Chips won't accumulate in pockets - Coolant flow paths exist - No trapped debris areas

Implementation Strategy

Phase Components
Phase 1: Core Infrastructure fxRaycastPoint, fxRaycastGrid, fxRaycastFromFace
Phase 2: Analysis Modules fxValidateContacts, fxCheckClearances, fxAnalyzeWeldAccess, fxCheckStability
Phase 3: Integration Auto-run after fixture generation, pass/fail reports, visual markers, JSON/XML export

Hybrid Approach Benefits

Aspect Solid Boolean Raycast Hybrid Winner
Profile generation ✓ Fast, accurate ✗ Slow, sampling Boolean for build
Point-specific checks ✗ Overkill ✓ Precise Raycast for verify
Accessibility ✗ Can't check ✓ Line-of-sight Raycast
Performance Medium Depends on density Optimized per task

📦 Planned Deliverables

fxRaycastPoint.ovm - Single ray, returns hit point/distance/face

fxRaycastGrid.ovm - Grid of rays, returns hit array

fxValidateContacts.ovm - Contact validation report

fxAnalyzeWeldAccess.ovm - Weld accessibility report

fxCheckStability.ovm - Gravity stability analysis

POST_FIXTURE_RAYCAST_ANALYSIS.md - Full specification (exists)

🔀 Sheet-Based Blade Profile (Jan 4 Improvement)

🔧 Architectural Decision: Return Sheets Instead of Kurves

The fxBladeProfileIntersect macro now returns sheet bodies directly rather than converting back to kurves. This eliminates unnecessary conversion steps since sheets are ultimately thickened into solids anyway.

Workflow Change

OLD APPROACH: Part → Section → Wire → Kurve → Extrude (back to solid) ↑ Unnecessary conversion NEW APPROACH: Part → Section → Sheet → Thicken → Blade Solid ↓ Skip kurve step entirely

Sheet Union for Multiple Slices

When a blade slices through a part with gaps (multiple disjoint pieces), multiple sheet bodies result. These can be unioned directly:

sld mode vdm sld uni i_targetSheet i_toolSheetSet i_resultSet sld mode list Key insight: Sheet union works with consistent winding direction (all CW or all CCW from same viewing angle)
  • ✓ Sheet-based return from intersection
  • ✓ VDM-based sheet union
  • ◐ Handle multiple slice results
  • ○ Update caller functions for sheet input
  • ○ Test with complex multi-body parts

📦 Modified Files

fxBladeProfileIntersect.ovm - Now returns sheets

fxCreateBladeFromIntersect.ovm - Updated for sheet input

fxTestBladeFromIntersect.ovm - Test harness updated

🔮 Future Considerations

🌉 Auto-Bridge for Through-Holes (Bidirectional)

Smart bridging algorithm for blade profiles crossing through-holes. Instead of leaving a gap or fully capping, the blade rises/descends a configurable distance, traverses across, then returns.

THROUGH-HOLE BRIDGING OPTIONS POSITIVE BRIDGE (Fixture Support - blade goes UP through hole): Part floor Part floor ████████ ████████████████ │ hole │ ▼ ▼ ░░░░│ │░░░░░░░░░░░░░░░ ← Blade bottom │ ░░░░░░│ ← Bridge (X mm up) ░░░░│ │░░░░░░░░░░░░░░░ ← Blade continues NEGATIVE BRIDGE (Trim Application - blade goes DOWN into hole): Part floor Part floor ████████ ████████████████ │ hole │ ▼ ▼ ░░░░│ │░░░░░░░░░░░░░░░ ← Blade top │ ░░░░░░│ ← Bridge (X mm down) ░░░░│ │░░░░░░░░░░░░░░░ ← Blade continues │ ▼ Cut piece falls INTO hole LATERAL SHIFT OFFSET: ░░░░░░│◀─gap─▶│░░░░░░░░░░░░░░ ← Optional L/R clearance │ ░░░░░ │ for material to fall through ░░░░░░│◀─gap─▶│░░░░░░░░░░░░░░

Use Cases:

  • Positive (Fixture): Blade supports part from below, bridges over floor holes
  • Negative (Trim): 5/6-axis laser trim fixtures where cut scrap falls into blade cavity

Parameters:

  • w_bridgeHeight - Distance to rise/descend (mm)
  • i_bridgeDirection - +1 = up (fixture), -1 = down (trim)
  • w_lateralGap - Left/right clearance for material drop (mm)

📦 Deliverables

fxAutoBridge.ovm - bridge generation for through-holes

fxTrimFixture.ovm - 5/6-axis laser trim fixture mode

🌐 Cross-Platform Fixture Engine

Python core with thin CAD wrappers (SolidWorks C#, Inventor VB.NET). S-bend sheet steel option with FEA integration.

🔥 Weld Distortion Prediction

Calculate expansion/shrinkage from weld heat input. Topology-aware system to predict and compensate for thermal distortion.

📱 Zoho CRM Integration

Web API for fixture configuration, JSON/XML schema for data exchange.

🔐 Privacy-First AI Integration Architecture

For customers who cannot send proprietary solid models over the web, provide a local interrogation option that only transmits abstracted topology data.

📊 Angled Shelf Systems

Surface-normal aligned gussets for clamping along blade edges at non-perpendicular angles.

⚡ Weight-Reduced Blades

Cutout patterns for large blades to reduce material usage and fixture weight while maintaining rigidity.

🔖 Fold Tabs

Integrated folding tabs for blade assembly positioning and welding alignment.

⚡ Multi-Instance Processing Strategy

🆕 Added January 8, 2026 - When to Use Parallel Processing

The overhead of spawning PEPS instances + JSON/XML IPC + file-based communication is significant (5-15 seconds startup). Use this decision table to determine when multi-instance processing is worthwhile.

📊 Decision Matrix

Scenario Single Instance Multi-Instance Verdict
Single part, <20 blades 30-60 sec 45-60 sec (overhead wipes out gains) Single
Single part, 50+ blades 3-5 min 1.5-2 min (blades are independent) Maybe
Batch: 10+ parts queued 10× sequential time Near-parallel processing YES
Massive model (1000+ faces) 15-30 min Distribute face analysis YES
Quick validation/preview 10 sec 20 sec (overhead dominates) Single

✅ Sweet Spot for Multi-Instance

  • Batch jobs from web API/CRM - multiple parts queued, farm them out to waiting instances
  • Blade-parallel processing - if you have 40+ blades, each blade profile is independent work
  • Analysis phases - weld detection, reach study, raycast validation on separate instances

❌ NOT Worth It For

  • Interactive single-part workflow
  • Anything under ~2 minutes total
  • Operations that are inherently sequential (can't parallelize)

🔄 JSON vs XML Data Format

RECOMMENDED ARCHITECTURE External Input → [Converter Layer] → Internal XML → PEPS ↑ ↑ JSON or XML Existing parser works Web UI → JSON → API → Convert to XML → PEPS B2B Partner A → JSON → API → Convert to XML → PEPS B2B Partner B → XML → API → Pass through → PEPS

Recommendation: Support both formats. JSON primary (90% of modern integrations), XML for legacy enterprise. Keep existing PEPS XML parser, add thin JSON→XML converter at API boundary (~50 lines of code).

📦 Existing Infrastructure

@@rstart.ovm - Entry point, detects -x (XML) and -w (waiting mode) flags

fxRunBackgroundInstance.ovm - Orchestrator, spawns multiple PEPS instances

fxExecuteBackgroundTasks.ovm - Worker, loads XML and executes fixture generation

fxLogInstance.ovm - XML-based semaphore system for status/heartbeat

🧹 Error Cleanup System (PLANNED)

🆕 Added January 8, 2026 - Next Week Priority

Comprehensive cleanup mechanism for macro errors. When a macro fails mid-execution, leftover state (globals, VDM data, temporary bodies, layers) can cause subsequent runs to fail or behave unexpectedly.

🔄 Cleanup Scope

  • Global Variables - Reset fixture globals to safe defaults (i_FX_*, w_FX_*)
  • VDM Slots - Clear/release allocated VDM sets (progress state, blade data, etc.)
  • Temporary Bodies - Delete orphaned solids from interrupted operations
  • Scratch Layers - Clean up temporary layers (@@NucleoProgress, etc.)
  • Position Marks - Restore SLD PMK state if interrupted mid-checkpoint
  • Window State - Restore graphics window on/off state

📋 Implementation Approach

ERROR CLEANUP ARCHITECTURE ┌─────────────────────────────────────────────────────────┐ │ onerror handler (per macro) │ │ ↓ │ │ call fxErrorCleanup $_MACRO_NAME │ │ ↓ │ │ ┌─────────────────────────────────────────────────┐ │ │ │ fxErrorCleanup: │ │ │ │ • Reset i_FX_* globals to defaults │ │ │ │ • Clear VDM slots in known ranges │ │ │ │ • Delete bodies on temp layers │ │ │ │ • Restore window state │ │ │ │ • Log error context for debugging │ │ │ └─────────────────────────────────────────────────┘ │ │ ↓ │ │ Resume or exit gracefully │ └─────────────────────────────────────────────────────────┘
  • ○ Create fxErrorCleanup.ovm master cleanup macro
  • ○ Document all VDM slot allocations (create VDM_SLOTS.md)
  • ○ Add onerror handlers to critical macros
  • ○ Create fxResetGlobals.ovm for global variable reset
  • ○ Test cleanup with intentional mid-macro failures
  • ○ Add cleanup call to fxProgressUpdate on error paths

📦 Deliverables

fxErrorCleanup.ovm - Master cleanup utility

fxResetGlobals.ovm - Reset all fixture globals

VDM_SLOTS.md - Documentation of VDM slot allocations

🔬 Pre-Release Validation Process

🆕 Added January 8, 2026 - Mandatory Pre-Production Analysis

Before releasing production code for testing, ALL OVM macros must pass through the Python-based source code analysis system.

📊 Python OVM Source Interrogation

Automated analysis of OVM macro source files to detect common issues before production release.

PRE-RELEASE VALIDATION WORKFLOW ┌─────────────────────────────────────────────────────────┐ │ DEVELOPMENT COMPLETE │ │ ↓ │ │ Run Python OVM Analyzer │ │ ↓ │ │ ┌─────────────────────────────────────────────────┐ │ │ │ Checks Performed: │ │ │ │ • Variable declarations at top of macros │ │ │ │ • Local variables inside loops/conditionals │ │ │ │ • Extended ASCII characters (>127) │ │ │ │ • CRLF line endings │ │ │ │ • Undeclared variable usage │ │ │ │ • VDM open/close balance │ │ │ │ • Syntax pattern validation │ │ │ └─────────────────────────────────────────────────┘ │ │ ↓ │ │ PASS? ─── YES ──→ Release for Testing │ │ │ │ │ NO │ │ │ │ │ └──→ Fix Issues ──→ Re-analyze │ └─────────────────────────────────────────────────────────┘
  • ✓ Python analyzer script created
  • ✓ Variable declaration position checking
  • ✓ Loop/conditional scope analysis
  • ○ Integrate into release checklist
  • ○ Add to CI/CD pipeline (future)
  • ○ Generate HTML validation report

⚠️ MANDATORY GATE

No OVM code should be released for production testing without first passing the Python analysis. This catches common PEPS macro pitfalls that cause silent failures or hard-to-debug runtime errors.

📦 Deliverables

ovm_analyzer.py - Main analysis script

analyze_all_macros.bat - Batch runner for full codebase

validation_report.html - Generated analysis report

🎯 Priority Tasks (Next Sprint)

Priority Task Phase Notes
HIGH Pre-Release Python/OVM Analysis Validation Run Python analyzer on ALL production macros before testing release. Mandatory gate.
HIGH Offline Programming System (Weld Data Export) Phase 12+ Weld detection → torch vectors → CSV/JSON/XML → Nachi/OTC Daihen formats. Foundation for robot integration.
HIGH Weight & CoG Calculation New Foundation for stability analysis
HIGH Complete gravity offset arc-to-arc Phase 10 VDM-based vertex projection needed
HIGH Weld Detection System Phase 12 Required for robot reach study
MEDIUM Robot Reach Study New Kinematic-free accessibility analysis
MEDIUM Fix fxBladeFromSection transformation Phase 3 Use blade line rotation, not centroid math
MEDIUM Test Mode Framework Phase 6 Standardize testing approach
LOW Blade Orphan Detection Phase 7 Validation utility
LOW 3-Tier Architecture Design New API contracts and deployment options

⚠️ Known Pitfalls & Edge Cases

Thick Blade Edge Case

If blade thickness approaches pocket size, normal-based face selection may pick wrong faces. Need fallback to area calculation or bounding box comparison.

Transform Order for Rotations

Must follow: Translate to origin → Rotate → Translate back (T⁻¹·R·T). Wrong order causes geometry to orbit around world origin.

SLD Command Gotchas

  • sld sec CONSUMES the sheet - don't try to delete it after
  • sld tap requires i_ws_body_set global - local sets fail silently
  • No sld fac are command exists - use kurve conversion or normal filtering
  • VDM value parameters must be variables, not literals

Robot Reach Study Limitations

The reach study is NOT a kinematic simulation. It only checks distance from robot base to weld points. Does not account for joint limits, singularities, or collision avoidance.