What it opens

Extensions accepted: .nc, .src, .gcode, .tap, .ngc, .cnc and .txt. The extension only gets the file through the door; what happens next depends on what the program actually contains.

3-axis router g-code (viewing free in Core; editing is Pro)

• Motion: G0 rapids, G1 feeds, G2 and G3 arcs in both I/J and R form, in G17, G18 or G19 planes.
• Modes: G90 and G91 positioning, G20 and G21 units, G28 and G53 machine moves, F feed words, S and M codes recorded but not simulated.
• Posts seen working: Fusion 360 generic and vendor posts, Vectric VCarve and Aspire, Mach3 and Mach4, GRBL, LinuxCNC, Masso, and hand-written files.
• Drilling cycles: G81, G82, G83, G73, G85, G86 and G89 are drawn as the rapid to the R plane, the feed to depth and the retract (G98 to the initial plane, G99 to R), with Z and R modal between holes. Pecks and dwells are not drawn, and the viewer says so.
• Not handled: cutter compensation (G41/G42) is read but not applied, and subprogram calls are not expanded.

4-axis hotwire XYUV (Pro)

• Recognised by AxisNames=XYUV or towerDistance in the header, or U and V words on motion lines.
• Drawn as two tower paths plus the wire between them, and the ruled surface the wire sweeps.
• Header values used: tower distance sets the depth between towers; if it is missing, 1000 mm is assumed and the viewer says so.
• Posts seen working: DevFoam, Jedicut, GMFC, and the posts shipped with MegaPlot and Foamlinx style machines.

KUKA KRL (Pro)

• Motion: LIN, PTP, CIRC, SLIN, SPTP, SCIRC and SPL, with the _REL relative variants and C_DIS / C_PTP approximation flags.
• External axes: E1 as a linear track and E2 as a rotary turntable, read from every move. Switch between the part frame and a cell view where the table turns under the path.
• Speeds: $VEL.CP is tracked line by line, including values set through BAS(#VEL_CP, …), so the time estimate follows the program instead of averaging it.
• Joint-space PTP moves (A1 to A6 with no Cartesian target) cannot be drawn without the robot's kinematics. They are counted, reported in a warning, and the next Cartesian move restarts from its own position rather than guessing.
• Point variables: LIN XP1 style moves are resolved from the declarations in your program or in the .dat file beside it, which the viewer opens automatically. A variable it cannot find is named in a warning rather than silently skipped.
• Frames: $BASE set to a literal frame or a declared one such as BASE_DATA[2] transforms the path, so a program that switches base between operations still lines up. A base that comes from an external kinematic, EK(...), or from a config file the viewer cannot see is drawn as programmed and says so. $TOOL is recorded; it moves the tool centre point, not the programmed target, so the drawn path is unchanged.

FDM printer g-code (free in Core)

• Recognised by extrusion on motion lines together with a slicer name, layer marker or hotend temperature.
• Layer count, filament length and a per-layer slider, with travel and print moves coloured apart.
• Slicers seen working: PrusaSlicer, Cura, Orca, Bambu Studio, Slic3r, Simplify3D, IdeaMaker and SuperSlicer.

Encodings and line endings

Files are read as UTF-8 where possible and Windows-1252 otherwise, which is what controllers and older CAM posts produce. A saved file keeps the encoding, byte-order mark and line endings it arrived with, so a controller that rejects anything unfamiliar still accepts it afterwards.

If a file does not open properly

That is a bug, not a limitation. Send the program to [email protected] and it gets fixed, usually within a week. Files sent for that purpose are used to fix the parser and nothing else.