[onmai-xyz]

A good G-Code variant would roll up the un-rolled loops and separate the geometry data from the tool config data. This is what the view of a CAM IDE presents, G-Code source can be structured the same. If you change the semantics on some of the syntax you get lexically scoped blocks, macro-b subsystem which has existed for decades needs to be fully utilized for this to happen.

A fully implemented system would provide the CAM GUI engineer and the CNC CLI machinist to work on the same file, skipping post-processing entirely.

And, finally implement what was originally envisioned but not possible on even the most powerful mainframes of the late 50's: https://youtu.be/ob9NV8mmm20

[lvh]

Eventually, something actuates a servo, and servos don’t understand iteration. Do you agree eventually something with g-codes level of detail must exist (even if it’s just unspecified internal commands)? If so, do you agree you’re just advocating for that layer to be part of the machine?

[onmai-xyz]

Speaking from user space that has G65 macro-b option, not machine tool builder (sudo) space.

>I think of G-code as ASM.

>Eventually, something actuates a servo, and servos don’t understand iteration.

I think of it more as an intermediate language. Interpreted on the CNC control and JIT compiled to whatever the RT system needs for servo control.

>Do you agree eventually something with g-codes level of detail must exist (even if it’s just unspecified internal commands)?

It does exist and a strict subset with enough primitives to bootstrap an application VM should continue to exist.

>If so, do you agree you’re just advocating for that layer to be part of the machine?

I am advocating for a DSL one layer up to be part of the CNC machine with support offline in say the JVM.

I want to answer this question, “how do we deploy MBE?” https://www.nist.gov/news-events/events/2019/04/model-based-...

The answer needs to be a single digital file that can render real parts and virtual parts. Why not?