Obviously its coz its old and works, but i chuckle everytime i have to look up the codes at how comically awful it is compared to anything else i see
It's a simple language, you don't have to memorize the codes and you end up memorizing the few you use most often anyway.
Honestly the actual math and figuring out the toolpaths for your machine ia far harder than writing the g-code for it.
Asking, because I am trying to level up cnc programming to "normal" programming.
The cam software i use does come with a few handy baked in things. Stuff like automatically lowering the feedrate for corners under a certain radius or for setting up z-level ramps.
There's a couple i can think of being handy. Functions for automatically decreasing feedrates at certain axis loads or horsepowers would be nice.
I think it would come down to something more like a handy library of functions for little things like that rather than anything really repeatable. Even that would likely be specific to whatever machine you use though.
Let's do a web site programming analogy(weak but relatable), because JS is now a mature programming language with advanced interpreters. This was not the case back when JS was used to make text dance and a few other useful ad-hoc solutions.
-Early web days with just html is like plain g-code spit out from cam systems.
-Early javascript is like macro options available on industrial cnc[1][2][3].
-Mid years javascript is where cnc macro program is heading, isolated shops doing some awesome things but no industry wide adoption of a coherent system.
-Late years javascript is where cnc macro programming needs to be if we want proper revision control and all the other benefits that normal programmers have afforded themselves.
Which brings us to real digital twins(monozygotic, not the fraternal state of the art), a single source of truth digital file should manifest as both a real world part on the shop floor and a virtual object in the top floor to be used by all the departments.
To close the analogy, like nodejs affords developing on the backend and the frontend with the same language.
[1] http://parts.haascnc.com/haasparts/en/USD/Performance-Upgrad...
[2] https://www.fanucamerica.com/fanuc-america-product-support/f...
[3] https://www.cncci.com/resources/tips/w%20custom%20macro.htm
I think of G-code as ASM. For high-performance work you might write code differently for different (related) machines, but it's still a pretty OK compilation target.
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
>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?
go_home
set_units mm
set_movements relative
activate_tool 0
move X 10
move Y 10
That said, I bet vim syntax highlighting could get you most of what you want. Color code movement, configuration, values, maybe display the toolhead status and position at your current line in the status bar...
A CNC moves with speeds on the mm/s range. So does a 3D printer (unless you ask for larger movements, but those take less codes/s). They also have a precision on the 100's of µm, but let's push it down to 10's here so we overestimate things by an order of magnitude.
That means they'll need around 1000 codes/s, with a minimum of 64kbps on the 8 character case, or 72kbps with my codes. I don't think there is any serial interface chipset on the market that can't do 512kbps even on a 100's of meters long cable. Not to say that everything nowadays runs over USB anyway.
The gcodes are a leggacy that isn't needed anymore. And since both sides of the CNC link are composed of overpowered computers doing anything on software, the only reason it didn't change already is because nobody bothered to do something better. I'm not much bothered by them either so, I'm not jumping over it, but it is suboptimal.
Compilers targeting G-code are called CAM software.