Table of Contents

PostExecutionCommand Panel (Post-Execution)

The key model is PostExecutionCommand, labelled Post-Execution. It is the Output category's first catalog entry, and it carries five outputs derived from what the session has played: step files, shot files, optimization files, a CL → NC writeback, and a geometry-difference detection.

When It Runs, and What It Covers

Post-Execution is an ordinary entry in the command list, not an end-of-run hook. Its name describes what it consumes, not a fixed position: the list runs its entries in order and skips any whose Enable box is clear, and everything this command writes is derived from what the session has played so far.

That makes its placement the whole question. Put it after two program entries and it writes both. Put a second one halfway down the list and it writes an interim snapshot of the same accumulating state. The CL → NC writeback says this outright in the panel — place the CL-playing Program File command before this command — and it re-serializes every control file the session played, so an NC play is written back too. Read this together with General Config, the other half of the pair: those settings apply from their position forward, these outputs cover everything up to this position.

The command sits anywhere in the list, like any other; nothing pins it to the end.

The step and shot writers report on the session's shell sink. Each file opened is announced as Creating file[…] (StepFile-Create--Start, ShotFile-Create--Start) between the writer's starts and finished, with the path the template expanded to. A writer that opened no file — nothing had played above the command, or nothing that played was a machining step from a program — does not report finished: it ends on the system warning StepFile-Write--NoFile or ShotFile-Write--NoFile, which counts the positions the step strip held, much as the difference reports Diff--Built only for a comparison it built. What the writers walk is the session's strip, not the latest run's: a run started without a Reset plays on top of the one before it, and the command walks the earlier play's steps along with the new ones. Each file is opened afresh — truncated — whenever the strip turns to its program from another one, so a lone program played twice keeps both plays in its file, while in a mission of several programs each file keeps the later play alone.

Run executes the enabled outputs in an order of its own, which is not the order the tree and the list below show them in: shot files, then step files, then optimization, then the CL → NC writeback, then the geometry difference. Output timestamps follow that order rather than the layout. The outputs run one after another with no pace point between them, so they all come from one state of the session: the run's Pause takes effect at the run's next pace point after them — after the first action a later row hands the player (a row that hands it none, such as NC Optimization Config, a Script that plays nothing or Record Meshed Geometry set to No Action, runs whole first), or inside a later Script's play — and not at all when no pace point follows: as the mission's last row, where a new project puts it, the badge reads paused while the outputs run on, and the run then finishes. A step-physics recompute requested meanwhile waits for that same pace point — the end of the run when none follows — or is withdrawn if that comes too late. Its Stop during one output ends the run before the next — an optimization the Stop cut short is followed by none of them.

Layout

Every output is a section child node of the command, and each section's enable flag is that node's own tree checkbox. The command node itself carries only two captions: the first says that its outputs cover only what the commands above it have played by the time it runs, the second that each output lives on a child node switched on by its checkbox; the section panels hold the template and numeric fields, which stay editable whether or not the output is switched on — the flag decides what runs, not what can be edited.

  • Step Files Output Section
    • The node's checkbox is EnableWriteStepFiles.
    • Step File Template Field
      • The model is StepFileTemplate.
      • Default value: Output/[NcName].step.csv, which is also the field's placeholder.
      • A path relative to the project folder; an absolute path is used as it is. [NcName] is replaced by the source program's file name, extension kept, and [NcFile] by its project-relative path with each / turned into -. One file is written per source program, opened afresh — truncated — each time the steps turn to it from another program, so a template with neither placeholder names one file and keeps only the last program's stretch. The field's hint gives the base folder, the [NcName] substitution and the one file per program.
    • Writes the step-series data of what the session has played.
  • Shot Files Output Section
    • The node's checkbox is EnableWriteShotFiles.
    • Shot File Template Field
      • The model is ShotFileTemplate.
      • Default value: Output/[NcName].shot.csv, which is also the field's placeholder.
      • Resolved as the step template is, and carries the same hint.
    • Shot File Time Resolution Number Field (ms)
      • The model is ShotFileTimeResolution_ms.
      • Default value: 1
      • This sampling period — not the machining resolution — sets the accuracy ceiling of the time-series data, and a fine period produces a large file: a six-cut program writes about 13 MB at 1 ms and about 128 MB at 0.1 ms.
  • Optimization Output Section
    • The node's checkbox is EnableOptimizeToFiles.
    • Optimization File Template Field
      • The model is OptimizationFileTemplate.
      • Default value: Output/Opt-[NcName], which is also the field's placeholder; the field carries the same hint as the step template.
    • The SoftNc pipeline runs when the SoftNc runner is on and the session holds played syntax layers; otherwise the HardNc path runs. Both clear every cutter's optimization-limit cache first.
  • CL → NC Writeback Section
    • The node's checkbox is EnableConvertClToNcFiles.
    • NC Output Template Field
      • The model is ClToNcFileTemplate.
      • Default value: Output/[NcName].nc
      • Its hint states the substitution: [NcName] is replaced by the source file name, extension kept.
    • A caption below the field explains the synthesis: the MSYS frame becomes a G68.2 tilted working plane, tool posture becomes G43.4 RTCP with rotary words, and motions become G00/G01/G02/G03. The CL must have been played on an XYZABC machine chain first. The converted files appear as → file.nc nodes on the Execution Program branch, with source ⇄ output line jumps.
  • Geometry Difference Detection Section
    • The node's checkbox is EnableGeomDiff.
    • Detect Radius Number Field (mm)
    • Compares the workpiece geometry at that radius and attaches the result to the live meshed tree as a colour overlay. It does nothing, and says so, whenever there is nothing to compare: no workpiece in the session reports Diff--Empty (“No Workpiece exist”), no ideal (target) geometry warns Diff--NoIdealGeom, no meshed geometry warns Diff--NoMeshedGeom. Only a comparison that was actually built reports Diff--Built.
    • The result is read on the Execution page's Program branch, as the Geometry Difference [detection radius mm] node this field labels — present only while the overlay is attached. The colour-scale radius the overlay is read with lives on that node's panel and not here: it is a project setting, and changing it recolours the comparison instead of re-running it. See Program Branch.

Shot Files Output and Optimization Output are the two physics-gated sections. The condition is the physics preference and the advanced-physics licence, served to the client already combined; when it is off, the tree builder omits those two nodes entirely; a preference flip rebuilds the Mission branch in place — after a mission operation already in flight, and once the open Mission editor's dirty-switch gate lets it (see Control Tree). CL → NC Writeback is deliberately not gated — writeback is a SoftNc syntax feature, not a physics one.

Every edit saves as it is made. A rejected save is reported and the panel reloads the command.

Note

Post-Execution writes run-derived files only. The meshed-geometry snapshot is a placeable command of its own, because a snapshot can be taken at any spot in a mission: Record Meshed Geometry (RecordMeshedGeomCommand, with its No Action / Read / Write / Read On First Or Write modes) and Export Meshed Geometry (STL) (ExportMeshedGeomToStlCommand) are both Output-category catalog entries with editors of their own. Opening a project that still carries an enabled meshed-geometry output on this command raises a system warning naming the replacement, and re-saving the project drops the element.

Note

GeomDiffCommand exists as a standalone command, as do WriteStepFilesCommand, WriteShotFilesCommand and OptimizeToFilesCommand. None of them carries the catalog attribute, so they load from a project file but are not offered in the Add Command dialog. Post-Execution is the catalogued carrier of these outputs, which is why they are edited as its sections.

Source Code Path

See HiNC App Anatomy for git repository links.

Web Application

HiNC-2025-webservice (Quasar CLI SPA):

  • wwwroot-src/src/components/mission/PostExecutionCommandPanel.vue — the command node's two captions and one headerless block per section: step-files, shot-files, optimization, cl-nc-writeback and geom-diff. No checkboxes live here.
  • wwwroot-src/src/components/controlTree/missionItemTypes.ts — declares the five sections with their labels, marks Shot Files and Optimization physics-gated with an explicit note that CL → NC is not, filters the gated sections out of the tree, and maps each section id to its enable-flag reader and writer.
  • wwwroot-src/src/components/controlTree/MissionSectionPanel.vue — renders one section headerless, the breadcrumb already naming it, and passes no enable state down because the flags decide only what runs.
  • wwwroot-src/src/components/controlTree/useControlTreeHost.ts — the ticks: a command node ticks its own enable flag, a section node with an enable flag ticks that, and every other node hides the box.
  • wwwroot-src/src/api/mission.ts — loadPostExecution, POST_EXECUTION_DEFAULTS (the engine's defaults, which the load's fallbacks, the panel's initial value and the template placeholders read) and the eleven postexecution/* PUTs.
  • wwwroot-src/src/i18n/en/mission.ts — the field labels, the template hint, the [NcName] hint, the command node's coverage and overview captions and the writeback paragraph.
  • wwwroot-src/src/i18n/en/tree.ts — the five section node labels.
  • wwwroot-src/src/stores/appState.ts — the physics preference and licence flags the tree builder reads.
  • Environments/PreferenceController.cs — serves the physics preference already combined with the advanced-physics licence.
  • Missions/MissionController.cs — the commands/{path}/postexecution/* endpoints: the five enable flags, the four templates, the shot-file time resolution and the geom-diff detect radius.

HiAPI Engine

  • HiNc/SessionCommands/PostExecutionCommand.cs — the model, its display name and Output-category catalog registration, every default above, the run order, and the warning raised for a project still carrying a meshed-geometry output.
  • HiNc/SessionCommands/ListCommand.cs — the in-order run that skips disabled entries, which is what makes this command's placement decide what it covers, and that ends a stopped run before its next row.
  • HiNc/MachiningProcs/SessionShell.cs — what each output actually calls: the shot-file writer and its sampling-period guidance, the step-file writer, the optimization routing between the SoftNc and HardNc paths, the CL → NC writeback synthesis, and the workpiece difference.
  • HiNc/MachiningProcs/LocalProjectService.cs — the two writers themselves, WriteShotFile and WriteStepFile: the template resolved against the project folder, a file opened each time the source program changes, the Creating file row for each, and the …-Write--NoFile warning in place of finished when none was opened; the player's run of the mission, which paces after each action a row hands it and ends a stopped run at the next pace or at a null item, the gap between two outputs; and the step-physics recompute's wait for the run's next pace point, withdrawn when it comes too late.
  • HiNc/SessionCommands/GeomDiffCommand.cs, HiNc/SessionCommands/WriteStepFilesCommand.cs, HiNc/SessionCommands/WriteShotFilesCommand.cs and HiNc/SessionCommands/OptimizeToFilesCommand.cs — the standalone commands behind the same four outputs: loadable from a project file, absent from the catalog.
  • HiNc/SessionCommands/RecordMeshedGeomCommand.cs and HiNc/SessionCommands/ExportMeshedGeomToStlCommand.cs — the two catalogued Output commands that carry the meshed-geometry snapshot.
  • HiNc/SessionCommands/CommandCatalogAttribute.cs — the attribute that separates a loadable command from an addable one.

See Also