SolidCAM output looks dense the first time you open it, but it follows the same logic as any other CAM package. SolidCAM calculates the toolpath from your geometry and operations, then a post processor translates that toolpath into a specific dialect of G-code for your control. Once you know the order the post writes things in, a long program becomes a few repeating blocks you can read and check quickly.
Understanding the output is not about admiring the software’s work. It is about doing the one job the software cannot: confirming that the generated file is right for the part you actually clamped on the machine in front of you. That confirmation is a reading task, and it is well within reach once you know what to look for.
What SolidCAM actually produces
The file your machine runs is generated, not hand written. SolidCAM holds the operations and the post processor decides the formatting, the comments, and which codes appear. That is why the same job can post differently for a Fanuc control versus a Haas or a Siemens control. The SolidCAM site describes the CAM side, and the posted file is the bridge between that and the metal.
The practical takeaway is the same principle that applies whether you run SolidCAM, Mastercam, or any other package: you do not have to write the code, but you do have to read it. If you have ever wondered whether you need to know G-code when the CAM writes it, the answer is that reading and verifying is the non-optional part. The software is responsible for the math; you are responsible for the match between the file and reality.
Read the output in blocks
Every posted program has a skeleton: a safety start, a repeating tool block, and a program end. Read it as blocks, not as hundreds of separate lines. G-code is modal, meaning a command like G01 stays active until something changes it, which is why most lines look like bare coordinates after the first command in a block sets the mode.
| Block | Typical codes | What it does |
|---|---|---|
| Safety start | G90 G94 G17, G20 or G21 | Absolute mode, feed per minute, plane, inch or mm |
| Work offset | G54 to G59 | Selects the setup origin you touched off |
| Tool change | T M06 | Loads the tool for the next operation |
| Spindle and coolant | S M03, M08 | Spindle on at speed, coolant on |
| Length offset and approach | G43 H, G00 | Applies tool length offset, rapids in |
| Cutting moves | G01, G02, G03, F | Linear and arc feed moves |
| Retract | G28 or G53 | Returns an axis to a safe reference |
| Program end | M30 | Ends and rewinds |
SolidCAM also writes comments in parentheses that name operations and tools; the control ignores them, and they make excellent signposts when you scan the file. Reading the comments first gives you a map of the program before you read a single coordinate.
A plain-language read of a header
To make this concrete, here is how you would read the opening of a typical SolidCAM program, line by thought.
| Line | How you read it |
|---|---|
| (Profile, T1 - 10 endmill) | The next section is a profile with a 10 mm endmill, tool 1 |
| G90 G94 | Absolute coordinates, feed per minute |
| G21 | Millimeters |
| G54 | Work offset 1, the origin you set |
| T1 M06 | Change to tool 1 |
| S5000 M03 | Spindle clockwise at 5000 rpm |
| G43 H1 | Apply tool 1 length offset |
| G00 X-10. Y-10. | Rapid to the approach point |
| Z5. | Rapid to a safe height first |
| M08 | Coolant on |
| G01 Z-3. F250. | Feed to depth at 250 mm per minute |
If you can read those eleven lines, you can verify the most important part of any SolidCAM program: the units, the offset, the tool, the speed, and a safe approach before the first cut.
A note on iMachining and varied feeds
One thing that surprises people reading SolidCAM output is that the feedrates can change frequently within a single operation. SolidCAM’s iMachining technology, in particular, adjusts feeds and sometimes spindle speed continuously to keep the cutting load steady, so the posted code may show many different F values where a simpler toolpath would show one. This is normal and intentional. When you read such a section, you are seeing the software vary the feed to suit the changing engagement, not a series of errors. The same verification still applies: confirm the tool, the offsets, and the retracts, and let the varied feeds be.
The things to verify every time
Verifying a SolidCAM program means five concrete checks, each tied to a code you can scan for. Confirm the units, G20 or G21. Confirm the work offset, G54 through G59, against the part you touched off. Confirm each tool, its T, M06, and G43 H, against the carousel and your offset table. Confirm the spindle and feed values are sane. And read the first Z move and the retracts to be sure the tool clears your fixture. A reference such as the CNCCookbook code list is handy for any word you do not recognize, and the same careful read you would use for a Fusion 360 posted program works here.
Why the output differs by control
A frequent surprise is that the same SolidCAM job posts as different text for different machines. The post processor decides the formatting, so one machine may get G28 retracts and another G53, or one may format tool changes differently. The motion math is the same; the presentation changes. This is why a post built for one control should never be trusted blindly on another, and why reading each posted file on its own terms matters when your shop runs more than one machine. A program that ran perfectly on the Haas last week is not automatically safe on the Fanuc today, even for the identical part, so give every new posted file a fresh read.
The mistake to avoid
The common error is trusting a clean simulation. A backplot confirms the toolpath geometry, not your real fixture, tool stickout, or a work offset typed wrong at the control. Many crashes happen on programs that simulated perfectly, which is why a reading habit matters more than the preview.
| Mistake | What happens | The fix |
|---|---|---|
| Trusting the backplot | Clean sim, real crash | Read the header and first moves at the control |
| Wrong work offset | Cuts air or buries the tool | Confirm G54 matches your touched-off origin |
| Tool or offset mismatch | Wrong depth or wrong tool | Check T, M06, and G43 H against the setup |
| Units mismatch | Every move scaled wrong | Confirm G20 or G21 before the first run |
| Misreading varied feeds | Thinking iMachining feeds are errors | Recognize that varied feeds are intentional |
Scan the header, the first tool change, the work offset, and the first Z move every time before you press cycle start.
What the offsets in the output actually do
Two pieces of a SolidCAM program cause most of the confusion for newer readers, and both are about offsets. The work offset, G54 through G59, tells the machine where the part is by pointing at a stored origin you set during setup. If the program calls G54 but you touched off the part as G55, every coordinate is measured from the wrong place. The tool length offset, applied with G43 and an H number, tells the machine how long the tool is so Z lands correctly; each tool has its own value. Reading the output well means treating these two as the anchors of the whole program, because the cutting moves are only as correct as the origin and tool length they are measured against. When you verify a posted file, you are really checking that these anchors in the code match the anchors you set on the machine.
Prove the first part safely
Reading the file is the first verification, but the machine is the final one. Treat the first run as a test even after a careful read. Lower the rapid override, keep a hand near feed hold, and run the first part in single block so each move is confirmed before it happens. A dry run above the part removes any remaining doubt about the first plunge. Watching the first part come off correctly is what confirms that the toolpath, the post, and your real setup all agree. SolidCAM did the math, the post wrote the code, and your read plus a careful first run close the loop. None of this requires writing G-code, but all of it requires reading it with confidence.
Build the recognition that makes reading fast
Reading SolidCAM output quickly comes down to knowing the common codes cold. When G43, G54, M08, and G28 register instantly, you stop decoding and start verifying. That recognition is recall, and recall responds to short repeated practice.
The free G-Code Sprint app at GCodePractice.com runs 60-second rounds on the common G and M codes and repeats the ones you miss, so the words SolidCAM writes into every program become words you read at a glance. It is an educational practice tool for building that fluency, not a machine controller or a verifier, so always prove the program safely on your machine. Drill a few minutes a day, read every posted file in blocks, and SolidCAM output stops being intimidating. The same skill lets you hand-edit a posted file safely when a one-off change is needed.
Frequently asked questions
How do you read SolidCAM G-code output?
Read it in blocks rather than line by line. Use the parenthetical comments to find each operation, then follow the standard order: safety header, work offset, tool change, spindle and coolant, tool length offset, approach, cutting moves, retract, and M30. Confirm units and work offset before cutting. To read the codes at a glance, the free G-Code Sprint app at GCodePractice.com drills the common G and M codes in 60-second recall rounds.
Does SolidCAM write the G-code or does a post processor?
SolidCAM calculates the toolpath, and a post processor translates it into the final G-code for your specific control. That is why the same operation can post as different text for a Fanuc, Haas, or Siemens machine.
Why do feedrates change so much in SolidCAM output?
SolidCAM’s iMachining adjusts feeds, and sometimes speeds, continuously to keep the cutting load steady, so a single operation can show many F values. This is intentional, not an error. Verify the tools and offsets as usual and let the varied feeds be.
Can SolidCAM output be wrong?
The toolpath math is usually correct, but the output can still be wrong for your setup, such as a default work offset, a tool number that does not match the carousel, or a retract that does not clear the fixture. Reading and verifying the file is a required step.
What codes should I check first in a posted program?
Check the units (G20 or G21), the work offset (G54 to G59), the tool change and length offset (T, M06, G43 H), and the first retract (G28 or G53). Those decide whether the first move is safe.
Why does SolidCAM output look different on another machine?
Because the post processor controls the formatting, and a different post for a different control changes things like retract codes and tool-change style, even for the same toolpath. Read each posted file on its own terms rather than assuming it matches the last machine.