Autodesk Fusion 360 Quiz: G Code Generation
10 questions · exam conditions
0:00
G Code GenerationQuestion 1 of 10

A verified post maps Setup WCS Offset 1 to G54 and Setup WCS Offset 2 to G55. A fixture is touched off in the machine's G54 register, but the posted program begins machining from G55. Inspection shows that the Fusion setup has WCS Offset 2.

Which correction best preserves a reliable post-processing workflow?

Change the machine's active offset to G55 at runtime without altering the Fusion setup or reposting the program.
Change the setup WCS Offset to 1, regenerate the affected toolpaths if necessary, and post the program again.
Replace every occurrence of G55 with G54 in the exported file while leaving the source setup unchanged.
Move the model origin to the fixture location because posted work offsets are controlled only by model coordinates.
← Back to quizzes

Autodesk Fusion 360 Quiz

Autodesk Fusion 360 Quiz: G Code Generation

Practice G Code Generation in Autodesk Fusion 360 with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on G Code Generation, giving you a quick way to practice the rules, question types, and explanations that matter most for Autodesk Fusion 360.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A verified post maps Setup WCS Offset 1 to G54 and Setup WCS Offset 2 to G55. A fixture is touched off in the machine's G54 register, but the posted program begins machining from G55. Inspection shows that the Fusion setup has WCS Offset 2.

Which correction best preserves a reliable post-processing workflow?

  1. Change the machine's active offset to G55 at runtime without altering the Fusion setup or reposting the program.
  2. Change the setup WCS Offset to 1, regenerate the affected toolpaths if necessary, and post the program again. (correct answer)
  3. Replace every occurrence of G55 with G54 in the exported file while leaving the source setup unchanged.
  4. Move the model origin to the fixture location because posted work offsets are controlled only by model coordinates.
Explanation: When you see a question about post-processing and work coordinate systems (WCS) in Fusion 360, focus on where the source of truth lives. The post processor reads your Fusion setup's WCS Offset number and maps it to a machine register (like G54 or G55). That mapping must stay consistent from Fusion setup → post processor → machine register. Here, the fixture is touched off in G54 (WCS Offset 1), but the Fusion setup is configured as WCS Offset 2, which posts to G55. The fix is to correct the mismatch at its source: change the setup's WCS Offset to 1, regenerate any affected toolpaths, and repost. This ensures the posted G-code calls G54, matching exactly where the fixture was registered on the machine. That's why B is correct — it maintains integrity across the entire workflow rather than patching symptoms. A is tempting but dangerous. Switching the machine's active offset at runtime without reposting means you're relying on an undocumented manual workaround. If anyone reruns the job later, the mismatch is still lurking in the source file. C represents a classic "text-editing the G-code" trap. Manually replacing offsets in the posted file leaves the Fusion setup wrong, so every future post will reproduce the error. Hand-editing G-code for workflow issues is fragile and error-prone. D is simply incorrect. Work offsets in Fusion are controlled by the setup's WCS Offset property, not by where the model origin sits in the design space. As a study habit, remember: always trace CNC errors back to the Fusion setup first, then repost. Never patch the G-code file when the root cause is upstream.

Question 2

A post emits G28 G91 Z0 between operations. On the target controller, the machine's reference-return behavior makes this retract undesirable. The controller supports nonmodal machine-coordinate positioning with G53, and the validated post provides a Safe Retracts property with G28 and G53 options.

What is the best way to change the generated retract behavior?

  1. Increase each operation's feed height so the controller interprets the existing G28 block as a G53 move.
  2. Delete the G28 blocks after posting and rely on the next operation's linking moves for collision avoidance.
  3. Change the setup work offset because reference-return commands are calculated from the active work coordinate system.
  4. Select G53 in the post's Safe Retracts property, repost, and verify the resulting machine-coordinate moves. (correct answer)
Explanation: When a post processor exposes a configurable property like Safe Retracts, that property is precisely the intended mechanism for changing retract behavior — no manual editing, workarounds, or setup changes are needed. Fusion 360's validated posts are designed so you modify behavior through properties first, repost, then verify output. That workflow is being tested here. Selecting G53 in the Safe Retracts property (choice D) instructs the post to replace G28 G91 Z0 blocks with G53-based machine-coordinate moves. You then repost to regenerate clean NC code and verify the output confirms the correct retract syntax. This is the correct, maintainable workflow — one change propagates to every operation automatically. Choice A is a misconception: feed height affects linking move clearance planes, not how the post interprets retract commands. G28 will still be emitted regardless of how high you set the feed height. Choice B is dangerous. Manually deleting G28 blocks after posting creates a manual, error-prone process you must repeat every time you repost. It also removes the retract entirely rather than replacing it with a safe alternative, creating real collision risk. Choice C misunderstands how reference-return works. G28 commands the machine to move to its fixed reference (home) position — this is independent of the active work coordinate system offset. Changing the work offset does nothing to affect reference-return behavior. Study tip: On Fusion 360 exam questions, when the passage explicitly mentions a post property that matches your goal (Safe Retracts → G53), that property is almost always the correct solution. Always exhaust post-level configuration options before considering manual edits.

Question 3

Every program for a particular machine requires a builder-specific clamp command immediately after each automatic tool change. A programmer currently inserts the command manually into each exported NC file, but programs are reposted frequently after toolpath revisions.

Which solution provides the most reliable long-term workflow?

  1. Store one manually edited NC file and paste revised cutting blocks into it after every later post-processing operation.
  2. Add the clamp command as an operation comment because comments are executed as machine commands by most controllers.
  3. Rename the generic post file to the machine's name so Fusion automatically adds the builder-specific command.
  4. Create and validate a controlled copy of the post that outputs the clamp command in the tool-change sequence. (correct answer)
Explanation: When you see a question about managing machine-specific output in Fusion 360, think about sustainability and automation. The real issue isn't just solving the problem once — it's solving it in a way that doesn't break every time the program changes. A custom post processor is Fusion 360's built-in mechanism for controlling exactly what gets written to NC output. By duplicating the generic post, adding the clamp command to the tool-change event handler, and validating it against the machine, you create a solution that fires automatically every time you post — regardless of how many times toolpaths are revised. That's why D is the correct answer: it removes the manual step entirely and ties the fix to the process, not the output file. A is a maintenance trap. Manually pasting revised cutting blocks into a "master" file introduces human error on every iteration and becomes exponentially harder to manage as programs grow in complexity. B misrepresents how CNC controllers work — operation comments in Fusion 360 are written as parenthetical remarks (e.g., (comment text)), which most controllers treat as non-executable annotations, not machine commands. Relying on this would silently skip the clamp command on the machine. C reflects a common misconception: renaming a post file changes how it appears in Fusion's machine library, but Fusion has no mechanism that magically injects builder-specific commands based on a filename alone. A good study strategy here: on post-processor questions, always ask "where in the workflow does this change live?" Changes that live inside the post are permanent and automatic; changes made to exported files are fragile and manual.

Question 4

A circular pocket toolpath is valid in Fusion. The current post outputs circular moves with center-offset words such as I and J, but the target controller accepts circular interpolation only in the required situations using radius-format R blocks. The controller alarms on the posted arcs.

Which action most directly addresses the cause of the alarm?

  1. Use or configure a compatible post to output the controller's supported arc format, then repost and verify the arcs. (correct answer)
  2. Tighten the CAM toolpath tolerance because a smaller tolerance automatically changes I and J arcs into R arcs.
  3. Change the setup WCS orientation because the selected work offset determines whether arcs use center or radius format.
  4. Edit each I and J word into an R word without recalculating the corresponding radius and arc direction.
Explanation: When a posted NC file causes controller alarms, your first instinct should be to trace the problem back to its source: the post processor. Post processors are the translators between Fusion 360's internal toolpath data and the specific dialect of G-code a controller understands. Different controllers support different arc interpolation formats — some expect center-offset words (I, J, K), others require radius-format R words, and some accept both. When there's a mismatch, the controller alarms because it literally cannot parse the instruction. Option A is correct because it targets the actual root cause. Configuring or swapping to a compatible post processor — one that outputs R-format arcs — resolves the mismatch at the generation stage. After reposting, you verify the output contains valid R blocks before sending it to the machine. This is the professional, repeatable fix. Option B is wrong because toolpath tolerance controls how closely the toolpath approximates curved geometry — it has absolutely no effect on which arc format the post outputs. Tightening tolerance might change arc segment counts, but I/J versus R is purely a post processor decision. Option C is wrong because WCS orientation determines coordinate system alignment and which work offset register is used. It has no bearing on how arcs are mathematically represented in the output code. Option D is wrong and potentially dangerous. Manually swapping I/J for R without recalculating the correct radius value produces geometrically incorrect or invalid arcs — you could crash the machine or cut the wrong shape. For the exam, remember: arc format = post processor responsibility. Any G-code output format question should lead you straight to the post processor as the solution.

Question 5

A controller requires the internal program identifier to appear as O followed by four digits. An operator renames the exported file from bracket.nc to 0125.nc, but the first program block still contains O0007, which came from the Fusion NC Program settings.

How should the internal identifier be corrected while maintaining consistency with future reposts?

  1. Rename the output file to O0125.nc because the controller derives the internal O identifier from the filename at load time.
  2. Set the appropriate program name or number to 0125 in the NC Program, then repost with the validated post. (correct answer)
  3. Rename the Fusion setup to O0125 because setup names always replace program identifiers in the posted header.
  4. Add O0125 as an operation comment because the controller uses the first matching text anywhere in the file.
Explanation: When working with Fusion 360 NC Programs, it's important to distinguish between two separate identifiers: the output filename (what the file is called on disk) and the internal program identifier (the O number embedded in the G-code itself). Controllers that require an O number read it directly from the program header, not from the filename — so renaming a file never changes what the controller sees inside. The correct approach is B: open the NC Program settings in Fusion 360, set the program name/number field to 0125, then repost using the validated post processor. This writes O0125 directly into the program header, ensuring the internal identifier and the filename stay synchronized automatically for every future repost. A is wrong because most CNC controllers parse the O word from the first block of the G-code file itself — they do not derive it from the filename on a USB drive or network share. Renaming the file leaves O0007 untouched inside the code. C is wrong because the Fusion setup name controls things like WCS or operation grouping, not the NC program's output header; setup names do not automatically replace the program number in the posted G-code. D is wrong because controllers look for the O word specifically in the first program block — they do not scan the entire file for matching text in comments, and an operation comment has no effect on the program identifier. A useful habit: whenever you see a mismatch between a filename and an internal identifier, go to the NC Program settings first — that's the authoritative source for what gets posted into the header.

Question 6

A part was modeled and programmed using inch document units. The target machine accepts only metric programs. A metric-capable post is selected, and the output begins with G21; a one-inch linear move is output as approximately X25.4.

Which interpretation of the posted result is most accurate?

  1. The post converted coordinates and feeds to metric output, so the model and CAM geometry should not be manually rescaled. (correct answer)
  2. The model must still be scaled by 25.4 because G21 changes only feed-rate interpretation, not coordinate values.
  3. The output is incorrect because a post processor cannot generate units different from the Fusion document units.
  4. The coordinate conversion is valid, but all tool diameters must be manually multiplied before the program is posted again.
Explanation: When a question involves post processors and unit conversion in Fusion 360 CAM, focus on what the post processor actually does: it translates the internal CAM data into machine-ready G-code, including handling unit conversions entirely on its own. A metric-capable post processor outputs G21 (metric mode) and automatically converts all coordinate values from inches to millimeters. So a one-inch move correctly becomes X25.4 — that's simply 1×25.4=25.4 mm1 \times 25.4 = 25.4\text{ mm}. The model geometry and CAM toolpaths stay exactly as programmed in inches; only the output changes. This makes A correct: because the post handles everything, you should not manually rescale the model or CAM geometry. Doing so would actually corrupt your part dimensions. B is wrong because it misunderstands what G21 does. G21 doesn't just change feed-rate interpretation — it signals the controller to interpret all coordinates as millimeters. Combined with the post's coordinate conversion, the output values are already in metric. No additional scaling is needed. C is wrong because it states a false limitation. Post processors absolutely can output units different from the Fusion document units — that's one of their core functions. A metric-capable post is specifically designed for this scenario. D is wrong because tool diameter data is also handled by the post processor during translation. There's no manual multiplication required; the post converts all relevant numerical values consistently. As a study tip, remember that in Fusion 360 CAM, the post processor is the final translation layer — it owns unit conversion completely. If the post is correctly configured, trust its output and never manually scale geometry to compensate.

Question 7

A simultaneous five-axis toolpath simulates correctly using a machine definition with two rotary axes. When it is posted with a generic three-axis post, the post reports unsupported tool orientation and does not create usable rotary-axis motion.

What is required to generate appropriate G-code for the target five-axis machine?

  1. Suppress the machine definition because five-axis rotary coordinates are derived only from the model's global origin.
  2. Post the toolpath as three-axis code because the controller reconstructs missing rotary motion from tool orientation comments.
  3. Use a post and machine configuration that represent the target controller syntax and rotary-axis kinematics. (correct answer)
  4. Increase the toolpath tolerance because a finer tolerance enables a three-axis post to calculate two additional axes.
Explanation: When working with multi-axis machining in Fusion 360, you need to understand that G-code generation depends on two tightly coupled components: the post processor and the machine configuration. The post processor translates toolpath data into controller-specific syntax, while the machine configuration defines the physical kinematics — how rotary axes are arranged, their pivot distances, and how they interact. Neither component works correctly in isolation for five-axis work. A post processor written for five-axis machines knows how to calculate the rotary axis commands (typically A/B or A/C axis combinations) from the tool orientation vectors that Fusion 360 computes internally. A generic three-axis post simply has no logic to handle those orientation vectors — it either ignores them or throws an error, which is exactly what the passage describes. This is why C is correct: you must match both the post processor and the machine configuration to your target controller and its rotary-axis kinematics. A is wrong because the machine definition is essential, not something to suppress — it provides the kinematic model that the post uses to compute rotary positions. B is wrong because no controller "reconstructs" rotary motion from comments in the G-code; that's not a real capability of CNC controllers. Comments are informational only. D is wrong because toolpath tolerance controls path accuracy and has absolutely no relationship to how many axes a post processor can output — tightening tolerance cannot conjure rotary-axis output from a three-axis post. As a study tip, remember this pairing rule: five-axis toolpath = five-axis post + matching machine definition. If either is missing or mismatched, your G-code will fail at the machine.

Question 8

A setup contains four operations in this order: Face, Adaptive, Drill, and Contour. Adaptive is suppressed. An NC Program is configured to include only Face, Adaptive, and Contour; Drill is not included in the NC Program selection.

Assuming the post completes normally, which operations should be represented in the generated G-code?

  1. Face, Drill, and Contour, because suppressed operations are replaced by the next enabled operation in the setup.
  2. Face, Adaptive, and Contour, because inclusion in the NC Program overrides an operation's suppressed state.
  3. Face and Contour only, because Adaptive is suppressed and Drill is outside the NC Program selection. (correct answer)
  4. All four operations, because posting an NC Program automatically processes the complete parent setup in browser order.
Explanation: When working with NC Programs in Fusion 360, you need to track two independent filters that determine which operations end up in generated G-code: the operation's suppressed state, and whether it's included in the NC Program's selection. Both conditions must be satisfied for an operation to appear in output. In this scenario, Adaptive is suppressed — meaning Fusion 360 treats it as disabled and skips it entirely during posting, regardless of any other settings. Drill, while active, was never added to the NC Program's operation selection. Since the NC Program only processes operations explicitly included in its list, Drill is simply invisible to it. Face and Contour are both active (not suppressed) and included in the NC Program selection, so they alone make it into the G-code. That confirms C as the correct answer. Choice A is wrong because suppression doesn't trigger any "replacement" behavior — there's no cascading logic that promotes the next enabled operation. Choice B represents a common and tempting misconception: being listed in an NC Program does not override suppression. Suppression happens at a lower level; the NC Program never even evaluates a suppressed operation. Choice D is wrong because NC Programs don't automatically pull in the full parent setup — they output only what's explicitly selected, and even then, only what's active. A useful rule of thumb: think of suppression and NC Program inclusion as two gates in series. An operation must pass both to appear in G-code. If either gate is closed, the operation is excluded, full stop.

Question 9

A three-axis milling toolpath simulates correctly in Fusion. The shop has a post processor for a machine with the same travel limits and controller family as the target machine, but the two machines use different M-codes for tool clamping and coolant control.

What is the most appropriate approach before generating production G-code for the target machine?

  1. Use the existing post because matching controller families ensure that machine-specific M-codes are translated automatically.
  2. Post with the existing file, then use a text editor to replace the clamping and coolant codes in each program.
  3. Use or validate a post configured for the target machine's controller options and machine-specific auxiliary functions. (correct answer)
  4. Modify the Fusion machine travel limits because the machine definition determines all M-codes written during posting.
Explanation: When working with CAM post processors in Fusion 360, remember that a post processor is not just a generic translator — it's a machine-specific configuration file that controls exactly which G-codes, M-codes, and auxiliary commands get written into your output program. The "controller family" determines the general syntax and cycle structures, but individual M-codes for functions like tool clamping, coolant valves, and spindle locks are defined within the specific post configuration for that machine. This is why C is correct. Even if two machines share the same controller family, their auxiliary functions can differ significantly. You need a post that has been explicitly configured — or at minimum validated — for your target machine's specific M-code assignments. Using or confirming a properly configured post ensures the output matches what your machine expects, preventing crashes or unintended behavior on the shop floor. A is wrong because controller family compatibility does not automatically translate machine-specific M-codes. The post processor must be explicitly written with those codes — they don't get "remapped" during posting just because the families are similar. B might seem pragmatic, but manually editing G-code with a text editor across production programs introduces human error and is not a scalable or safe practice — it's exactly the kind of risk that proper post processor management is meant to eliminate. D is incorrect because machine travel limits in the Fusion machine definition affect simulation boundaries and safety checks, not the M-codes the post processor writes. As a study tip: on post processor questions, always ask yourself whether the proposed solution addresses the specific layer of the problem — controller syntax, machine-specific codes, and simulation are separate concerns in Fusion's CAM workflow.

Question 10

While posting a toolpath that requests through-tool coolant, Fusion reports: Through-tool coolant is unsupported; using flood coolant. The post still creates an NC file, and the toolpath simulation shows no collisions. The machining process requires through-tool coolant to evacuate chips from a deep hole.

What should be done before the program is released to the machine?

  1. Release the file because successful NC-file creation means the substituted coolant mode is functionally equivalent.
  2. Resolve the coolant mapping with a suitable post or post configuration, then repost and review the affected code. (correct answer)
  3. Reduce the drilling feed rate because a lower feed causes the post to restore through-tool coolant automatically.
  4. Ignore the warning after simulation because Fusion simulation validates the machine's physical coolant delivery system.
Explanation: When working with CAM post processors in Fusion 360, you need to understand that a post warning about an unsupported feature is not a cosmetic message — it signals that the NC output no longer matches your machining intent. The post processor is essentially telling you it silently substituted something different into the code, which requires your direct intervention before the program reaches the machine. The correct path forward is B: resolve the coolant mapping by selecting a post processor that supports through-tool coolant (or editing the post configuration to enable it), repost the operation, and verify the resulting G-code contains the correct coolant commands. Through-tool coolant in deep-hole drilling isn't a preference — it's a functional requirement for chip evacuation. Running the program with flood coolant instead risks chip packing, tool breakage, and scrapped parts. A is wrong because successful NC-file creation only confirms the file is syntactically valid — it says nothing about whether the substituted coolant mode meets your process requirements. "It posted" ≠ "it's correct." C is wrong because feed rate and coolant delivery are independent parameters. No feed rate value triggers a post processor to restore an unsupported coolant mode; that's not how post logic works. D is wrong because Fusion's toolpath simulation validates geometry and collision avoidance — it does not model or validate the machine's physical coolant plumbing, pressure, or delivery system. Study tip: On post-processing questions, treat any warning about a substituted or unsupported feature as a blocker, not a suggestion. Always trace the warning back to the G-code and confirm the output matches your process requirements before release.