Tool path disappears

7 views
Skip to first unread message

Ezh Ezhovski

unread,
Jan 30, 2026, 3:32:48 AMJan 30
to CAMotics Users
I have a g-code file.   Cutting a sorta bowl shape.  Moving left-right (x), then stepping up (y) and vary in z as it goes. At a certain z depth, the tool path does not display.  (it's within the workpiece bounds.)   If I slow it down, I can watch the movements, and it's moving as expected.   But the tool patch shows a gap.

Any suggestions?

Thanks
HF top cradle fine.nc

Ezh Ezhovski

unread,
Jan 30, 2026, 11:35:25 PMJan 30
to CAMotics Users

OK ... I found it.  Somehow I had the wrong "view".

Attila Szazvai

unread,
Jan 31, 2026, 4:56:48 PMJan 31
to CAMotics Users

Subject: CAMotics fails to load NC + no stock unless project & paths meet strict conditions (ASCII-only) — initial console shows inf,inf,inf

Hi everyone,

After struggling with CAMotics showing no toolpaths — and at first not even the stock — I finally identified the root cause and a reliable workaround. I noticed many posts with similar symptoms but without a clear explanation, so I’m sharing what actually fixes the problem.

Important: Initially, the console showed:

Computing surface bounded by ((inf,inf,inf), (inf,inf,inf)) at 1 grid resolution Time: 0.00 secs Triangles: 0 Triangles/sec: -nan(ind)

This means CAMotics had no valid stock bounds and generated no mesh at all. After setting stock manually, the console began reporting finite bounds and triangles — but the toolpath still didn’t appear until I addressed path/encoding issues (see below).


Symptoms (two stages)

Stage A (before manual stock):

  • No stock, no toolpath
  • Console: Computing surface bounded by ((inf,inf,inf), (inf,inf,inf)) ... Time: 0.00 secs Triangles: 0

Stage B (after manual stock but before fixing paths/encoding):

  • Stock becomes visible (finite bounds, Triangles > 0)
  • Still no toolpath at all
  • Console shows only the stock computation, never: Loading NC file: Parsed commands: Tool Path bounds:

This indicates CAMotics did not load the NC file, even though the program looks “fine”.


Root cause

CAMotics is very sensitive to project/file paths and character encoding. Several conditions must be satisfied, otherwise the NC file won’t load (and no error is shown). Automatic stock can also fail, producing inf bounds.


Working conditions (ALL must be satisfied)
  1. Save the CAMotics project (.camotics) BEFORE adding the NC file.
    Adding NC to an unsaved project can silently fail.

  2. Put the .camotics project and the .nc file in the SAME folder.
    External/absolute paths often fail to resolve later.

  3. Use ASCII‑only folder paths and filenames.

    • No accented characters (á, é, ö, ü, ő, ű, ñ, ç, etc.)
    • No non‑English characters; avoid spaces + accents
    • Even a non‑ASCII Windows username in the path can break NC loading
  4. Define stock manually.
    Auto stock can yield invalid bounding boxes (inf,inf,inf) and zero triangles.


Verified fix / workflow
  1. Create a folder with ASCII‑only name
  2. Put both the .camotics project and .nc file into that folder
  3. Open CAMotics and save the project first
  4. Set stock manually (X/Y/Z and top Z origin)
  5. Add NC file
  6. Save the project again
  7. Re‑open the project
  8. Toolpaths appear normally

This process is repeatable and works 100% of the time on my systems.


Why this matters

Since CAMotics does not show an error when NC loading fails, users can waste hours debugging G‑code, GPU/OpenGL, or CAM settings. In reality, it’s a combination of path encoding and project/stock pitfalls.

Suggested dev improvements:

  • Proper UTF‑8/Unicode path handling in the project loader
  • Clear error if an NC file cannot be opened
  • Warn when auto‑stock yields invalid (inf) bounds

Tested on CAMotics 1.2.0 (Windows 10/11). I can provide a minimal test case if needed.

Hope this helps others hitting the same issue!

Best regards,

Reply all
Reply to author
Forward
0 new messages