Files
OpenNest/OpenNest.Core/IPostVerificationSupport.cs
T
ajandClaude Opus 5.5 72039a238b feat(post): declare placed order for CL nests that post in it
The Cincinnati CL post always drew an "incomplete final rapid sequence"
warning because it never declared IPostVerificationSupport. It writes etch
features before cuts, inserts or drops rapids, and with part sub-programs
rapids to each part's corner, so it cannot declare it unconditionally.

IPostVerificationSupport gains a nest-aware PlacedProgramOrderChange(nest)
(null = preserved; otherwise the reason, shown in the warning). The CL post
answers it from its own writer: part sub-programs and smart rapids off, and
every part's and hole's posted motions exactly equal to its placed ones.
Plan Cutting cuts scribes first, so planned nests qualify. CNC output is
unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-02 17:21:25 -05:00

24 lines
1.1 KiB
C#

namespace OpenNest;
/// <summary>
/// Optional post contract for nest-level rapid verification. Opt in only when the
/// post preserves Plate.Parts order and each placed Program's contour order and
/// pierce positions. This does not certify retract height, parking or controller macros.
/// Unknown/reordering posts still get nest diagnostics, but require acknowledgment
/// that their final rapid sequence has not been verified.
/// </summary>
public interface IPostVerificationSupport
{
/// <summary>True when the post preserves the placed order for every nest.</summary>
bool PreservesPlacedProgramOrder { get; }
/// <summary>
/// Why posting <paramref name="nest"/> with the current settings would not move in the
/// placed order, or null when it would. A post whose order depends on the nest or its
/// settings overrides this; it must return null only when the posted motion sequence
/// provably equals the placed one.
/// </summary>
string PlacedProgramOrderChange(Nest nest) =>
PreservesPlacedProgramOrder ? null : "does not declare that it preserves placed part/contour order and pierce positions";
}