[{"data":1,"prerenderedAt":362},["ShallowReactive",2],{"post-zh-engineering-how-laetoly-parses-g-code-for-preview-worker-flow-modal-motion-known-limits":3,"header-article-translation-zh-engineering-how-laetoly-parses-g-code-for-preview-worker-flow-modal-motion-known-limits":194,"trans-gcode-parser-source-evidence-zh":195},{"id":4,"title":5,"body":6,"category":158,"date":159,"description":160,"difficulty":161,"draft":162,"duration":161,"extension":163,"featured":162,"image":164,"layout":167,"locale":168,"meta":169,"navigation":170,"path":171,"references":172,"related":161,"section":184,"seo":185,"slug":186,"status":187,"stem":188,"tags":189,"translationKey":192,"updated":161,"video":161,"__hash__":193},"content\u002Fzh\u002Fengineering\u002Fhow-laetoly-parses-g-code-for-preview-worker-flow-modal-motion-known-limits.md","Laetoly 如何为预览解析 G-code：Worker 流程、模态运动与已知限制",{"type":7,"value":8,"toc":146},"minimark",[9,13,18,21,24,28,31,34,37,40,43,46,49,52,55,58,61,64,67,70,75,78,81,84,87,90,93,96,99,134,137,140,143],[10,11,12],"p",{},"G-code 解析并不是一个统一的操作。一个程序可能涉及文本识别、模态状态、坐标解释、几何构建以及控制器特有的行为。本文只描述当前 Laetoly 源码证据在三个入口处所能说明的内容：前端预览 Worker、Java 后端解析器，以及 Python 刀路命令。现有记录都是静态源码快照，它们既不能证明这几条路径共用同一条运行时流水线，也不能证明某个文件一定能正确加工。",[14,15,17],"h2",{"id":16},"前端预览从-worker-开始","前端预览从 Worker 开始",[10,19,20],{},"在 Web 前端中，G-code 预览组件不会在页面主线程上解析程序。它会启动一个专门用于解析的独立 Web Worker，把 Worker 发回的消息转交给组件处理，并包含一条错误路径：当 Worker 报告错误时，正在等待的解析请求会被拒绝，而不是一直悬而未决。这说明浏览器一侧存在一条边界：解析工作位于消息接口之后，负责绘制预览的页面只与它交换消息。",[10,22,23],{},"仅凭这次源码审阅，还无法说明一次解析请求的完整生命周期、每一种消息结构，或者最终显示的几何是否正确。这些都需要浏览器测试夹具和运行时检查。源码记录也指出，在声称渲染几何正确之前，仍需检查对 Worker 结果的处理。",[14,25,27],{"id":26},"worker-初始化解析状态","Worker 初始化解析状态",[10,29,30],{},"在 Worker 内部，解析流程会先统计输入行数、选择校验模式、创建校验器，并建立解析状态。这个状态从默认的定位、单位和进给率设置开始，并分别为已解析的点和仍在拼接中的路径段准备好存放位置。这些细节描述的是该流程如何开始；它们并不能证明所有 G-code 方言、设置程序段或之后的状态变化都得到了处理。",[10,32,33],{},"校验器配置了坐标和激光功率限制。这些限制属于这个代码快照，而不是通用的机器行程、安全限制或产品规格。它们不应被照搬到机器设置指南中，也不应被表述为受支持的行程尺寸。这些证据是静态的，而且该仓库快照被标记为有未提交修改，因此在作为发布承诺公开之前，还需要对照版本进行复核。",[10,35,36],{},"区分文本解析与机器语义很重要。识别一个运动指令字或维护解析状态，只是判断控制器会做什么的一部分。预览可以把识别出的路径可视化，但这并不能证明目标机器接受文件中的每一条指令、每一个偏置或每一种模式。现有证据明确地把“识别出的指令字”与“完整的加工语义”区分开来。",[14,38,39],{"id":39},"后端解析器跟踪的模态状态更有限",[10,41,42],{},"Java 后端有自己的解析器。输入为空或只有空白时，不会生成任何指令。对于其他输入，解析器会保存一个单位模式和一个模态运动值，把程序拆分成行、去掉注释、把每一行拆成指令字，并检查其中的 G-code 数值。它把 G20 和 G21 分别当作英寸和毫米模式，并把 G0 或 G1 记为模态运动，用于之后只包含坐标的行。",[10,44,45],{},"遇到 G2、G3 或 G80 时，同一个解析器会清除记住的直线运动。源码中说明了原因：尚不支持圆弧插补，清除记住的运动可以避免把之后的圆弧坐标当作直线处理。这是一个很好的例子，说明解析器的限制被明确处理：一条指令可以被识别，而它完整的运动语义仍然不受支持。",[10,47,48],{},"在这个有限的例子里，“模态”指的是：当后续坐标程序段省略了运动指令字时，解析器会沿用之前的运动选择。这并不意味着每一种模态代码都已实现。源码明确列出了它会保留的 G0、G1 行为，以及会清除该状态的 G2、G3 和 G80 情况。技术说明应当把这个清单写清楚，而不是笼统地概括成“Laetoly 支持模态 G-code”，却不说明是哪些模式、哪个解析器。",[10,50,51],{},"单位状态是解析器中另一个独立的部分。它从毫米模式开始，看到 G20 或 G21 时才改变。单位影响数值如何被解释；它与记住的运动指令字不是同一个状态。阅读解析器时把这两部分状态分开，有助于避免把每一个 G-code 指令字都当作在修改解析器的同一部分。",[10,53,54],{},"这些代码证据能够支持的，是关于这个解析器如何把输入拆成指令字、如何决定模态运动的说明。它不能证明完全符合某个 G-code 标准、兼容所有控制器，或者机器能正确执行。Java 解析器与前端 Worker 是两条独立的证据记录，因此两处对相同指令字的处理看起来一致，并不足以证明两套实现的行为完全相同。",[14,56,57],{"id":57},"驱动程序提供刀路生成入口",[10,59,60],{},"用 Python 编写的本地驱动程序中，有一个命令的既定用途是把 SVG 输入转换为 G-code 刀路。它声明的输入包括刀具尺寸与类型、切削类型与深度、进给与下刀速率、主轴转速、安全高度、优化与简化选项、铣削方向，以及其他精加工或挖槽设置。换句话说，驱动程序接收一幅图形和加工选项，负责生成程序；而 Web 预览和后端解析器则是使用程序的一方。",[10,62,63],{},"这是关于一个接口及其声明输入的证据。审阅的源码并未展示完整的几何计算、所有分支、生成的 G-code，也没有与实际切削结果进行比较。因此，它可以支持一篇讲解命令边界的源码导读，但不能支持“某组特定参数会生成安全或精确刀路”这样的说法。",[14,65,66],{"id":66},"讲解时把三条路径分开",[10,68,69],{},"证据包涵盖前端 Worker、后端解析器和驱动程序的刀路命令。它们代表不同的源码入口。除非运行时追踪能够证明某个产品流程是如何把它们连接起来的，否则图表或文章都应把它们标注为分别检查的路径。如果画一条从 Python 刀路生成器指向浏览器 Worker 的简单箭头，就会暗示当前快照并未证明的调用关系。",[71,72],"figure",{"alt":73,"src":74},"前端预览路径与后端解析入口，作为两条分别检查的路径展示","\u002Fmedia\u002Fasset-template-gcode-parser-flow-zh.svg",[10,76,77],{},"这条边界对工程师很有用，因为它指明了下一步该调查什么。要建立端到端的契约，需要记录实际的界面请求、Worker 的输入和输出、任何后端解析请求，以及驱动程序生成的产物。然后用同一个示例程序在这几层之间进行比较，并记录所用的源码版本。在完成这些工作之前，结论应当与支持它的那部分源码绑定。",[14,79,80],{"id":80},"更强的运行时证据能补充什么",[10,82,83],{},"浏览器测试夹具可以把一个已知的小型 G-code 文件送入前端预览组件，并记录 Worker 的请求、响应、错误以及生成的几何。这样可以针对特定的浏览器构建和输入，测试从界面到预览的路径。但它并不会自动证明后端 Java 解析器或 Python 驱动程序使用相同的规则。",[10,85,86],{},"后端需要自己的解析器测试夹具。用例应当包括：设置运动指令字的一行、紧随其后只含坐标的一行、一次单位切换，以及一个不受支持的圆弧后面再跟一个坐标程序段。预期结果应当对照当前的解析器源码，以及项目打算支持的公开行为来检查。一个夹具的结果只是关于这些用例的证据，并不构成符合标准的声明。",[10,88,89],{},"驱动程序需要单独的 SVG 输入和生成结果检查。记录所选的刀具和工序设置，检查生成的文件，并与受控的预期形状进行比较。实际切削则是更进一步的验证步骤，需要特定的机器、材料、刀具和装夹。目前对该命令入口的审阅不包含这样的测试结果，因此本文对切削质量不作任何声明。",[10,91,92],{},"执行这些检查时，应把输入、输出、源码版本和测试条件一起保存。如果某个源码文件发生变化，在把文章中的描述视为最新之前，应对照新版本重新审阅。证据包已经为每条选定记录保存了仓库版本、未提交修改状态、文件指纹和源码位置；这些字段有助于准确定位某个说法所描述的是哪一个快照。",[14,94,95],{"id":95},"阅读解析器证据的稳妥方法",[10,97,98],{},"审阅解析器时，请把以下五个问题分开：",[100,101,102,110,116,122,128],"ol",{},[103,104,105,109],"li",{},[106,107,108],"strong",{},"识别："," 解析器会检查哪些指令字或指令族？",[103,111,112,115],{},[106,113,114],{},"状态："," 它会保留哪些单位、模式或模态运动值？",[103,117,118,121],{},[106,119,120],{},"几何："," 实际会生成哪些点或路径段，在什么条件下生成？",[103,123,124,127],{},[106,125,126],{},"校验："," 哪些检查会拒绝或限制输入？这些边界是产品默认值还是针对特定机器的数值？",[103,129,130,133],{},[106,131,132],{},"执行："," 同一个文件是否已在目标控制器和机器设置上验证过？",[10,135,136],{},"这里描述的记录回答了前两个问题的一部分，并展示了一些接口。它们并没有解决几何和执行这两个问题。前端证据要求在声称渲染几何正确之前先进行浏览器夹具测试；后端源码记录了一个不支持圆弧插补的情况；驱动程序的证据只覆盖了该命令的入口。",[14,138,139],{"id":139},"本文不声明什么",[10,141,142],{},"这篇源码导读不声明解析器的性能、对标准的符合程度、完整的圆弧支持、机器兼容性、控制器安全性或经过验证的加工结果。它不把受支持的指令清单当作完整语义的证明，也不会把一个有未提交修改的源码快照当成对每个发布版本的承诺。",[10,144,145],{},"这些限制本身就是技术结论的一部分。一篇严谨的解析器文章应当说明现有源码能证明什么、证据在哪里停止，并在用受控夹具测试之前，保持运行时行为的开放性。对 CNC 软件来说，这种区分能帮助读者理解软件是如何组织的，而不会把一次静态源码审阅误认为一次机器测试。",{"title":147,"searchDepth":148,"depth":148,"links":149},"",2,[150,151,152,153,154,155,156,157],{"id":16,"depth":148,"text":17},{"id":26,"depth":148,"text":27},{"id":39,"depth":148,"text":39},{"id":57,"depth":148,"text":57},{"id":66,"depth":148,"text":66},{"id":80,"depth":148,"text":80},{"id":95,"depth":148,"text":95},{"id":139,"depth":148,"text":139},"architecture","2026-09-28","基于当前源码快照能够证明的内容，解释一种 G-code 解析或刀路相关行为。",null,false,"md",{"src":165,"alt":166},"\u002Fmedia\u002Fasset-engineering-gcode-parser-source-evidence-cover-v1-4acd7b701125.webp","抽象的程序数据流穿过发光的处理方块，变成刻在木料上的刀路","article","zh",{},true,"\u002Fzh\u002Fengineering\u002Fhow-laetoly-parses-g-code-for-preview-worker-flow-modal-motion-known-limits",[173,176,179,181],{"id":174,"title":175},"evidence-57c129df64d7145c","Laetoly backend service source snapshot",{"id":177,"title":178},"evidence-add66504d6d5dbd7","Laetoly web frontend source snapshot",{"id":180,"title":178},"evidence-ca0db9e6c9526e9e",{"id":182,"title":183},"evidence-d56343cb188b1352","Laetoly local driver source snapshot","engineering",{"title":5,"description":160},"how-laetoly-parses-g-code-for-preview-worker-flow-modal-motion-known-limits","experimental","zh\u002Fengineering\u002Fhow-laetoly-parses-g-code-for-preview-worker-flow-modal-motion-known-limits",[190,191],"cnc","software","gcode-parser-source-evidence","rjKmx-_dFZhHGrYChsCY1sSMHzTC2qMKMRT4RR8E_BU",{"section":184,"slug":186},{"id":196,"title":197,"body":198,"category":158,"date":159,"description":347,"difficulty":161,"draft":162,"duration":161,"extension":163,"featured":162,"image":348,"layout":167,"locale":350,"meta":351,"navigation":170,"path":352,"references":353,"related":161,"section":184,"seo":358,"slug":186,"status":187,"stem":359,"tags":360,"translationKey":192,"updated":161,"video":161,"__hash__":361},"content\u002Fen\u002Fengineering\u002Fhow-laetoly-parses-g-code-for-preview-worker-flow-modal-motion-known-limits.md","How Laetoly Parses G-code for Preview: Worker Flow, Modal Motion, and Known Limits",{"type":7,"value":199,"toc":337},[200,203,207,210,213,217,220,223,226,230,233,236,239,242,245,249,252,255,259,262,266,269,273,276,279,282,285,289,292,324,327,331,334],[10,201,202],{},"G-code parsing is not one universal operation. A program can contain text recognition, modal state, coordinate interpretation, geometry construction, and controller-specific behavior. This article describes only what the current Laetoly source evidence shows at three entry points: a frontend preview Worker, a Java backend parser, and a Python toolpath command. The available records are static source snapshots. They do not establish that these paths share one runtime pipeline or that a particular file will machine correctly.",[14,204,206],{"id":205},"the-frontend-preview-starts-in-a-worker","The frontend preview starts in a Worker",[10,208,209],{},"In the web frontend, the G-code preview component does not parse a program on the main page thread. It starts a separate Web Worker that is dedicated to parsing, routes the Worker's messages back to the component, and includes an error path: when the Worker reports an error, the pending parse request is rejected instead of being left open. This is evidence of a browser-side boundary. Parsing work sits behind a message interface, and the page that draws the preview only exchanges messages with it.",[10,211,212],{},"That source review does not by itself show the complete lifecycle of a parse request, every message shape, or the correctness of the geometry eventually displayed. Those require a browser fixture and runtime checks. The source record also notes that the handling of Worker results still needs to be checked before claiming rendered geometry correctness.",[14,214,216],{"id":215},"the-worker-initializes-parsing-state","The Worker initializes parsing state",[10,218,219],{},"Inside the Worker, the parsing routine first counts the input lines, chooses a validation mode, creates a validator, and sets up its parse state. That state starts from default positioning, unit, and feed-rate settings, and prepares separate collections for parsed points and for path segments that are still being assembled. These details describe how this routine starts; they do not prove that all G-code dialects, setup blocks, or later state transitions are represented.",[10,221,222],{},"The validator is configured with coordinate and laser-power limits. Those limits belong to this code snapshot, not to a universal machine envelope, safety limit, or product specification. They should not be copied into a machine setup guide or presented as supported travel dimensions. The evidence is static, and the repository snapshot is marked dirty, so these observations need a version review before publication as a release guarantee.",[10,224,225],{},"The distinction between text parsing and machine semantics matters. Recognizing a motion word or maintaining a parse state is only one part of deciding what a controller will do. A preview can visualize a recognized path without proving that the target machine accepts every command, offset, or mode in the file. The available evidence explicitly separates recognized command words from complete machining semantics.",[14,227,229],{"id":228},"the-backend-parser-tracks-a-narrower-modal-state","The backend parser tracks a narrower modal state",[10,231,232],{},"The Java backend has its own parser. Empty or blank input produces no commands. For other input, the parser keeps a unit mode and a modal motion value, splits the program into lines, removes comments, breaks each line into words, and inspects the G-code values it finds. It treats G20 and G21 as inch and millimeter modes, and it remembers G0 or G1 as the modal motion to apply to later lines that contain only coordinates.",[10,234,235],{},"The same parser clears the remembered linear motion when it encounters G2, G3, or G80. The source documents why: arc interpolation is not yet supported, and clearing the remembered motion avoids treating later arc coordinates as a straight line. That is a useful example of a parser limitation being handled explicitly: a command can be recognized while its full motion semantics remain unsupported.",[10,237,238],{},"In this narrow example, “modal” means the parser carries a motion choice forward when a later coordinate block omits the motion word. It does not mean that every modal code is implemented. The source names the specific G0 and G1 behavior it retains and the G2, G3, and G80 cases that clear it. A technical explanation should keep that list explicit rather than shorten it to “Laetoly supports modal G-code” without saying which modes and which parser.",[10,240,241],{},"The unit state is another distinct part of the parser. It starts in millimeter mode and changes when the parser sees G20 or G21. Units affect how values are interpreted; they are not the same state as the remembered motion word. Keeping those two pieces of state separate when reading the parser helps avoid treating every G-code word as if it changed the same part of the parser.",[10,243,244],{},"The code evidence supports a statement about how this parser splits input into words and decides modal motion. It does not prove complete conformance to a G-code standard, compatibility with every controller, or correct machine execution. The Java parser is a separate evidence record from the frontend Worker, so matching behavior on the same words in both places is not sufficient proof that the two implementations behave identically.",[14,246,248],{"id":247},"the-driver-exposes-a-toolpath-generation-entry-point","The driver exposes a toolpath-generation entry point",[10,250,251],{},"The local driver, written in Python, has a command whose stated purpose is converting SVG input into a G-code toolpath. The inputs it declares cover tool dimensions and type, cut type and depth, feed and plunge rates, spindle speed, safe height, optimization and simplification options, milling direction, and additional finishing or pocket settings. In other words, the driver takes a drawing plus machining choices and is responsible for producing the program, while the web preview and the backend parser consume programs.",[10,253,254],{},"This is evidence of an interface and its declared inputs. The reviewed source does not show the complete geometry calculation, every branch, the resulting G-code, or a comparison against a physical cut. It therefore supports a source-navigation article about the command boundary, but not a claim that a specific parameter combination produces a safe or accurate toolpath.",[14,256,258],{"id":257},"keep-the-three-paths-separate-in-explanations","Keep the three paths separate in explanations",[10,260,261],{},"The evidence pack covers the frontend Worker, the backend parser, and the driver's toolpath command. They represent distinct source entry points. A diagram or article should label them as separate inspected paths unless runtime tracing proves how a particular product workflow connects them. Showing a simple arrow from the Python toolpath generator into the browser Worker would imply a call relationship that the current snapshots do not demonstrate.",[71,263],{"alt":264,"src":265},"The frontend preview path and the backend parser entry shown as two separately inspected paths","\u002Fmedia\u002Fasset-template-gcode-parser-flow-en.svg",[10,267,268],{},"This boundary is useful to engineers because it directs the next investigation. To establish an end-to-end contract, capture the actual UI request, the Worker input and output, any backend parsing request, and the driver's generated artifact. Then compare the same sample program across these layers and record the source revisions used. Until that work exists, keep conclusions tied to the part of the source that supports them.",[14,270,272],{"id":271},"what-stronger-runtime-evidence-would-add","What stronger runtime evidence would add",[10,274,275],{},"A browser fixture could send a small, known G-code file through the frontend preview component and record the Worker request, response, errors, and resulting geometry. That would test the path from UI to preview for the specific browser build and input. It would not automatically prove that the backend Java parser or the Python driver uses the same rules.",[10,277,278],{},"The backend needs its own focused parser fixture. Cases should include a line that sets a motion word, a following coordinate-only line, a unit change, and an unsupported arc followed by another coordinate block. The expected result should be checked against the current parser source and whatever public behavior the project intends to support. A result from one fixture is evidence about those cases only; it is not a standards-compliance claim.",[10,280,281],{},"The driver needs a separate SVG input and generated-output check. Record the selected tool and operation settings, inspect the generated file, and compare it with a controlled expected shape. A physical cut would be a further validation step with a particular machine, material, tool, and setup. The present review of the command's entry point does not include such a test result, so this article makes no claim about cut quality.",[10,283,284],{},"When these checks are performed, save the input, output, source revision, and test conditions together. If a source file changes, review the article against the new version before treating its description as current. The evidence pack already records the repository revision, dirty state, file fingerprint, and source location for each selected record; these fields help identify exactly which snapshot a statement describes.",[14,286,288],{"id":287},"a-safe-way-to-read-parser-evidence","A safe way to read parser evidence",[10,290,291],{},"When reviewing a parser, separate five questions:",[100,293,294,300,306,312,318],{},[103,295,296,299],{},[106,297,298],{},"Recognition:"," Which words or command families does the parser inspect?",[103,301,302,305],{},[106,303,304],{},"State:"," Which units, modes, or modal motion values does it retain?",[103,307,308,311],{},[106,309,310],{},"Geometry:"," Which points or segments are actually produced, and under what conditions?",[103,313,314,317],{},[106,315,316],{},"Validation:"," Which checks can reject or limit input, and are their bounds product defaults or machine-specific values?",[103,319,320,323],{},[106,321,322],{},"Execution:"," Has the same file been verified in the target controller and machine setup?",[10,325,326],{},"The records described here answer parts of the first two questions and expose some interfaces. They do not close the geometry and execution questions. The frontend evidence calls for a browser fixture before asserting rendered geometry correctness; the backend source documents an unsupported arc-interpolation case; the driver evidence covers only the command's entry point.",[14,328,330],{"id":329},"what-this-article-does-not-claim","What this article does not claim",[10,332,333],{},"This source walk-through does not claim parser performance, standards compliance, complete arc support, machine compatibility, controller safety, or a verified machining result. It does not treat a supported-command list as proof of full semantics. It also does not turn a dirty source snapshot into a promise about every released build.",[10,335,336],{},"Those limits are part of the technical result. A careful parser article should explain what the available source proves, show where the evidence stops, and leave runtime behavior open until it has been tested with a controlled fixture. For CNC software, that distinction helps readers understand how the software is organized without mistaking a static source review for a machine test.",{"title":147,"searchDepth":148,"depth":148,"links":338},[339,340,341,342,343,344,345,346],{"id":205,"depth":148,"text":206},{"id":215,"depth":148,"text":216},{"id":228,"depth":148,"text":229},{"id":247,"depth":148,"text":248},{"id":257,"depth":148,"text":258},{"id":271,"depth":148,"text":272},{"id":287,"depth":148,"text":288},{"id":329,"depth":148,"text":330},"Explain one G-code parsing or toolpath behavior that the current source snapshots can prove.",{"src":165,"alt":349},"Abstract streams of program data pass through a glowing processing block and become a toolpath carved into a wooden workpiece","en",{},"\u002Fen\u002Fengineering\u002Fhow-laetoly-parses-g-code-for-preview-worker-flow-modal-motion-known-limits",[354,355,356,357],{"id":174,"title":175},{"id":177,"title":178},{"id":180,"title":178},{"id":182,"title":183},{"title":197,"description":347},"en\u002Fengineering\u002Fhow-laetoly-parses-g-code-for-preview-worker-flow-modal-motion-known-limits",[190,191],"JPNa5GyszuQD8qnjjfleq-KFcH0YiUTWs04zX6Ghk-A",1792396297829]