Selector Mapping Dossier

Executive State Board

The project has moved out of discovery mode. The core Flashforge block family is already known, the real truth file exists, and the new binary work says the first executable is likely only a launcher. The remaining effort is now precise: find or emulate the selector that picks the right concrete swap block at each toolchange.

Key Files And Folders

These are the concrete files and directories used in the current AD5X reverse-engineering pass. This section is here so the research page is operational, not just descriptive.

Active Comparison Files

These are the concrete test artifacts behind the current conclusions. If someone needs to repeat the same comparison, these are the first files to open.

Visual Model Of The Problem

Evidence Architecture

Decision Scorecard

Scores are pragmatic fit for AD5X/IFS support, not general slicer quality.

Latest Same-Cube G-code Result

We patched flashforge_162_OrcaCube_v2_AD5X_patched.3mf so both Flashforge-Orca 1.6.2 and vanilla OrcaSlicer 1.6.2 could slice the same two-part cube as AD5X/Klipper multi-material output. Both outputs now use the same visible AD5X profile and matching tool IDs, but the actual toolchange bodies are different.

generated by Orca-Flashforge 1.6.2
T0 = 26
T2 = 27
CP TOOLCHANGE START = 51
CP TOOLCHANGE UNLOAD = 52
CP TOOLCHANGE LOAD = 52
CP TOOLCHANGE WIPE = 52
Ramming start = 52
Cooling park = 52
SET_PRESSURE_ADVANCE ADVANCE=0 = 52
G1 E-55.3000 = 52
G1 E18.0000 = 52

generated by OrcaSlicer 1.6.2
T0 = 27
T2 = 25
CP TOOLCHANGE START = 50
CP TOOLCHANGE UNLOAD = 0
CP TOOLCHANGE LOAD = 0
Ramming start = 0
Cooling park = 0
SET_PRESSURE_ADVANCE ADVANCE=0 = 0
G1 E-55.3000 = 0
G1 E18.0000 = 0

Flashforge Toolchange Shape

; CP TOOLCHANGE START
; CP TOOLCHANGE UNLOAD
SET_PRESSURE_ADVANCE ADVANCE=0
; Ramming start
G1 E-15.0000 F6000
G1 E-55.3000 F5400
G1 E-15.8000 F2700
G1 E-7.9000 F1620
M104 S200
; Cooling
; Cooling park
; Ramming end
T0 / T2
; CP TOOLCHANGE LOAD
G1 E18.0000 F180
; CP TOOLCHANGE WIPE

Vanilla Toolchange Shape

; CP TOOLCHANGE START
M220 S100
T0 / T2
G4 S0
; CP TOOLCHANGE WIPE
; CP TOOLCHANGE END

Forensic Comparison Board

This board reduces the current finding to its operational core. Both slicers can be made to say “AD5X”, but only one emits the full swap sequence needed for a believable IFS workflow.

Four-Tool Stress Test

We repeated the comparison on a larger four-object, four-tool plate using the AD5X-patched vanilla project and a Flashforge-Orca export. This test is noisier than the same-cube comparison because tower placement was manually moved during one pass and then corrected later, so it should be treated as supporting evidence, not the cleanest reference pair.

generated by Orca-Flashforge 1.6.2
total filament change = 402
tool counts = T0:151 T1:127 T2:76 T3:52
CP TOOLCHANGE START = 403
CP TOOLCHANGE UNLOAD = 406
CP TOOLCHANGE LOAD = 406
Ramming start = 406
Cooling park = 406
SET_PRESSURE_ADVANCE ADVANCE=0 = 406

generated by OrcaSlicer 1.6.2
printer_model = Flashforge AD5X
printer_settings_id = Flashforge AD5X 0.4 nozzle
tool counts = T0:151 T1:125 T2:76 T3:50
CP TOOLCHANGE START = 401
CP TOOLCHANGE UNLOAD = 0
CP TOOLCHANGE LOAD = 0
Ramming start = 0
Cooling park = 0
SET_PRESSURE_ADVANCE ADVANCE=0 = 0

Representative 4-Tool Block Difference

Flashforge first block:
START -> WIPE_TOWER_START -> UNLOAD -> ramming -> cooling park -> T1 -> LOAD -> WIPE -> G92 E0 -> END

Vanilla first block:
START -> T1 -> WIPE -> G92 E0 -> END

Model Comparison Ledger

This table is the compact research log. It tracks which comparison was actually clean, what was held constant, what still differed, what interventions were tried, and where human setup choices introduced noise.

Swap Marker Matrix

This is the hard-count view across the main datasets. The point is simple: where Flashforge emits the deeper AD5X swap markers, vanilla Orca does not. The patched export case is included to show that those missing sections can be programmatically reintroduced, even if vanilla Orca does not natively emit them.

Truth Comparison: Real Flashforge Vs Patch v3

This is the first comparison against the actual Flashforge-Orca output for the exact 3-item / 4-filament print, not a proxy reference. It is the most important validation point in the document because it separates “close enough to look plausible” from “actually close to truth.”

CP TOOLCHANGE START = 492
CP TOOLCHANGE UNLOAD = 492
CP TOOLCHANGE LOAD = 491
CP TOOLCHANGE WIPE = 491
Ramming start = 492
Cooling park = 492
SET_PRESSURE_ADVANCE ADVANCE=0 = 492
first tool sequence = T3, T1, T0, T1, T2, T3, ...

CP TOOLCHANGE START = 492
CP TOOLCHANGE UNLOAD = 492
CP TOOLCHANGE LOAD = 492
CP TOOLCHANGE WIPE = 492
Ramming start = 492
Cooling park = 492
SET_PRESSURE_ADVANCE ADVANCE=0 = 492
first tool sequence = T1, T2, T3, T0, T1, T2, ...

Most Important Remaining Gap

v3 learned:
- the Flashforge swap-body phases
- the need for unload / ramming / cooling / load / wipe
- transition-shaped selection is better than simple tool matching

v3 still missed:
- the exact first transition ordering
- one real load/wipe omission present in truth
- the exact tower-coordinate context used by the real Flashforge slice

Binary Triage Update

A first real IDA pass on orca-flashforge.exe changed the reverse-engineering target in an important way. The executable looks more like a bootstrap/launcher layer than the place where the full AD5X swap selector necessarily lives.

x64 Windows GUI PE
entry point in .text
imports include:
LoadLibraryExW
GetProcAddress
GetModuleFileNameW
GetModuleHandleW
CreateWindowExW
GetMessageW
DispatchMessageW

key strings:
aOrcaSlicerDllW
aBambustuMain
aCouldNotLocate
aOrcaSlicerExe

Literal strings such as:
CP TOOLCHANGE
Ramming start
Cooling park
single_extruder_multi_material
purge_in_prime_tower

did not show up as normal loaded strings
in the first IDA strings pass on the EXE/DLL pair already tried.

Reading Of The Result

Inline Binary Evidence

These screenshots are local assets generated from the FireShot captures taken during the IDA and binary-inspection pass. They are included here so the launcher interpretation is visible inside the dossier instead of living only in chat history.

Capture 005: PE Overview

The first-pass executable inspection shows a normal x64 PE layout. This supported the initial conclusion that the file is inspectable and not obviously packed or opaque.

ghidra_re_tool_005.png

Capture 006: Imports and Layout

The import surface matters because it exposes LoadLibraryExW and GetProcAddress, which fit the launcher/bootstrap interpretation rather than a single self-contained slicer binary.

ghidra_re_tool_006.png

Capture 007: String-Level Clues

This is the important pivot: visible names like aOrcaSlicerDllW and aBambustuMain point to a downstream loaded module. That is why the next search target is the resolved DLL path and handoff function, not just WinMain.

ghidra_re_tool_007.png

IDA Graph: Loader Handoff Region

This capture is the first useful in-graph confirmation that the launcher is resolving bambustu_main while also carrying a nearby failure branch for OrcaSlicer.dll was not loaded. That is the handoff seam to keep following.

20260422_14h56m46s_grim.png

Launcher Proof Sequence

The later IDA passes moved this from inference to proof. We now have a clean visual sequence showing the launcher loading the slicer DLL, resolving bambustu_main, storing the function pointer, and then calling it indirectly on the success path. That is the exact seam between bootstrap code and the real slicer entry.

Cropped Step 1: Resolve DLL Entry

The launcher block at loc_1400055DC loads rdx = aBambustuMain, passes the module handle in rcx, calls GetProcAddress, stores the result into qword_14000C268, and branches to the success path at loc_140005606 only if the pointer is non-null.

loader_getproc_block.png

Cropped Step 2: Indirect Handoff

The success path at loc_140005606 performs the actual call into the DLL entry. The graph shows an indirect call rax after preparing a small argument value with lea ecx, [rdi-1]. This proves the launcher is transferring control into the function resolved from the DLL, not implementing the slicer core locally.

launcher_handoff_call_rax.png

Cropped Step 3: Data-Slot Detour

This detour matters because it explains one false start during analysis. Following qword_14000C268 by xref only lands on the write site. It does not by itself expose the later indirect call. That is why the success block had to be followed directly to prove the handoff.

qword_store_detour.png

Original Screenshot Links

DLL Entrypoint Trace

After proving the launcher handoff, the next job was to verify that the Flashforge DLL exposes a real application entry and to separate useful call-chain leads from low-value allocator noise. That work is now partially complete. The DLL does expose a Flashforge-specific entrypoint, and we have already ruled out at least two early helper branches as too low-level to be the AD5X swap selector.

Cropped Step 4: Real Flashforge DLL Entry

This graph confirms the exported entrypoint inside the Flashforge DLL is orca_flashforge_main. The function is not a trivial thunk. It allocates a large frame, initializes state, and immediately fans out into real helper calls.

orca_flashforge_main_graph.png

Cropped Step 5: Text View Confirmation

The text view is useful because it exposes the exact export label and confirms the entrypoint address directly. It also shows the first setup block before graph exploration, which helps distinguish real logic from folded function chunks or export-table confusion.

orca_flashforge_main_text.png

Cropped Step 6: Rejected Helper `sub_1800C6FD0`

This branch was followed because it appears early in the DLL entrypoint. The graph shows mostly null checks, size checks, allocator-style flow, and a path to invoke_watson. That is useful as elimination evidence, but not as the AD5X lead.

helper_sub_1800C6FD0.png

Cropped Step 7: Rejected Helper `sub_1800D37A0`

This function is larger, but still reads like low-level machinery: flag math, shifts, masks, bounds checks, and helper calls that look more like parser/container support than slicer semantics. It should not be the main reverse-engineering target.

helper_sub_1800D37A0.png

Original Export Discovery

This is the screenshot that changed the direction of the DLL work. It shows orca_flashforge_main in the export list and establishes a Flashforge-native symbol to trace instead of relying on stale upstream strings.

20260422_15h25m16s_grim.png

Original Search Failure

This screenshot is worth keeping because it documents a negative result: searching for bambu and similar text inside the Flashforge DLL did not provide a productive lead. That justifies the switch to entrypoint-led tracing.

20260422_15h25m06s_grim.png

Bootstrap Chain Narrowing

The newest IDA work moved the DLL phase forward in an important way. We are no longer just proving that orca_flashforge_main exists. We now have a clearer startup chain inside the Flashforge DLL itself, and several branches have been eliminated with enough confidence that they should be treated as dead ends in future sessions.

Cropped Step 8: `sub_180125CE0` And `orcaslicer_main`

This crop captures the transition from generic DLL entry to a higher-level bootstrap coordinator. The key signal is not the string itself, but the fact that sub_180125CE0 is the only caller using the aOrcaSlicerMain ; "orcaslicer_main" anchor. That makes it a real startup coordination point, not a random string hit.

sub_180125CE0_orcaslicer_main_xref.png

Cropped Step 9: `sub_1801BB100` Semantic Call Slice

This crop is the current best startup-chain view. Unlike the earlier allocator and parser helpers, sub_1801BB100 shows repeated object construction, state movement, and multi-argument coordinator calls such as sub_1801A3560. That makes it a better candidate zone for real subsystem setup than the rejected low-level helpers.

sub_1801BB100_text_view.png

Raw Screenshot Links For This Pass

Current State In One Sentence

We already have the Flashforge block family, we have proven the launcher-to-DLL handoff, and we now have a real narrowed DLL startup chain; the project is paused with the remaining unknown reduced to the exact selector inside that loaded slicer path that chooses the right concrete block instance at each swap point.

Semantic Config Hits

This is the first DLL evidence pass that moved beyond generic bootstrap and runtime scaffolding into recognizable printer and G-code semantics. The important shift is not that we found the final AD5X selector. The important shift is that we found string-owning regions that clearly belong to printer/profile/G-code configuration and multi-material gating.

Cropped Step 10: Custom Toolchange JSON Registration

This crop is the clearest ownership proof so far for Flashforge custom toolchange JSON handling. Inside sub_180204A30+F47, the function registers a config item with the exact trio we needed: Load custom G-code, Load custom G-code from json., and custom_gcode_toolchange.json. That proves the string is not a stray resource and gives us a real enclosing function to anchor later xref work against.

custom_gcode_toolchange_registration.png

Cropped Step 11: Multi-Material Plate Flag Region

This crop matters because it is no longer talking about generic files or menus. It is talking about the rule surface itself: allow_multi_materials_on_same_plate. The region also shows that the immediate helper below it is still container support, which is exactly why the report now distinguishes semantic string ownership from actual execution ownership.

allow_multi_materials_flag_region.png

Cropped Step 12: Printer / Filament Validation Region

This region contains the first printer-facing validation message cluster worth keeping in the report. It shows current_printer_name in a live code path, together with nearby helper calls used during validation and message construction. It sits closer to printer/profile enforcement than the earlier startup chain and should remain one of the top tracing targets.

current_printer_name_validation_region.png

Cropped Step 13: Modified G-code Reset Message

This crop is not as central as the custom-toolchange or printer-validation regions, but it is still useful. It shows a reset/status path containing allGcodes2Modified, which helps map where the Flashforge UI tracks G-code state changes and default resets. That may become relevant later if toolchange JSON edits are being normalized or reverted through the same settings layer.

all_gcodes_modified_reset_region.png

Cropped Step 14: Ghidra Semantic String Workflow

This crop captures the point where the reverse-engineering workflow finally stopped fighting startup noise and started using semantic anchors directly. The important lesson is procedural: search for the exact strings that already surfaced in IDA and the comparison notes, then jump from the string owner to the enclosing function. In practice, this is what moved the work away from giant bootstrap graphs and into configuration- and validation-owning regions.

ghidra_string_search_workflow.png

Text Export Inventory

Resume Checklist

A successor should be able to restart this project without re-reading every branch log. The checklist below is the shortest defensible path back into the work.

What Would Be Next If Resumed

If this project is resumed later, the next phase should stop trying to rediscover the existence of the swap body. That work is finished. The only high-value work left is to map the selector that chooses the right block instance for each real toolchange and to keep narrowing the real DLL call chain until the slicer-core ownership becomes obvious.

What We Do Not Need To Re-Prove

• Vanilla Orca does not natively emit the deeper AD5X swap body.
• Profile-only injection is not enough.
• Flashforge-style blocks can be reconstructed structurally.

What We Need To Learn Next

• Which enclosing function actually owns the current_printer_name and invalid filament_id validation strings at runtime, rather than only formatting them.
• Whether the allow_multi_materials_on_same_plate region is just configuration declaration or the actual gate that blocks/enables multi-material same-plate behavior.
• Whether custom_gcode_toolchange.json only registers a UI-facing import path or also connects to runtime toolchange override loading.
• Why the real file starts with a different first tool-transition ordering than v3.
• Why the real file has one fewer load/wipe than the patch.
• Whether tower Y/X anchor is the dominant selector after tool transition.
• Whether startup swaps and steady-state swaps are chosen from different internal block families.
• Which sub-chain under sub_180125CE0 and sub_1801BB100 first stops looking like bootstrap and starts looking like real slicer-core ownership.
• Whether sub_1801A3560 is only another setup wrapper or the first function on the path to meaningful slicer behavior.
• Where the Flashforge DLL path stops being generic application startup and starts becoming printer/profile/G-code-specific.

Next Clean Dataset

This section is now partly satisfied. We do have a simpler two-filament cube pair, and it is the current best reference for hook development. It still is not perfectly coordinate-aligned, so one more carefully untouched pair would still be useful if we want the cleanest possible geometric baseline.

Target Hook Contract

This is the current contract for an in-Orca patch or DLL hook. It describes what the patch must observe and what it must emit, based on the evidence already collected, without assuming we have found the exact compiled function yet.

Minimum Viable Hook Behavior

Observe:
current tool
next tool
tower geometry context
swap-related profile parameters

Emit:
START
UNLOAD
pressure-advance reset
ramming retract sequence
cooling / cooling park
tool switch
re-prime / load
wipe
G92 E0
END

Non-Negotiable Success Markers

• The patched vanilla output must contain Flashforge-style swap markers, not just AD5X header identity.
• The prime/wipe tower must remain physically coherent with the emitted swap coordinates.
• The clean two-filament pair should match Flashforge behavior before the hook is trusted on the four-tool stress case.
• If the patch only changes metadata or profile naming, it is not solving the real problem.

Newest Reverse-Engineering Update

We tested the stronger profile-port theory directly by injecting Flashforge AD5X profiles into the live roaming OrcaSlicer system profile store used by the Windows prefix. That made Orca recognize the AD5X profile family in a more realistic way, but it still did not generate Flashforge-style unload/load/ramming/cooling toolchange bodies.

Orca roaming system store:
AppData/Roaming/OrcaSlicer/system/Flashforge/

Injected values included:
cooling_tube_length = 5
cooling_tube_retraction = 91.5
extra_loading_move = -2
enable_filament_ramming = 1
single_extruder_multi_material_priming = 1
filament_loading_speed = 28
filament_unloading_speed = 90
filament_ramming_parameters = ...

New vanilla output still looked like:
; CP TOOLCHANGE START
M220 S100
T2
...
; CP TOOLCHANGE WIPE
; CP TOOLCHANGE END

Missing:
CP TOOLCHANGE UNLOAD
CP TOOLCHANGE LOAD
Ramming start
Cooling park
SET_PRESSURE_ADVANCE ADVANCE=0

Toolchanger Comparison Result

The built-in fdm_toolchanger_common path in Flashforge-Orca is useful as a reference for Orca's profile/template model, but it does not explain AD5X behavior. It is a normal multi-tool machine path with start-time purge logic. AD5X behaves like a different compiled path: single-nozzle multi-material with extra toolchange generation layered on top.

Useful profile/template path:
Custom/machine/fdm_toolchanger_common.json

But AD5X reference G-code still reports:
change_filament_gcode =
single_extruder_multi_material = 1

and nevertheless emits:
CP TOOLCHANGE UNLOAD
Ramming start
Cooling park
CP TOOLCHANGE LOAD

What The Current Evidence Rules Out

Failure Matrix

This is the current state after two passes: one pass on profile extraction and a second pass on same-model G-code evidence. The point is to show which theories are still alive and which ones are now weak.

Extracted Folder Map

IFS Behavior Pipeline

Why After-Slice Editing Is Weak For IFS

Known Portable Profile Pieces

Reference Commands

# Check whether AD5X process profiles force prime tower
rg -n '"enable_prime_tower"|"prime_volume"|"prime_tower_width"' extracted/process_ad5x

# Check AD5X machine tool-selection startup
rg -n '"single_extruder_multi_material"|"machine_start_gcode"|T\\[initial_no_support_extruder\\]' extracted/machine_ad5x

# Compare AD5X toolchange blocks in the latest same-cube G-code pair
rg -n 'CP TOOLCHANGE|Ramming start|Cooling park|SET_PRESSURE_ADVANCE|^T[0-9]' ../temp/flashforge_orca_cube_t1_t3.gcode ../temp/vanilla_orca_cube_t1_t3.gcode

# Compare official Orca and Flashforge-Orca filtered binary strings
less binary_clues/dll_multifilament_string_diff.txt