Blohm G-Code Syntax Highlighting

Syntax highlighting, semantic coloring, and live diagnostics for G-Code (ISO 6983 / Siemens SINUMERIK 840D sl / 828D), tailored to Blohm grinding cycles and the Blohm variable naming conventions.

Supported file extensions: .gcode · .nc · .cnc · .gc · .ngc · .txt · .mpf · .spf

Features

Syntax highlighting

• G / M commands — G0, G1, G41.1, M3, M30, …
• Siemens 840D cycles & commands — CYCLE832, POCKET3, TRANS, ROT, SCALE, MIRROR, MCALL, CALL, RET, STOPRE, MSG, SPOS, Pos/POSA, interrupt keywords (SETINT, PRIO, BLSYNC, LIFTFAST, CLRINT, …) and more.
• R-parameters — R1, R100, …
• Blohm variables — identifiers ending in _ (e.g. MyVar_), $-system variables (e.g. $AA_IW, $TC_DP1), and plain mixed-case globals.
• Comments — ; and ' line comments (semicolons inside (...) and "..." are not treated as comments).
• Function calls, DEF/DEFINE keywords, type keywords, labels, and the %_N_… program header.

Semantic (depth-based) coloring

Nesting levels are colorized by depth (5 cycling levels) for:

• IF / ELSE / ENDIF
• FOR / ENDFOR and WHILE / ENDWHILE
• Parentheses ( )
• Variable index brackets [ ] (e.g. $AN_CEC_STEP[N_LOOP1])

Diagnostics (error / warning squiggles)

Cross-file variable resolution

On workspace open, all DEF/GUD files (first line matching %_N_*_DEF) are pre-scanned so variables declared there — including commented-out DEF lines — are known globally and won't be flagged in other files. PROC parameter lists (including STRING[n]) are treated as local declarations. Matching is case-insensitive, and diagnostics refresh live when a DEF file is saved.

Hover documentation

Bilingual (DE/EN) hover tooltips sourced from the Siemens SINUMERIK 840D sl / 828D documentation for:

• G and M commands (including parameterized forms like M31=10)
• R parameters and OPTI1_[n] option bits
• $-variables (691+ BTSS parameters), with per-tool-type tables for $TC_* tool parameters
• Path methods (ASPLINE, CUT3DCC, SUPA, …) and TOFF / TOFFL / TOFFR

Editor integration

• Bracket-pair highlighting, auto-closing pairs, and surrounding pairs for ( ), [ ], and "…".

Extension settings

Directories whose .txt files are checked (linted) as G-Code. Paths may be absolute or relative to a workspace folder — the default content/Zyklen resolves against the VS Code working directory (workspace root). When the list is empty, all .txt files are checked. Files with unambiguous G-Code extensions (.mpf, .spf, .nc, .gcode, .cnc, .gc, .ngc) are always checked regardless of this setting. This affects only the VS Code editor — the lint:gcode CLI is controlled solely by its own --dir argument.

// .vscode/settings.json
{
  "blohmGCode.txtCheckPaths": ["content/Zyklen", "C:\\NC\\programs"]
}

CLI linter (CI / Azure DevOps)

A standalone command-line linter (out/cli.js) runs the same diagnostic checks in a pipeline:

npm run bundle:cli
node out/cli.js --dir <path> [--exclude "<glob>"]... [--fail-on-warnings]

• Scans a directory recursively for supported G-Code files.
• Resolves cross-file variables by pre-scanning DEF/GUD files first.
• Decodes UTF-16 LE (the SINUMERIK default), UTF-8, and UTF-8-with-BOM.
• In Azure DevOps (TF_BUILD=True), emits each finding as an ##vso[task.logissue] annotation and fails the stage on errors (or warnings with --fail-on-warnings).

Building & packaging

npm ci
npm run bundle      # bundle client + server + CLI into out/
npm run release     # produce a .vsix package